AN1649: Analytic 1649
Defender correlates an app querying device model and iOS version (often limited to UIDevice-visible attributes) with subsequent behavior divergence (capability gating, alternate code paths) and/or near-term outbound connections, suggesting device fingerprinting for decision-making rather than normal telemetry.
Analyst context for executives and security teams
This mobile detection analytic matters because it focuses on iOS apps that appear to use device model and iOS version information to make decisions, such as changing behavior or initiating outbound connections soon afterward. For leaders, the value is not that querying device attributes is automatically malicious; it is that behavior-based correlation can help distinguish routine app telemetry from possible environment-aware or fingerprinting behavior that may affect mobile security, privacy, compliance evidence, and incident triage.
Executive priority
Prioritize this as a validation point for mobile security monitoring and app-risk governance on iOS. Security leaders should ask whether the organization can see enough app behavior, network activity, and device context to explain why an app queries device model or iOS version and what it does next. The business decision is whether current mobile telemetry supports confident triage, audit defensibility, and incident response for potentially environment-aware mobile app behavior.
Technical view
AN1649 is an iOS-focused detection analytic. It describes correlating an app querying device model and iOS version, often through UIDevice-visible attributes, with later behavior divergence such as capability gating, alternate code paths, or near-term outbound connections. SOC and detection teams should validate whether their mobile telemetry can link app-level device attribute access to subsequent behavioral changes and network events. Because no official detection logic or relationships are supplied, implementation should be treated as a hypothesis-driven correlation rather than a standalone alert rule.
Likely telemetry
- iOS app behavior telemetry showing access to device model and iOS version attributes
- Mobile application runtime or instrumentation logs, where available
- Outbound network connection metadata from the mobile device or app
- App execution context sufficient to correlate attribute queries with later behavior
- Mobile device management or endpoint/mobile security telemetry for installed app identity and device context
Detection direction
- Correlate device model and iOS version queries with near-term outbound connections or observable changes in app behavior.
- Treat the attribute query alone as low-confidence because many legitimate apps collect device and OS information for compatibility, diagnostics, or analytics.
- Tune around expected app behavior, approved telemetry collection, and known application compatibility checks to reduce false positives.
- Look for timing and sequence: device attribute query followed by capability gating, alternate code paths, or network activity is more meaningful than isolated access.
- Document telemetry gaps, especially where iOS privacy controls or limited mobile instrumentation prevent visibility into app internals.
Mitigation priorities
- Establish an inventory of approved iOS apps and expected data collection behavior.
- Use mobile security, MDM, or app governance controls to assess whether apps request or use device and OS attributes in ways consistent with business need.
- Prioritize review of apps where device fingerprinting-like behavior is paired with unexplained outbound connections or behavior divergence.
- Ensure incident response playbooks include mobile app evidence collection, network context, device state, and app identity.
- Maintain compliance evidence showing how mobile app telemetry, privacy expectations, and app-risk decisions are reviewed.
Analyst notes and limits
This object is a detection analytic, not a technique description. It is most useful as guidance for building or validating a mobile correlation analytic on iOS. The key analytic judgment is separating normal compatibility or telemetry behavior from device fingerprinting used for decision-making. Local baselines and app-specific context are essential.
The supplied ATT&CK object provides no official detection implementation, no tactics, no relationships, and only one supported platform: iOS. It does not identify adversaries, campaigns, impact, or active exploitation. Any production detection requires local telemetry validation and environment-specific tuning.
Analytic 1649
Defender correlates an app querying device model and iOS version (often limited to UIDevice-visible attributes) with subsequent behavior divergence (capability gating, alternate code paths) and/or near-term outbound connections, suggesting device fingerprinting for decision-making rather than normal telemetry.
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 | a6fbee094768… |
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 AN1649Open 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.