AN1767: Analytic 1767
The defender correlates recent access to locally collected or protected data with subsequent compression, packaging, or encryption behavior inside the same app context, followed by creation of archive-like or high-entropy output and optional near-term network transmission. The analytic prioritizes Android runtime and storage effects: application data access or sensor-derived collection, compression/encryption framework use, archive/blob creation in app-accessible storage, and background or device-locked execution inconsistent with the app’s declared function.
Analyst context for executives and security teams
This analytic matters because it focuses on a common mobile data-risk pattern: an Android app accesses locally collected or protected data, then compresses, packages, or encrypts it into an archive-like or high-entropy output, with possible near-term network transmission. For leaders, the value is not just detecting a file operation; it is validating whether mobile monitoring can connect data access, local staging, background execution, and outbound activity inside the same app context before sensitive information leaves the device.
Executive priority
Prioritize this where Android devices handle regulated, operational, or sensitive business data. The key decision is whether the organization has enough mobile telemetry and policy control to prove that protected data access, local packaging, and possible transmission can be investigated. This supports incident response readiness, compliance evidence for mobile data handling, and risk decisions around approved app behavior, especially when background or device-locked activity is inconsistent with the app’s declared function.
Technical view
SOC and detection teams should validate correlation across Android runtime and storage effects: recent access to locally collected or protected data, use of compression or encryption frameworks, creation of archive-like blobs or high-entropy outputs in app-accessible storage, and optional network transmission shortly afterward. The analytic is scoped to Android and app-context behavior. Because no official detection logic is provided, teams should treat this as a detection design pattern requiring local data sources, baselining of legitimate app behavior, and tuning around apps that normally compress, encrypt, back up, or sync data.
Likely telemetry
- Android application runtime events showing data access or sensor-derived collection
- File and storage events for archive-like files, blobs, or high-entropy outputs in app-accessible storage
- Indicators of compression, packaging, or encryption framework use within an app context
- App execution context, including background or device-locked activity
- Mobile network telemetry showing near-term transmission after local packaging activity
Detection direction
- Correlate events within the same Android app context rather than alerting on isolated compression or encryption activity.
- Tune against legitimate apps that routinely package, encrypt, back up, or synchronize data to reduce false positives.
- Validate whether telemetry preserves timing: data access followed by packaging/encryption and optional transmission within a near-term window.
- Prioritize suspicious cases where background or device-locked execution is inconsistent with the app’s declared function.
- Assess blind spots from limited mobile endpoint visibility, lack of app-context attribution, missing file entropy/archive indicators, or absent network correlation.
Mitigation priorities
- Inventory Android apps that access sensitive, locally collected, protected, or sensor-derived data.
- Enforce mobile app governance and permissions consistent with business need and declared app function.
- Ensure mobile security monitoring can collect runtime, storage, execution-state, and network evidence needed for this correlation.
- Define incident response playbooks for suspicious app-context data staging and potential transmission events.
- Use compliance and risk reviews to verify that mobile data handling controls produce auditable evidence, not only policy statements.
Analyst notes and limits
This object is a MITRE ATT&CK mobile detection analytic, AN1767, for Android. It provides a behavioral description but no official detection logic and no relationship context. The strongest use is as a validation checklist for mobile telemetry coverage and correlation quality.
No tactics, relationships, aliases, labels, or official detection content were supplied. The object does not identify specific malware, threat actors, active exploitation, or guaranteed detection outcomes. Local app baselines, Android management architecture, and available telemetry determine practical coverage.
Analytic 1767
The defender correlates recent access to locally collected or protected data with subsequent compression, packaging, or encryption behavior inside the same app context, followed by creation of archive-like or high-entropy output and optional near-term network transmission. The analytic prioritizes Android runtime and storage effects: application data access or sensor-derived collection, compression/encryption framework use, archive/blob creation in app-accessible storage, and background or device-locked execution inconsistent with the app’s declared function.
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 | f0bb3a9d2bc4… |
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 AN1767Open 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.