AN1664: Analytic 1664
The defender correlates repeated retrieval-oriented communication from a supervised device or managed iOS app to a legitimate public web-service platform where the activity remains primarily inbound and does not produce corresponding writeback to that same service class during the operational window. The strongest iOS evidence is managed-app or device-attributed communication to collaboration, social, messaging, storage, or generic HTTPS platforms where inbound fetches or content pulls recur during background refresh, while the device is locked, or without recent user interaction, and no matching POST, upload, update, or message-send activity to that same public service class is observed. Because direct local runtime visibility is weaker than Android, the primary analytic is anchored on network directionality plus supervised managed-app and device-state context.
Analyst context for executives and security teams
AN1664 is an iOS-focused detection analytic for spotting managed or supervised devices that repeatedly pull data from legitimate public web services without corresponding user-driven or writeback activity. For leaders, the value is not that the service is malicious, but that unusual inbound-only retrieval patterns can expose gaps in mobile device visibility, managed-app monitoring, and incident triage for corporate iOS fleets.
Executive priority
Prioritize this where supervised iOS devices or managed apps handle business communications, collaboration, messaging, or cloud storage. The key business question is whether the organization can prove what managed mobile apps contacted, whether activity occurred while locked or in background refresh, and whether SOC or IR teams can distinguish normal sync behavior from suspicious repeated retrieval. This supports mobile security assurance, incident response readiness, and audit evidence for managed-device controls.
Technical view
Validate coverage for iOS network directionality and managed-device context. The analytic depends on correlating repeated inbound fetches or content pulls to legitimate public web-service classes—collaboration, social, messaging, storage, or generic HTTPS—with the absence of matching POST, upload, update, or message-send activity during the same operational window. Because the object notes weaker direct local runtime visibility on iOS than Android, detection should rely on supervised-device attribution, managed-app context, device-state signals such as locked state or background refresh, and network metadata rather than assuming endpoint-runtime evidence is available.
Likely telemetry
- Supervised iOS device inventory and device attribution
- Managed iOS app identity or app-to-network attribution
- Network connection metadata for public web-service platforms
- Directionality indicators distinguishing inbound fetch/content pull from writeback activity
- HTTP/HTTPS metadata where available, including method-like evidence such as POST/upload/update indicators
Detection direction
- Confirm that telemetry can separate retrieval-oriented inbound activity from writeback activity to the same public service class.
- Baseline normal managed-app sync, background refresh, and notification-related fetch behavior to reduce false positives.
- Tune by operational window, device state, app identity, and service class rather than by domain reputation alone, since the described platforms are legitimate public services.
- Validate blind spots from iOS visibility limits, especially where unmanaged apps, unsupervised devices, encrypted traffic, or missing app attribution prevent confident correlation.
- Use the analytic as a triage signal requiring context, not as standalone proof of malicious activity.
Mitigation priorities
- Ensure corporate iOS devices requiring this visibility are supervised and enrolled in appropriate management controls.
- Require managed-app controls and inventory so network activity can be attributed to business-relevant apps and devices.
- Preserve network and device-state telemetry needed for incident review and compliance evidence.
- Define SOC runbooks for repeated inbound-only mobile service access, including checks for user interaction, background refresh, and expected app behavior.
- Review mobile security architecture where encrypted traffic, unmanaged devices, or limited logging prevent defensible investigation.
Analyst notes and limits
No ATT&CK tactics, technique relationships, or explicit detection text were supplied beyond the analytic description. The analytic is most useful as a validation pattern for mobile SOC and IR readiness: can teams correlate iOS managed-app communication, service class, directionality, and device state over time?
This take is limited to the supplied AN1664 STIX fields and external reference. It does not establish adversary use, impact, attribution, or guaranteed detection. Local baselines are required because legitimate iOS background refresh and app synchronization may look similar without managed-app and device-state context.
Analytic 1664
The defender correlates repeated retrieval-oriented communication from a supervised device or managed iOS app to a legitimate public web-service platform where the activity remains primarily inbound and does not produce corresponding writeback to that same service class during the operational window. The strongest iOS evidence is managed-app or device-attributed communication to collaboration, social, messaging, storage, or generic HTTPS platforms where inbound fetches or content pulls recur during background refresh, while the device is locked, or without recent user interaction, and no matching POST, upload, update, or message-send activity to that same public service class is observed. Because direct local runtime visibility is weaker than Android, the primary analytic is anchored on network directionality plus supervised managed-app and device-state context.
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 | 33f5b10f3526… |
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 AN1664Open 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.