T1614 system location discovery: what attackers learn and where it shows up
When a SOC lead sees a suspicious process or session asking where the system runs, the question is usually a location probe inside the Discovery tactic. T1614 System Location Discovery describes an adversary working out the physical or cloud location, region or geography of a host so it can plan its next step. The technique sits under Discovery (TA0007), which MITRE describes as the point where "the adversary is trying to figure out your environment." Location answers matter because they tell an attacker which data residency rules apply, which cloud region holds valuable workloads, and whether the host sits somewhere it can operate without drawing the attention of local responders or regional controls. Read the MITRE ATT&CK tactic page for Discovery before writing detections so your team uses the same definition as your analysts.
ATT&CK defines T1614 with one sub-technique, so your detection inventory should record both the parent technique and that child. Any detection mapping you write must name the ATT&CK version it targets. This document uses Enterprise ATT&CK 20.0, and the mapping should be re-checked whenever MITRE renames, deprecates or revokes a technique or changes its data components. Confirm the current technique and sub-technique names in the version your team has adopted, rather than assuming an older release still applies.
Your first decision is scope: which platforms and telemetry can reveal a location query in your estate. Ask your platform team which hosts run on physical servers, which run on IaaS instances, and which sit behind a managed platform that hides the underlying location. Then check that the logs you need are actually collected for those platforms. The sections on detection and data sources cover the specific signals. Here, the practical step is to confirm, in writing, which owner is responsible for each platform's telemetry before the first detection rule goes live.
Which telemetry reveals system location discovery on each platform
This table maps each platform in scope (IaaS, Linux, macOS and Windows) to the data components the ATT&CK STIX data associates with T1614, the signal to look for and an open-source collector that can capture it. Read it as a starting point for coverage, then confirm the exact data component mapping for T1614 in the enterprise-attack 20.0 bundle before you rely on any row. The main takeaway is that IaaS coverage depends on cloud audit logs, while host platforms depend on process and command telemetry.
| Platform | Data components to confirm | Signal to look for | Open-source collector |
|---|---|---|---|
| IaaS | Cloud service audit records, Network Traffic Content (DC0085) where flow data exists | Calls to instance metadata endpoints or cloud location APIs from workloads that do not normally query them | Cloud audit log forwarding into a Wazuh or Security Onion pipeline, Zeek on virtual network flow data |
| Linux | Process Creation (DC0032), Command Execution (DC0064) | Shell or utility invocations that read time zone, locale, hostname or geolocation-related configuration in unusual sequence | Wazuh agent, auditd rules, Velociraptor hunts |
| macOS | Process Creation (DC0032), Command Execution (DC0064) | Command-line tools queried for system locale, time zone or network-derived location from non-administrative user contexts | Wazuh agent with unified logging collection where configured, Velociraptor artifacts |
| Windows | Process Creation (DC0032), Command Execution (DC0064), OS API Execution (DC0021) | Scripted or built-in commands that return regional settings or time zone from processes launched by unexpected parents | Sysmon with a Wazuh agent, Velociraptor, Sigma rules converted for the chosen SIEM |
| Network (all platforms) | Network Traffic Content (DC0085) | Outbound requests to public IP geolocation services from hosts that have no business reason to query them | Zeek HTTP and DNS logs, Suricata alerts on defined destination lists |
| Verification step | All components above | Confirm the T1614 data component mapping and detection strategy wording in the enterprise-attack 20.0 bundle before publishing | Pin the ATT&CK version in each detection record |
Detection logic for T1614 that SOC analysts can tune
T1614 System location discovery shows up as small, repeated queries about where a host, account or workload runs. The cards below describe detection ideas across endpoints, cloud instance metadata and network content, with the thresholds to tune and the benign sources that will trigger them first.
Location-related process execution on Linux
Watch for short-lived processes that read time zone, locale, network region or host location settings, especially when launched by an interactive shell, a web service account or a script that has no change ticket. Count distinct location-related reads per host per hour and alert on a sudden rise above that host's baseline. Expect configuration management, package installers and cron jobs that read locale files to be the main false positive sources, so exclude known management service accounts and parent processes after validating them in your environment.
Location-related process execution on Windows
On Windows, focus on process creation events where command interpreters or scripting hosts run locale, time zone or region queries that are not part of a logon or patching workflow. Pair the process event with the parent process and the user context, and alert when one account runs several of these queries across many hosts within a short window. Management agents, endpoint protection and inventory tools commonly perform similar queries, so maintain an allow list keyed to signed binaries and known service accounts.
Metadata service access on IaaS
Instance metadata endpoints reveal region, availability zone and instance identity, so unexpected requests to them from application processes are a strong T1614 indicator. Baseline which workloads normally call the metadata service, then alert on new source processes, new containers or user identities calling it, and bursts of requests that differ from the usual pattern. Cloud agents, configuration tools, container runtimes and SDK credential refresh routines are the common false positives, so confirm each one with your cloud provider's documentation and your own asset inventory.
Cloud control plane location queries
Location data also appears in cloud API calls that list regions, zones or resource locations for an account. Build a per-identity baseline of region enumeration calls and alert when an identity that normally operates in one or two regions starts enumerating all regions, especially from an unfamiliar network address. Asset inventory tools, cost management dashboards and infrastructure-as-code pipelines generate these calls legitimately, so tag their identities and review the exclusions quarterly.
Geolocation lookups in network content
Outbound requests to public IP geolocation services, or DNS queries for such services, can indicate an attempt to learn where a host sits on the internet. Use network traffic content and DNS logs to flag hosts that contact geolocation domains they have never contacted before, and rate-limit alerts by host criticality. Legitimate geolocation features in browsers, mobile device management, time synchronization tools and software license checks produce the same signal, so document which applications are expected to call these services before setting severity.
Tuning thresholds and review cadence
Set thresholds from a baseline period of normal activity rather than from vendor defaults, and record each suppression with its owner and a review date. Start with a low-severity alert that routes to a queue, then raise severity only after analysts confirm the false positive rate for each source. Re-run the baseline after major changes to cloud accounts, endpoint tooling or network egress rules, because those changes shift what counts as normal.
How to validate that the T1614 detection fires
This sequence proves, in a private cyber range, that the T1614 System Location Discovery detections fire on each covered platform, and it produces a dated record of hits, misses and gaps that can be re-run after every rule change.
Define the test scope and ATT&CK version
The detection owner and the range lead agree in writing which platforms are in scope for T1614 System Location Discovery, such as IaaS, Linux, macOS and Windows, and which telemetry sources each platform is expected to produce. Record the Enterprise ATT&CK version the test targets, because technique and data component mappings can change between releases, and name that version on every result. The step is done when the scope sheet is signed off and the target version is written at the top of it.
Map expected telemetry for each platform
For each in-scope platform, list the data components the detection strategy relies on, such as Process Creation, Command Execution and Network Traffic Content, and name the log source that should carry each one in your stack, for example the Wazuh agent, Zeek or Suricata sensor, or cloud audit feed. Confirm the exact data component IDs and detection strategy identifiers against the ATT&CK release you recorded in the previous step, not against memory. The step produces a matrix of platform, expected telemetry and collecting sensor, which is the baseline for every later check.
Name the expected alerts and rule identifiers
Assign each detection rule its name, version and owning team, and state the alert title the SIEM should raise when the rule matches, such as the Sigma rule title after conversion to your backend. Agree how an alert is considered a hit, for example a match on the expected host and process context within the agreed collection window, and how a partial match is recorded. The step is complete when every platform row in the matrix maps to at least one named alert and one hit criterion.
Run the emulation and capture the record
The red or purple team runs the agreed T1614 emulation activity inside the isolated range, following the written plan, while a second person watches the SIEM. For every run, record the timestamp, source host, user context, platform, rule identifier and whether the detection fired or missed. Store the log of runs with the ATT&CK version and rule versions in the evidence repository. The step is done when every planned run has one complete record, including the misses.
Check coverage gaps per platform
Compare the run records against the expected telemetry matrix and sort each gap into one of three groups: no telemetry collected, telemetry collected but no rule matched, or rule matched but alert not routed. Assign each gap an owner and a fix type, such as collector configuration, rule logic or alert routing. Platforms where no run produced a hit must be marked as not covered rather than assumed covered. The step produces a per-platform coverage table that the CISO or detection lead can review.
Tune rules and re-run after changes
Apply the agreed fixes to collectors, rules or routing in a change record that references the gap identifiers. Repeat the same emulation for every platform that changed, then for a regression sample of platforms that did not, to confirm that tuning did not break earlier hits. Compare the new records with the earlier ones and note any rule whose false positive rate in normal range activity changed. The step is complete when the re-run results are stored beside the originals and the change record is closed.
Re-validate after each ATT&CK release
When MITRE publishes a new Enterprise ATT&CK version, compare the T1614 technique, its sub-technique and its detection strategy against the version you tested. If mappings were renamed, deprecated or revoked, update the matrix, rerun the affected runs and record the new version in the evidence file. Confirm the release details in the MITRE ATT&CK updates page before planning the re-run. The step is done when the evidence file shows which version each result belongs to.
How to triage a T1614 alert without over-reacting
The first decision on a T1614 System Location Discovery alert is whether the lookup came from a process that has a reason to ask where it runs. Start with the process parent. A location query launched by a configuration management agent, a cloud guest agent, a provisioning script or a monitoring collector, started by its usual service manager, is normal behavior on many IaaS hosts. The same query spawned by a document viewer, a web server worker, a scripting host opened from an email attachment, or an interactive shell with no change ticket behind it deserves immediate attention. Next, check the account that owns the process. Service accounts that the platform team created for an agent are expected to query metadata. An ordinary user session on a database server, or a service account that has never queried metadata before, is a question to answer before closing the alert.
Then look at timing and expectation. Compare the event against the host's baseline and against your change calendar. A lookup during a scheduled patch window or agent upgrade is easy to explain. A lookup at 03:00 on a host that has never run a location check is not, though it may still be routine if a scheduled job runs then. Confirm with the owning team whether the host is supposed to reach the metadata service at all, because many hardened builds block or restrict that path, and a successful query from a host that should be blocked is a stronger signal than the query itself. Finally, widen the view. T1614 is usually one step in a wider reconnaissance sequence, so search the same host and account for nearby discovery activity such as account, network configuration, process or cloud service enumeration in the same session. A single benign lookup with no neighbors and a known parent is a candidate for tuning. A lookup followed by several other discovery events within minutes warrants escalation and a host review.
Record the outcome in the alert so the next analyst can reuse the reasoning. Note the expected parent, the owning team, whether the host is documented as a metadata consumer and whether related discovery appeared. If the answer is benign, tune the rule with a narrow exclusion tied to the specific parent and account rather than suppressing the technique across the estate. Confirm the ATT&CK version your detection content targets before you change mappings, because the detection strategy for this technique can change between releases, and check the current technique page on the MITRE ATT&CK website during review.
Preventive controls that limit location discovery
Location discovery is hard to block outright because it relies on metadata that most workloads can read by default. The controls below reduce what a foothold can learn about its placement, limit the paths it can use to reach metadata or management interfaces, and make attempts visible when they happen. Confirm the exact mitigation mapping for T1614 System location discovery in the ATT&CK version you target, since mappings are updated between releases.
User account management
ATT&CK mitigation M1018 covers restricting who can create, modify and use accounts. For T1614, the relevant question is which identities can query cloud instance metadata, read cloud region or availability zone attributes, or call provider APIs that return placement details. Review IAM roles on IaaS workloads and remove broad read permissions that are not needed by the application. Confirm with your provider's documentation which roles expose location attributes.
Network segmentation
ATT&CK mitigation M1030 limits which hosts can reach each other and which networks can reach metadata endpoints. On IaaS, restrict workload egress so that only approved services can contact the link-local metadata address, and separate management networks from application tiers. Segmentation does not stop a local process from reading location data, but it narrows the reach of a compromised host. Check that the rules apply to containers and VMs alike.
Audit logging
ATT&CK mitigation M1047 is about enabling the logs needed to see discovery activity. For T1614, make sure cloud audit logs, instance metadata access logs where the provider offers them, and host command auditing are retained and forwarded to your SIEM. Without these records, a location query looks like ordinary administration. Confirm which metadata access events your provider records and at what detail.
Operating system configuration
ATT&CK mitigation M1028 covers hardening settings on the operating system. On Linux, Windows and macOS hosts, restrict local tools that query cloud metadata, limit outbound HTTP from service accounts, and keep agents and utilities that are not needed off base images. Apply these settings through your configuration management baseline so that they are reproducible and auditable.
Network intrusion prevention
ATT&CK mitigation M1031 relies on inspecting and blocking traffic that matches known discovery patterns. Suricata or a comparable inline sensor can alert on or drop requests to metadata endpoints from unexpected sources. Tune rules carefully, because legitimate cloud agents also query metadata. Test each rule in a range before enforcing it in production.
Disable unneeded features
ATT&CK mitigation M1042 removes software and features that give an adversary easy discovery options. For T1614, disable metadata versions, endpoints or legacy interfaces your workloads do not use, and remove diagnostic utilities that expose instance details. Review each image or template to confirm nothing depends on the feature before you turn it off.
Response steps when a T1614 detection fires
This sequence turns a T1614 System Location Discovery alert into a scoped, evidence-backed decision on containment. It makes sure the team knows which hosts and cloud accounts were touched, what the identity did before and after the query, and who must be involved before any change is made.
Confirm the alert against the raw telemetry
The on-call analyst opens the alert in the SIEM and reviews the underlying process creation, command execution or cloud audit events that triggered the rule, not only the rule summary. Confirm the host or cloud identity, the time window, the parent process and whether the activity matches a known administrative task such as a provisioning script, an inventory job or a scheduled health check. The step closes when the analyst records either a confirmed true positive with the triggering event IDs or a documented benign explanation that names the owner who can verify it.
Scope affected hosts and cloud accounts
Identify every host, container node and cloud account, subscription or project that shows the same location-related queries within the investigation window. Pivot on the account or service identity rather than only the first host, and check whether the same activity appears from other source addresses. Record the full list in the case file with first and last seen times. The step is complete when the scope list is reviewed by a second analyst and marked as either contained to one asset or spread across several.
Preserve process, network and cloud audit evidence
Export and hash the relevant process creation records, command execution history, network traffic captures or flow records and cloud control-plane audit logs before retention windows roll them over. Store the copies in the case repository with restricted access and a chain-of-custody note. Confirm that the export covers both the source identity and the metadata service or API calls the activity used. The step closes when the evidence set is verified as readable and complete for the defined scope.
Review everything the same identity did
Build a timeline of all actions taken by the implicated user, service account or workload identity around the location query. Look for follow-on discovery, credential access, changes to network or IAM configuration, new resource creation and data access. Note any activity from unfamiliar locations or unusual times. The step is done when the timeline is attached to the case and each unexpected action has either an explanation or an open item assigned to an owner.
Decide on containment with the asset owner
Using the scope and timeline, decide whether to isolate a host, disable or restrict a cloud identity, rotate affected credentials or tighten a network path. Involve the system owner so that business-critical services are not interrupted without agreement. Document the chosen action, the reason for it and the rollback path. The step closes when the decision and its approver are recorded and the containment action is confirmed in the logs.
Escalate to incident response and governance
Escalate the case to the incident response lead and, where regulated data or cloud tenant boundaries may be involved, to the privacy, legal and compliance contacts defined in the organization's playbook. Share the evidence index, the scope list and the decisions made so far. Confirm the notification obligations and timelines with those contacts, since these depend on the organization's own regulatory duties. The step is complete when the escalation is acknowledged and the case owner is named.
Record lessons and tune the detection
After containment, record whether the detection was accurate, which benign sources caused noise and whether any gaps in telemetry slowed the response. Feed the findings into allowlists, rule tuning and data source coverage work, and retest the rule in the cyber range against the same scenario. Map the update to the ATT&CK version the rule targets so the change is traceable. The step closes when the post-incident review is filed and the tuning change is approved and deployed.
How to rehearse T1614 detection in a private cyber range
The IaaS tab covers a dedicated test tenant or subscription in a cloud account that the exercise team controls, with no production workloads and no shared identities. The range should mirror the logging you run in production: control-plane audit logs, identity sign-in records, and any instance metadata access logs your provider exposes. Confirm which of these your provider records and at what retention, because the exercise can only test what is logged. Activity is scripted in advance by the exercise team, and the purple team reviews which queries the defenders run.
- Range setup: A sandboxed tenant with a test identity that has read-only rights, forwarding of control-plane and identity logs into the same SIEM used in production.
- Conceptual injects: A scripted series of read-only location and metadata queries issued from a test workload, run at a set pace and logged with a unique exercise tag.
- Good detection: Alerts or hunts that correlate the identity, the source workload, and the unusual query pattern within the expected logging delay.
- Good response: The on-call cloud engineer confirms the identity, checks whether the workload was expected, and records the decision in the case with the exercise tag.
- Check afterward: Whether the detection fired on the first pass, and whether any log source you assumed was missing.
Confirm with your provider which metadata and audit events are available in your tenant before you commit to a detection scope.
The Linux and macOS tab uses a small set of hosts built from the same images as production, enrolled in the monitoring agent and forwarding process creation, command execution and network telemetry. The exercise team scripts the activity, so defenders see only the outcome of a planned sequence. The range should include at least one host where the agent is deliberately misconfigured, so the team can measure what a coverage gap looks like before an adversary finds it.
- Range setup: Hosts on an isolated segment, with auditing and endpoint telemetry forwarded to Wazuh or the SIEM chosen for the program, and a baseline of normal administrative activity.
- Conceptual injects: Scripted location-related commands run from a standard user session and from a service account, each tagged so responders can trace them.
- Good detection: Rules that flag location lookups from accounts or parent processes that do not normally perform them, mapped to the Process Creation and Command Execution data components.
- Good response: Responders isolate the host or session only after confirming scope, preserve the process tree, and check for follow-on activity.
- Check afterward: Whether the rule relied on command text that a legitimate tool could also produce, and how many false positives appeared during the baseline period.
Verify that every host forwards its telemetry before the exercise starts, since a silent agent looks identical to a quiet host.
The Windows tab uses a private domain segment with a domain controller, a small set of workstations and member servers, and a logging pipeline that matches production. The Windows segment is where the exercise team can test whether process creation auditing, command line capture and network content inspection work together. Because the segment is private and scripted, the team can compare the same injects across hosts with different logging settings and record which settings were actually in effect.
- Range setup: A separate forest or domain with restricted credentials, Sysmon or equivalent process logging, and command line auditing enabled and verified.
- Conceptual injects: Scripted location lookups issued from a standard user, from an administrator session, and from a remote management session, each with a distinct tag.
- Good detection: Correlation of process creation, command execution and network traffic content that identifies the session, the host, and the sequence within the same time window.
- Good response: Responders validate the session with the identity team, contain the account if needed, and document which data components supported the decision.
- Check afterward: Whether command line capture was complete on every host, and whether any detection depended on a single data source.
Confirm your audit policy and logging configuration against the vendor documentation for your Windows version before relying on any result.
Practitioner questions about detecting T1614
How do I map T1614 to the current ATT&CK version and detection strategy IDs?
Start with the Enterprise ATT&CK 20.0 STIX bundle in the mitre-attack/attack-stix-data repository, filter for the technique ID T1614, and follow its relationships to detection strategies and data components. Since ATT&CK v18, technique pages no longer carry detections directly. Detection strategies (DET IDs) and analytics hold that logic, so record the DET ID and the ATT&CK version together in each rule's metadata. Releases can rename, deprecate or revoke techniques, so repeat the mapping after each release, including v19 and v20. Confirm the exact DET IDs in the bundle yourself, and do not copy them from older blog posts or community mappings. The ATT&CK updates page lists what changed in each release.
Do Sigma rules cover T1614 on every platform in scope?
Usually not, so check each rule's logsource and platform fields against every platform you run. T1614 coverage spans IaaS, Linux, macOS and Windows, and the telemetry you need includes Process Creation, Command Execution and Network Traffic Content. Sigma rules are written against specific log sources. A Windows process creation rule gives you nothing on Linux audit data, and an IaaS rule depends entirely on your cloud audit logs being ingested. Treat community rules as starting points, test each one against your own log format and field names, and record every uncovered platform as an explicit gap with an owner. Ask the rule maintainers which fields they normalize and which they assume.
How do we handle cloud metadata access noise for T1614?
Begin by baselining which processes, service accounts and agents legitimately query instance metadata endpoints in each IaaS account. Record them in an allowlist keyed on process name, parent process, user and destination, and review it during change windows such as agent upgrades. Keep exceptions narrow, because a broad rule for a whole subnet or account hides the activity you need to see. Route remaining hits to triage with context: the workload, the identity, and whether the same host shows Command Execution from an unusual parent. For example, illustratively, a configuration agent that queries metadata at boot is expected, while a shell launched by a web server doing the same is not. Document every suppression with an owner and a review date.
How can we test T1614 detections without disrupting production?
Rehearse the detection in a private cyber range that mirrors your collectors, log formats and IaaS account structure before any production check. Agree the scope in writing: which hosts and accounts are in play, the time window, and who can stop the exercise. The team that owns the range should run approved test activity, then confirm that the expected alert fires in Wazuh or your SIEM with the fields your rule needs. In production, limit checks to read-only validation, such as confirming that Process Creation events from a canary host arrive on time. DeployOpen runs private cyber ranges and security testing, and engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How do we know our T1614 coverage is complete?
A rule count cannot prove completeness, but a coverage matrix can show what you have tested, what you have not, and what compensates for the gap. Create rows for IaaS, Linux, macOS and Windows and columns for Process Creation, Command Execution, Network Traffic Content and the DET ID you map to. Mark each cell as tested in the range, ingested in production, or missing. Re-run the range test after each ATT&CK release and after each collector change, because either can silently break a detection. Share the matrix with your internal audit function or external assessor as evidence of method. It documents your testing, and it does not certify anything.
What should we confirm with each collector vendor before relying on it?
Ask which event types the collector emits for process creation, command execution and network content, and whether every field your rules need is populated on each supported OS version. Confirm the log schema version and whether field names change on upgrade. Ask how the collector handles high-volume metadata or network events, including sampling, dropping and truncation, because any of these can hide the events you are looking for. Confirm how timestamps are sourced and how clock skew is handled, since cross-host correlation depends on it. Request the vendor's documented limitations for IaaS and containerized hosts, get the answers in writing, and retest after every upgrade.
How DeployOpen works on this
DeployOpen approaches T1614 System location discovery as a fixed-scope engagement that runs inside the client's own infrastructure, from the telemetry the environment already produces. The work covers the detection logic, the validation evidence and the response runbook, handed over in a form the client's own team can operate.
How we scope
- Confirm which platforms are in scope for T1614, such as IaaS, Linux, macOS and Windows, and which are excluded.
- Inventory the Process Creation, Command Execution and Network Traffic Content sources that already reach the SIEM.
- Agree the ATT&CK version the detections target and record it in the written scope before work starts.
How we build
- Write detection logic for T1614 in open formats such as Sigma and map it to the data components named in the ATT&CK detection strategy.
- Deploy and tune the rules in the client's Wazuh, Security Onion or other chosen stack, with the collectors inside the client's own environment.
- Document known benign administrative activity that resembles location lookups so analysts can separate it from suspicious use.
How we hand over
- Deliver the rule set, test cases and a validation report showing which telemetry triggered each detection in the range.
- Provide a response runbook for T1614 alerts covering triage questions, containment steps and evidence capture.
- Walk the client's security operations team through the rules and run a rehearsal exercise in a DeployOpen private cyber range.
How we support
- Offer ongoing support as a retainer to tune false positives and update mappings when ATT&CK releases change techniques.
- Re-run validation after platform upgrades or log source changes that could break the T1614 detection logic.
- Confirm with your team which support hours, response channels and retainer terms apply, as these are set out in the written scope.
