Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1430: Location Tracking

Adversaries may track a device’s physical location through use of standard operating system APIs via malicious or exploited applications on the compromised device.

On Android, applications holding the `ACCESS_COAURSE_LOCATION` or `ACCESS_FINE_LOCATION` permissions provide access to the device’s physical location. On Android 10 and up, declaration of the `ACCESS_BACKGROUND_LOCATION` permission in an application’s manifest will allow applications to request location access even when the application is running in the background.[1] Some adversaries have utilized integration of Baidu map services to retrieve geographical location once the location access permissions had been obtained.[2][3]

On iOS, applications must include the `NSLocationWhenInUseUsageDescription`, `NSLocationAlwaysAndWhenInUseUsageDescription`, and/or `NSLocationAlwaysUsageDescription` keys in their `Info.plist` file depending on the extent of requested access to location information.[4] On iOS 8.0 and up, applications call `requestWhenInUseAuthorization()` to request access to location information when the application is in use or `requestAlwaysAuthorization()` to request access to location information regardless of whether the application is in use. With elevated privileges, an adversary may be able to access location data without explicit user consent with the `com.apple.locationd.preauthorized` entitlement key.[5]

MobileT1430TechniqueObject v1.2 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Location Tracking matters because a compromised or malicious mobile app can turn an employee’s Android or iOS device into a source of physical-location intelligence. For executives and security leaders, the risk is not only privacy; it can affect executive protection, field operations, critical infrastructure staff, investigations, and any business process where knowing a person’s location creates safety or operational risk.

Executive priority

Prioritize this where mobile devices are used by executives, administrators, responders, field personnel, government-facing staff, or operational teams. Leaders should ask whether the organization can prove which apps have location permissions, whether background location access is controlled, whether mobile OS versions are current, and whether EMM/MDM and cloud device-location services are governed and audited. This technique also supports compliance and privacy evidence because location data is sensitive and access should be justified, minimized, and monitored.

Technical view

For Android and iOS, validate controls around application permission requests and privileged access to location services. Android review should include apps requesting ACCESS_COAURSE_LOCATION, ACCESS_FINE_LOCATION, and ACCESS_BACKGROUND_LOCATION. iOS review should include Info.plist location usage keys, calls requesting when-in-use or always authorization, and unusual elevated entitlement use such as com.apple.locationd.preauthorized where observable. Because ATT&CK lists related sub-techniques for remote device management services and SS7 node impersonation, defenders should separate app-based location access from EMM/cloud-console tracking and telecom signaling exposure when scoping detections and response.

Likely telemetry

  • Mobile device inventory with OS version for Android and iOS
  • Mobile application inventory and app provenance
  • Android application manifest permissions, including foreground and background location permissions
  • iOS application Info.plist location usage keys and relevant entitlements where available
  • MDM/EMM policy state, compliance posture, and device-location feature configuration

Detection direction

  • Use DET0675 as the ATT&CK-linked detection strategy reference, but validate locally because the official technique object does not provide detection text.
  • Tune for unjustified or high-risk location access: apps requesting always-on or background location, apps with location permissions outside business need, and newly installed or sideloaded apps requesting location data.
  • Correlate permission findings with app reputation, installation source, device risk state, OS version, and network activity to reduce false positives from legitimate navigation, logistics, safety, or device-management use cases.
  • For iOS, review location usage declarations and elevated entitlement indicators where tooling can expose them; absence of visibility into iOS internals is a common blind spot.
  • For Android, ensure app manifest and runtime permission state are both assessed; manifest-only review may miss whether users granted access, while runtime-only review may miss latent capability.

Mitigation priorities

  • Keep mobile devices on recent Android and iOS versions, aligning with M1006, because newer OS versions add patches and security architecture improvements.
  • Use enterprise policy through EMM/MDM, aligning with M1012, to restrict risky app sources, govern location permissions, and enforce mobile compliance requirements where supported.
  • Provide user guidance, aligning with M1011, so users understand location prompts, background access requests, and risky app installation behavior.
  • Review and limit use of device-location features in EMM/MDM and cloud services to authorized roles with auditability.
  • Apply app vetting and privacy review before approving business apps that request location access, especially always-on or background location.
Analyst notes and limits

ATT&CK associates this technique with Android and iOS and with multiple campaigns, groups, and software entries, including mobile spyware and Android/iOS malware families. Those relationships show the behavior is observed across mobile threat reporting, but they do not by themselves prove current targeting of any specific organization. The parent technique covers app/API-based location access, while its sub-techniques expand the defensive scope to remote device-management services and SS7 impersonation.

