AN1851: Analytic 1851
Defender correlates a sandboxed app writing high-entropy or encoded artifacts (often in app-private or shared storage), performing decode/decompress/reassembly, then dynamically loading/execing the resulting code (DexClassLoader/JNI dlopen) or spawning a helper process. Sequence: high-entropy file writes → decode/unpack bursts → new .dex/.so/.jar creation in temp/obfuscated paths → dynamic load or shell spawn within a tight window.
Analyst context for executives and security teams
This analytic matters because it describes a mobile pattern where an Android app appears to unpack or assemble hidden code at runtime and then load it or execute a helper process. For leaders, the decision value is whether mobile security monitoring can distinguish normal app behavior from risky runtime code creation and loading, especially on devices or apps that support business operations, regulated workflows, or privileged access.
Executive priority
Prioritize this as a mobile application and device-risk validation item, not as proof of compromise by itself. Executives and security leaders should ask whether Android fleet monitoring, mobile app vetting, and incident response playbooks can produce evidence for high-entropy file creation, unpacking behavior, new executable artifacts, dynamic loading, and process spawning. The main business issue is readiness: if telemetry is missing, teams may be unable to assess suspicious Android app behavior during an incident or compliance review.
Technical view
For Android, validate whether SOC and mobile IR workflows can correlate the described sequence within a tight time window: high-entropy or encoded artifact writes by a sandboxed app, decode/decompress/reassembly activity, creation of new .dex, .so, or .jar files in temporary or obfuscated paths, followed by DexClassLoader, JNI dlopen, or helper-process execution. Because no ATT&CK detection text or relationships are supplied, this should be treated as an analytic pattern to test against local telemetry rather than a complete detection rule.
Likely telemetry
- Android application file-write events, especially app-private and shared-storage paths
- File metadata for newly created .dex, .so, .jar, temporary, or obfuscated-path artifacts
- Entropy or encoding indicators for written artifacts, where available
- Application behavior showing decode, decompress, or reassembly bursts
- Runtime dynamic loading evidence such as DexClassLoader use or JNI dlopen activity
Detection direction
- Validate that telemetry can correlate file creation, unpacking, and dynamic loading by the same Android app identity within a tight time window.
- Tune carefully for legitimate Android apps that unpack resources, use plugins, or load native libraries, since the supplied analytic describes a suspicious sequence rather than a standalone verdict.
- Prioritize correlation over single indicators: high entropy alone, new files alone, or dynamic loading alone may be noisy without the sequence context.
- Check blind spots around app-private storage, shared storage, temporary paths, and visibility into dynamic loading or process creation events.
- Use this analytic as a coverage test for mobile detection engineering because the official detection field is not provided.
Mitigation priorities
- Establish or validate Android mobile telemetry collection for app file activity, dynamic code loading, and process spawning where permitted by the environment.
- In mobile app governance, review whether business-critical or internally distributed Android apps have legitimate reasons to create and load new code at runtime.
- Strengthen mobile incident response procedures so analysts can preserve app artifacts, paths, timestamps, and process evidence needed to reconstruct the sequence.
- Apply least-privilege and app control policies appropriate to the Android fleet to reduce exposure from untrusted or unnecessary applications.
- Document monitoring limits as compliance and risk evidence, especially where Android devices support sensitive workflows.
Analyst notes and limits
This object is a MITRE ATT&CK mobile detection analytic for Android, external ID AN1851. It provides a behavioral sequence but no ATT&CK tactics, relationships, aliases, or official detection text. The strongest use is as a validation checklist for mobile telemetry and correlation logic.
The supplied fields do not identify adversaries, active exploitation, prevalence, impact, or specific mitigations. No relationship context is available, and the official detection field is absent. Local Android device management, EDR/MDM capability, app inventory, and logging constraints will determine whether this can be detected reliably.
Analytic 1851
Defender correlates a sandboxed app writing high-entropy or encoded artifacts (often in app-private or shared storage), performing decode/decompress/reassembly, then dynamically loading/execing the resulting code (DexClassLoader/JNI dlopen) or spawning a helper process. Sequence: high-entropy file writes → decode/unpack bursts → new .dex/.so/.jar creation in temp/obfuscated paths → dynamic load or shell spawn within a tight window.
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 | ab0650259b16… |
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 AN1851Open 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.