AN1768: Analytic 1768
The defender correlates managed-app data access and lifecycle context with indirect evidence of packaging or encryption prior to outbound transfer. Because direct archive/compression visibility is generally weaker on iOS, the analytic anchors on app lifecycle state, file/output effects observable by mobile EDR where available, managed app role via MDM, and downstream network uploads that closely follow creation of new large or high-entropy local artifacts. Confidence is lower when only network effects are available.
Analyst context for executives and security teams
This analytic matters because it addresses a difficult mobile visibility problem: on iOS, defenders may not directly see archive, compression, or encryption activity before data leaves the device. The practical value is to correlate managed-app context, app lifecycle state, local artifact changes, and near-term outbound uploads to identify suspicious preparation and transfer of data from managed applications.
Executive priority
For security leaders, the priority is validating whether mobile security, MDM, and network monitoring provide enough evidence to support decisions during a suspected managed-app data loss event. This affects incident response confidence, compliance evidence for managed mobile data handling, and control investment decisions around iOS visibility. Because ATT&CK notes confidence is lower when only network effects are available, leaders should ask whether mobile investigations can connect app context, local file effects, and outbound transfer timing rather than relying on upload volume alone.
Technical view
For SOC, detection engineering, and IR teams, this analytic should be treated as a correlation use case for iOS managed applications. Validate whether the environment can correlate managed-app data access and app lifecycle state with mobile EDR-observable file or output effects, especially creation of new large or high-entropy local artifacts, followed closely by outbound network uploads. Tune expectations carefully: the supplied ATT&CK description states direct archive or compression visibility is generally weaker on iOS, so the analytic depends on indirect evidence and has reduced confidence when only network telemetry is available.
Likely telemetry
- MDM records identifying managed applications and their role or management status
- Managed-app data access context where available
- iOS app lifecycle state or foreground/background activity context
- Mobile EDR file or output-effect telemetry where available
- Metadata for newly created large local artifacts
Detection direction
- Validate that detection logic requires time-correlated evidence rather than treating any upload from an iOS device as suspicious.
- Prioritize correlations that include managed-app role, app lifecycle state, local artifact creation, and subsequent outbound upload activity.
- Flag lower-confidence cases separately when only downstream network effects are available, as ATT&CK explicitly notes confidence is weaker in that condition.
- Tune for expected managed-app workflows that legitimately create large files or upload data to reduce false positives.
- Assess blind spots where mobile EDR is absent, MDM context is incomplete, or network telemetry cannot be tied back to app and device context.
Mitigation priorities
- Confirm MDM accurately identifies managed applications and retains useful lifecycle and management context for investigations.
- Improve mobile EDR and network telemetry coverage where the organization depends on iOS devices for managed data access.
- Define IR procedures for triaging suspected managed-app data staging and outbound transfer using available MDM, mobile EDR, and network evidence.
- Use the analytic as a control-validation exercise: determine whether teams can reconstruct the sequence from managed-app activity to local artifact creation to outbound upload.
- Document telemetry limitations for audit and risk owners, especially where only network evidence is available.
Analyst notes and limits
This is a mobile ATT&CK detection analytic for iOS, external ID AN1768. No tactics, related techniques, or relationship context were supplied. The main decision value is not a single event match, but whether defenders can correlate weak iOS packaging visibility with managed-app context, artifact effects, and network uploads.
The official object provides a description but no separate official detection field and no relationships. This take does not infer specific adversaries, active exploitation, impacts, or guaranteed detection. Local device management, mobile EDR, and network logging capabilities will determine practical usefulness.
Analytic 1768
The defender correlates managed-app data access and lifecycle context with indirect evidence of packaging or encryption prior to outbound transfer. Because direct archive/compression visibility is generally weaker on iOS, the analytic anchors on app lifecycle state, file/output effects observable by mobile EDR where available, managed app role via MDM, and downstream network uploads that closely follow creation of new large or high-entropy local artifacts. Confidence is lower when only network effects are available.
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 | 309cc8f975e9… |
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 AN1768Open 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.