Location Tracking (T1430) is an adversary learning where a phone, and so its owner, is, either from malware on the device, from a stolen account on a device management service, or from the mobile network's own signalling. MITRE ATT&CK for Mobile v20 lists T1430 under both Collection and Discovery for Android and iOS, with two sub-techniques: Remote Device Management Services (T1430.001) and Impersonate SS7 Nodes (T1430.002). Each of the three routes needs a different owner: the mobile team for on-device permissions, the identity team for device management accounts, and the carrier for signalling. This guide is for mobile security, identity and SOC teams; it goes deeper than the MITRE ATT&CK for Mobile Guide and focuses on detection, prevention and response.
Key takeaways
- Three routes, three owners. On-device APIs (T1430), device management consoles and cloud locator services (T1430.001) and SS7 signalling (T1430.002) need separate controls.
- Background location is the signal. Android 10 and later require
ACCESS_BACKGROUND_LOCATION, and iOS separates When in Use from Always authorisation. An app that wants location all the time needs a reason. - Device management accounts are a tracking tool. ATT&CK names Google's device manager, Apple's Find My and enterprise MDM consoles. Protect those accounts with strong MFA and least privilege.
- BYOD enrolment modes limit enterprise visibility by design. ATT&CK notes that Apple User Enrollment and Android profile owner mode prevent the enterprise from accessing the device's physical location.
- Signalling attacks sit outside the device. ATT&CK's mitigation for T1430.002 is Interconnection Filtering (M1014), which is a carrier control; enterprises influence it through carrier selection and contracts.
The three routes at a glance
| Route | ATT&CK ID | What the adversary needs | Primary control owner |
|---|---|---|---|
| Malicious or exploited app using OS location APIs | T1430 | Location permission granted by the user, or elevated privileges | Mobile and MDM team |
| Cloud locator service or MDM console | T1430.001 | Credentials or session for a Google account, Apple Account or MDM administrator account | Identity team and MDM administrators |
| Signalling network queries | T1430.002 | Access to SS7 interconnect and the victim's phone number (MSISDN) | Mobile network operator |
On-device tracking: how each platform gates location
ATT&CK describes T1430 as tracking a device's physical location through standard operating system APIs via malicious or exploited applications. Both platforms gate this with permissions that distinguish precision and background use.
| Control | Android | iOS |
|---|---|---|
| Permission or key | ACCESS_COARSE_LOCATION (approximate) or ACCESS_FINE_LOCATION (precise) | NSLocationWhenInUseUsageDescription required for any request; NSLocationAlwaysAndWhenInUseUsageDescription required for Always |
| Background access | Android 10 and later: ACCESS_BACKGROUND_LOCATION must be declared; on earlier versions foreground access also gave background access | Always authorisation lets the system launch the app for significant location changes, visits and region monitoring |
| Extra friction | Android 11 and later: "Allow all the time" is not offered in the prompt; the user must select it on the settings page (per ATT&CK) | An app with When in Use can ask for Always once, in a separate request |
| Precision | Android 12 and later: users can grant approximate location only; Android documents approximate as about 3 square kilometres | iOS 14 and later: users choose whether to give Precise Location per app (per ATT&CK) |
Two points matter for defenders. First, a permission prompt is the main barrier for commodity malware, so app source restrictions and permission review do most of the work. Second, ATT&CK notes that with elevated privileges an adversary may access location data on iOS without explicit user consent using the com.apple.locationd.preauthorized entitlement, citing Google Project Zero's analysis of the INSOMNIA implant. Privileged spyware does not need the prompt.
Procedure examples in ATT&CK v20 show the range. TriangleDB (S1216), used in Operation Triangulation (C0054), monitored geolocation including coordinates, altitude, bearing and speed; Kaspersky reported that by default this command worked only while the screen was off. Pegasus for iOS (S0289) sends the phone's location, Hornbill (S1077) only logs location changes greater than 70 metres, FrozenCell (S0577) used an online cell tower geolocation service, and Adups (S0309), pre-installed software, transmitted location information. Banking malware such as Cerberus (S0480) and Chameleon (S1083) also collects location. See the Mobile App Permissions guide for permission governance.
T1430.001 Remote Device Management Services
ATT&CK describes an adversary using access to cloud services such as Google's Android device manager or Apple iCloud's Find My iPhone, or to an EMM or MDM console, to track the location of devices managed by that service. No malware is needed: the adversary uses a legitimate feature with stolen access.
- Consumer accounts: ATT&CK's mitigation is User Guidance (M1011): protect account credentials and enable MFA. For staff who face targeted threats, help them secure personal Apple and Google accounts. See the Securing Your Apple ID and Google Account Guide.
- MDM consoles: treat location features as privileged. Limit which administrator roles can view device location, require phishing-resistant MFA for those roles and review console audit logs for location lookups. See the Mobile Device Management Security Guide.
- Enrolment mode: ATT&CK's Enterprise Policy (M1012) note says Apple User Enrollment and Android profile owner enrolment prevent the enterprise from accessing the device's physical location, which is why they suit BYOD.
ATT&CK detection strategy DET0702 correlates cloud service audit telemetry and identity provider sign-in events with device management state, so the practical detection is in your IdP and MDM audit logs: an unusual sign-in to an administrator account followed by device location queries.
T1430.002 Impersonate SS7 Nodes
ATT&CK describes adversaries exploiting the lack of authentication in signalling system network nodes: by providing the victim's MSISDN and impersonating internal network nodes, they query subscriber information and work out the device's cell area or nearest cell tower. The device itself shows nothing. Citizen Lab's December 2020 report on Circles (S0602), a firm affiliated with NSO Group, identified Circles deployments in at least 25 countries and described it as reportedly exploiting weaknesses in the global mobile phone system to monitor calls, texts and phone locations.
- Mitigation: Interconnection Filtering (M1014), where the operator filters signalling requests by checking their origin. This sits with the carrier.
- Enterprise levers: ask carriers how they filter SS7 and Diameter signalling, prefer services that keep sensitive communication in end-to-end encrypted apps over the data channel, and limit how widely high-risk users' numbers are published.
See the SS7 and Diameter Signalling Security Guide and the Mobile Communications Protection for High-Risk Individuals Guide.
Detection: ATT&CK v20 analytics
| Detection strategy | Platform | Evidence ATT&CK correlates |
|---|---|---|
| DET0675 Detection of Location Tracking | Android | Dynamic analysis showing LocationManager.requestLocationUpdates() called with a short update interval by an app not on the location allowlist; permission grant state from the device policy controller; proxy or gateway traffic |
| DET0675 Detection of Location Tracking | iOS | Code-signing entitlements and Info.plist privacy keys in app vetting; Network Extension, per-app VPN or gateway flow metadata |
| DET0702 Detection of Remote Device Management Services | Android, iOS | Cloud service audit and API telemetry; identity provider sign-in and audit events; device management state |
| DET0662 Detection of Impersonate SS7 Nodes | Android, iOS | Network flow and content evidence from managed network logging, VPN and gateways; in practice most signalling evidence sits with the operator |
On Android Enterprise, network activity logging gives a device owner (Android 8.0 and later) or the profile owner of a work profile (Android 12 and later) DNS and TCP connection events with the package name, which helps tie unexpected uploads to an app.
Where identity fits
T1430.001 is an identity problem. The accounts that can locate devices include human Apple and Google accounts, MDM administrator accounts and the API credentials that integrations use to query the MDM. Inventory those API clients and service accounts, scope them so integrations that do not need location cannot read it, rotate their secrets and alert on use from new sources. See the API Key Management Guide.
How to implement
- Map the routes: list apps with location permission on managed devices, every console and API client that can read device location, and your carriers.
- Audit first: report apps holding background or precise location without a recorded business need, and administrator roles that can view location, for two to four weeks before enforcing.
- Enforce in rings: deny location permissions to unapproved managed apps and narrow console roles for a pilot group; widen once exceptions are handled. Roll back by removing the policy, which restores the earlier grant state.
- Harden accounts: require phishing-resistant MFA on MDM administrator roles and help high-risk staff secure personal locator accounts.
- Engage carriers: add signalling security questions to carrier reviews and contracts.
Decision guidance
- Corporate-owned versus BYOD: on corporate-owned devices you can enforce permission states and may need location for lost device recovery; use it under a written policy. On BYOD, prefer User Enrollment or a work profile so the enterprise cannot see location at all.
- Small organisations: focus on official app stores, MFA on the MDM console and a short user guide on reviewing location permissions.
- Large or high-risk organisations: add MTD, network logging, console audit alerting and a high-risk user programme that covers signalling exposure.
Detection and measurement
- Background location ratio: share of managed apps with background or Always location that are on the approved list.
- Console location lookups: number of device location queries per administrator per month, with outliers reviewed.
- MFA strength on console roles: percentage of MDM administrators using phishing-resistant MFA (target 100 percent).
- OS currency: percentage of devices on a supported OS within the patch deadline.
- Carrier assurance: carriers that have answered signalling security questions.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK for Mobile | T1430, T1430.001, T1430.002; M1006, M1011, M1012, M1014 | Technique, sub-techniques and mitigations |
| NIST SP 800-53 Rev. 5 | AC-19 Access Control for Mobile Devices; IA-2 Identification and Authentication; AU-6 Audit Record Review | Device restrictions, administrator authentication, console audit review |
| NIST CSF 2.0 | PR.AA-03; DE.CM-09 | Authentication of users and services; monitoring of devices and software |
| OWASP MASVS | MASVS-PRIVACY | For in-house apps: request only the location precision and duration needed |
Common failure patterns
- Location left open in the MDM console: every help desk role can locate every device, so one compromised account tracks the whole fleet.
- Approving Always location by default: apps that need location only during use keep background access because nobody reviewed it.
- Ignoring personal locator accounts: a senior executive's Apple or Google account with weak MFA tracks their phone as well as any malware would.
- Assuming the device will show signalling attacks: SS7 tracking leaves nothing on the handset, so device tools cannot rule it out.
- Integration credentials with full scope: an MDM API client built for inventory can also read location.
Practitioner checklist
- List managed apps with precise, background or Always location and reconcile against an approved list.
- Restrict device location lookups in the MDM console to named roles and audit them.
- Require phishing-resistant MFA for MDM administrators.
- Scope MDM API clients so only those that need location can read it, and rotate their secrets.
- Use User Enrollment or Android work profiles for BYOD.
- Enable Android Enterprise network logging or managed VPN telemetry where policy allows.
- Ask carriers how they filter signalling traffic.
- Give high-risk staff guidance on securing personal locator accounts.
Standards and references
- MITRE ATT&CK: Location Tracking (T1430)
- MITRE ATT&CK: Remote Device Management Services (T1430.001)
- MITRE ATT&CK: Impersonate SS7 Nodes (T1430.002)
- Android Developers: Request location permissions
- Apple Developer: Requesting authorization to use location services
- Android Developers: Network activity logging
- Citizen Lab: Running in Circles
- Kaspersky Securelist: Dissecting TriangleDB, a Triangulation spyware implant
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Location Data Privacy Guide · T1614 System Location Discovery · Commercial Spyware Guide