AN1729: Analytic 1729
Correlates (1) application possession and use of location authorization sufficient for ongoing geographic evaluation, (2) repeated location or region-monitoring behavior with limited visible feature activation outside target area, and (3) abrupt onset of network communication, background execution, or feature activation only after a qualifying location context is reached. Because direct visibility into every geofence callback is often weaker on iOS, the defender relies more heavily on the combination of location authorization state, repeated location access, app state transition, and downstream behavior that begins after region alignment.
Analyst context for executives and security teams
AN1729 is a mobile detection analytic for iOS behavior where an app appears to use location permission and repeated location or region monitoring, then starts network activity, background execution, or feature activation only after the device reaches a qualifying location context. For leaders, the significance is not just “location access”; it is whether mobile apps can change behavior based on where an employee, executive, or operational device is located, creating privacy, security, and potentially site-sensitive risk that may be hard to see directly on iOS.
Executive priority
Prioritize this analytic where iOS devices are used by executives, privileged staff, field teams, or personnel entering sensitive facilities. The business question is whether mobile security, privacy governance, and incident response processes can identify apps whose behavior materially changes after location alignment. This supports decisions about mobile app approval, location permission policy, managed device telemetry, and evidence needed for privacy or compliance reviews. Because ATT&CK provides no relationship context or tactic mapping here, treat this as a defensive validation area rather than proof of a specific campaign or impact.
Technical view
SOC, mobile security, and IR teams should validate whether they can correlate four evidence areas on iOS: location authorization state, repeated location access or region-monitoring indicators, app state transitions/background execution, and downstream behavior such as network communication or feature activation that begins only after a location condition is met. The analytic explicitly notes that direct visibility into every iOS geofence callback may be weak, so detection should rely on behavioral correlation rather than a single event. Tuning should distinguish legitimate location-based features from suspicious cases where visible user-facing functionality is limited outside the target area and activity begins abruptly after location context changes.
Likely telemetry
- iOS app location authorization state and permission changes
- Repeated location access or region-monitoring-related signals where available
- Application foreground/background state transitions
- Background execution indicators
- Network communication timing and destination metadata for mobile apps
Detection direction
- Validate that telemetry can correlate app permissions, repeated location use, app state changes, and post-location network or feature activity over time.
- Account for the stated iOS blind spot: direct geofence callback visibility may be limited, so avoid relying on a single callback event as the detection requirement.
- Tune for legitimate location-aware applications by comparing expected visible features and user activity against abrupt background or network behavior after location alignment.
- Investigate apps with sufficient ongoing location authorization that show limited visible functionality until a qualifying location context is reached.
- Because no official detection logic is provided, document local assumptions, required data sources, and false-positive handling before operationalizing this analytic.
Mitigation priorities
- Review which iOS apps are allowed to hold ongoing location authorization, especially on managed or high-risk devices.
- Apply least-privilege mobile permission governance for location access where business need is not clear.
- Use managed mobile device policies and app approval processes to reduce unvetted apps with persistent location capability.
- Ensure incident response playbooks include collection and review of app permission state, app activity timing, background execution, and network behavior.
- For compliance and privacy readiness, retain evidence showing how location permissions and mobile app behavior are reviewed and governed.
Analyst notes and limits
This object is a detection analytic in the mobile ATT&CK domain for iOS. It provides a detailed behavioral description but no official detection block, no tactics, and no relationship context. The most useful defender action is therefore telemetry validation and correlation design, not assertion of existing coverage or threat attribution.
Analysis is limited to the supplied ATT&CK fields and external reference. No active exploitation, adversary use, related techniques, specific tools, data components, or mitigations were supplied. Local iOS management capabilities and available mobile telemetry will determine whether this analytic is practical to implement.
Analytic 1729
Correlates (1) application possession and use of location authorization sufficient for ongoing geographic evaluation, (2) repeated location or region-monitoring behavior with limited visible feature activation outside target area, and (3) abrupt onset of network communication, background execution, or feature activation only after a qualifying location context is reached. Because direct visibility into every geofence callback is often weaker on iOS, the defender relies more heavily on the combination of location authorization state, repeated location access, app state transition, and downstream behavior that begins after region alignment.
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 | ce439ad5886f… |
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 AN1729Open 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.