The supplied ATT&CK object has no official detection text and no specified tactic. Detection recommendations therefore depend on local mobile-management visibility, app-vetting capability, OS telemetry, and audit logging. Some evidence, especially iOS entitlements or telecom signaling data, may not be available to a typical enterprise SOC without specialized tooling or provider cooperation.

Official MITRE ATT&CK definition

Location Tracking

Adversaries may track a device’s physical location through use of standard operating system APIs via malicious or exploited applications on the compromised device.

On Android, applications holding the `ACCESS_COAURSE_LOCATION` or `ACCESS_FINE_LOCATION` permissions provide access to the device’s physical location. On Android 10 and up, declaration of the `ACCESS_BACKGROUND_LOCATION` permission in an application’s manifest will allow applications to request location access even when the application is running in the background.[1] Some adversaries have utilized integration of Baidu map services to retrieve geographical location once the location access permissions had been obtained.[2][3]

On iOS, applications must include the `NSLocationWhenInUseUsageDescription`, `NSLocationAlwaysAndWhenInUseUsageDescription`, and/or `NSLocationAlwaysUsageDescription` keys in their `Info.plist` file depending on the extent of requested access to location information.[4] On iOS 8.0 and up, applications call `requestWhenInUseAuthorization()` to request access to location information when the application is in use or `requestAlwaysAuthorization()` to request access to location information regardless of whether the application is in use. With elevated privileges, an adversary may be able to access location data without explicit user consent with the `com.apple.locationd.preauthorized` entitlement key.[5]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

2 rows
Domain ID Name Relationship / procedure
Mobile T1430.001 Remote Device Management Services Sub-technique Remote Device Management Services subtechnique of this object.
Mobile T1430.002 Impersonate SS7 Nodes Sub-technique Impersonate SS7 Nodes subtechnique of this object.
Associated objects

Groups, software, and campaigns

Group Mobile

G0112: Windshift

Windshift is a threat group that has been active since at least 2017, targeting specific individuals for surveillance in government departments and critical infrastructure across the Middle East.[1][2][3]

Malware Mobile

S1094: BRATA

BRATA (Brazilian Remote Access Tool, Android), is an evolving Android malware strain, detected in late 2018 and again in late 2021. Originating in Brazil, BRATA was later also found in the UK, Poland, Italy, Spain, and USA, where it is believed to have targeted financial institutions such as banks. There are currently three known variants of BRATA.[1][2][3]

Android
Malware Mobile

S1069: TangleBot

TangleBot is SMS malware that was initially observed in September 2021, primarily targeting mobile users in the United States and Canada. TangleBot has used SMS text message lures about COVID-19 regulations and vaccines to trick mobile users into downloading the malware, similar to FluBot Android malware campaigns.[1]

Android
Malware Mobile

S1083: Chameleon

Chameleon is an Android banking trojan that can leverage Android’s Accessibility Services to perform malicious activities. Believed to have been first active in January 2023, Chameleon has been observed targeting users in Australia and Poland by masquerading as official applications. A new variant of Chameleon has expanded its targets to include Android users in the United Kingdom and Italy.[1][2]

Android
Malware Mobile

S0425: Corona Updates

Corona Updates is Android spyware that took advantage of the Coronavirus pandemic. The campaign distributing this spyware is tracked as Project Spy. Multiple variants of this spyware have been discovered to have been hosted on the Google Play Store.[1]

Android
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.2
Created
Modified
Raw hash
8bf08e700ecff761...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle 8bf08e700ecf…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Android Request Location Permissions

    Android Developers. (2022, March 24). Request Location Permissions. Retrieved April 1, 2022.

    Open source URL
  2. [2]
    PaloAlto-SpyDealer

    Wenjun Hu, Cong Zheng and Zhi Xu. (2017, July 6). SpyDealer: Android Trojan Spying on More Than 40 Apps. Retrieved September 18, 2018.

    Open source URL
  3. [3]
    Palo Alto HenBox

    A. Hinchliffe, M. Harbison, J. Miller-Osborn, et al. (2018, March 13). HenBox: The Chickens Come Home to Roost. Retrieved September 9, 2019.

    Open source URL
  4. [4]
    Apple Requesting Authorization for Location Services

    Apple Developers. (n.d.). Requesting Authorization for Location Services. Retrieved April 1, 2022.

    Open source URL
  5. [5]
    Google Project Zero Insomnia

    I. Beer. (2019, August 29). Implant Teardown. Retrieved June 2, 2020.

    Open source URL
  6. [6]
    NIST Mobile Threat Catalogue APP-24
    Open source URL
  7. [7]
    mitre-attack T1430
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.