---
{
  "title": "System Location Discovery",
  "summary": "System location discovery estimates a host's geographical context from configuration or other clues.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1614"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1614: System Location Discovery",
      "url": "https://attack.mitre.org/techniques/T1614"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

System location discovery estimates a host's geographical context from configuration or other clues. It can affect targeting or execution decisions.


## An investigation example

A suspicious program examines locale and location-related settings and changes behavior depending on the result.

## Evidence to examine

Review queried settings, program conditions, host configuration, and differences across tested environments.

## A common analytical pitfall

Locale is not a reliable statement of a person's physical location, and legitimate applications use these settings.

## Response considerations

Report what the program actually queried and did, preserving uncertainty about how accurately the inferred location reflects reality.


## Configuration can suggest location without proving presence

System location may be inferred from language, timezone, locale, network information, or other environmental clues. An intruder can use those clues to select or avoid targets. The inference is imperfect: people travel, remote services use distant infrastructure, and language or timezone settings may not match physical location. Treat the result as context rather than precise geolocation.

Legitimate applications use similar information for formatting, scheduling, and localization. Evaluate the requesting process, account, purpose, and relationship to later behavior. A language-setting query alone is not a strong indicator of malicious activity. The important question is how the information was used within the observed sequence.

## A fictional selective execution

An academy's training sample checks locale-related settings and then behaves differently across two prepared environments. Analysts record the settings and other differences rather than assume locale is the only cause. They compare the sequence with the sample's context and any subsequent action. A controlled difference can support a hypothesis, but additional variables may remain.

Network-derived location also needs caution. A public address may identify a gateway, cloud region, VPN exit, or approximate service location rather than the person operating a device. Do not use one such clue to make a confident claim about an individual's physical presence or nationality. Preserve the source and uncertainty.

## Compare location clues

Create a fictional host with one timezone, another interface language, and a VPN address associated with a third region. Explain why these observations can coexist without contradiction. Then write a bounded statement about what a process could learn from querying them. Use prepared data rather than collecting personal location information from real users.

This distinction matters in both detection and reporting. Location anomalies can prioritize review, but they require session, identity, and business context before they justify an attribution claim. A useful finding describes the clue and its limitations instead of presenting configuration metadata as a definitive map pin.

## Related concepts

- [[digital-forensics]]
- [[incident-timeline]]
- [[logs-and-telemetry]]