AN1777: Analytic 1777
Defender correlates an application’s location authorization level (When-In-Use vs Always) and entitlement posture with observed location sensor activity that occurs without proximate user interaction, including background updates, followed by periodic outbound network sessions aligned to location update timing—suggesting covert or policy-violating location tracking.
Analyst context for executives and security teams
This analytic matters because location access on iOS can create privacy, compliance, and trust risk when an application uses location sensors in the background without clear user interaction. For leaders, the key decision value is whether the organization can prove that mobile apps with location permissions are behaving consistently with policy, consent, and business need—especially when location updates are followed by network activity that may indicate reporting of location data.
Executive priority
Prioritize this as a mobile privacy and governance control validation issue. Security, privacy, and compliance leaders should ask whether managed iOS devices, enterprise apps, or approved third-party apps are monitored for excessive or policy-violating location use, and whether incident responders can distinguish legitimate background location functions from suspicious tracking behavior. The risk is less about a named adversary in the supplied data and more about readiness to investigate covert or noncompliant location collection that could affect employee privacy, regulatory evidence, or executive/mobile device risk decisions.
Technical view
For SOC, mobile security, and IR teams, the analytic is centered on correlating three evidence points on iOS: an application’s location authorization level, its entitlement posture, and observed location sensor activity occurring without proximate user interaction. The higher-value signal is background or non-interactive location activity followed by periodic outbound network sessions that align with the timing of location updates. Because no ATT&CK detection text or relationships are supplied, teams should treat this as a validation pattern rather than a complete rule: confirm the data sources exist, define what counts as proximate user interaction, baseline legitimate background location behavior, and review apps whose authorization level or entitlement posture does not justify observed activity.
Likely telemetry
- iOS application location authorization state, including When-In-Use versus Always permission levels
- Application entitlement information related to location access
- Location sensor activity or background location update events
- User interaction or foreground/background application state context near the time of location access
- Outbound network session timing and destination metadata from the device or managed mobile environment
Detection direction
- Validate that telemetry can correlate location permission level, entitlement posture, sensor activity, app foreground/background state, and outbound network timing for the same iOS application.
- Tune detections around location sensor activity without proximate user interaction, especially when followed by periodic network sessions aligned to location update timing.
- Baseline legitimate apps that require background location, such as navigation, safety, logistics, or device management use cases, to reduce false positives.
- Investigate mismatches between authorization level, entitlement posture, and behavior, such as apps with limited expected need for location performing recurring background updates.
- Account for blind spots where iOS privacy controls, mobile management tooling, or network visibility do not expose sufficient app-level context.
Mitigation priorities
- Establish or review mobile app location-access policy for managed iOS devices, including when Always authorization is acceptable.
- Limit approved apps to those with justified business need for location access and review entitlement posture during mobile app approval or procurement.
- Use mobile device management or equivalent governance processes to monitor, restrict, or review location permissions where supported.
- Require privacy and security review for enterprise apps that collect background location data and transmit it over the network.
- Ensure incident response playbooks include steps to preserve mobile app permission state, entitlement information, sensor activity context, and network timing evidence.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for iOS in the mobile domain. Its value is in the correlation logic: location authorization and entitlement posture plus non-interactive location activity plus periodic outbound network sessions. The object does not provide tactics, relationships, official detection logic, adversary attribution, or confirmed exploitation context, so conclusions should remain focused on defensive validation and governance.
This take is limited to the official STIX fields, external reference, and supplied context. No relationships, tactics, labels, aliases, or official detection implementation were provided. Local mobile management capabilities, iOS logging availability, network visibility, app inventory, and privacy policy requirements will determine whether this analytic can be operationalized.
Analytic 1777
Defender correlates an application’s location authorization level (When-In-Use vs Always) and entitlement posture with observed location sensor activity that occurs without proximate user interaction, including background updates, followed by periodic outbound network sessions aligned to location update timing—suggesting covert or policy-violating location tracking.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 900afd65f280… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1777Open source URL
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.