AN1722: Analytic 1722
From the defender view: a sandboxed app handles a high-entropy executable blob, performs rapid decode/decrypt in memory (often with RW→RX or execmem friction), optionally emits a transient .dex/.so into app-writable paths, then immediately loads/executes it (DexClassLoader/dlopen) or spawns a helper. We correlate: (1) opaque blob write/arrival → (2) decode/unpack or memory protection change → (3) new code artifact or byte[] class definition → (4) dynamic load/exec within a tight window.
Analyst context for executives and security teams
This analytic matters because it describes a mobile app behavior pattern consistent with unpacking and running code only at runtime: an Android app receives or writes an opaque high-entropy blob, rapidly decodes or decrypts it in memory, may create a short-lived .dex or .so file, and then dynamically loads or executes it. For leaders, the decision value is whether mobile security monitoring can see beyond static app reputation and identify runtime code-loading behavior that may evade pre-deployment review.
Executive priority
Prioritize this as a mobile application runtime visibility and incident readiness question. If Android devices or apps are material to business operations, executives should ask whether SOC, MDM/mobile security, and incident response teams can collect evidence of dynamic code loading, transient executable artifacts, and suspicious memory permission changes. This is especially relevant for compliance evidence and risk decisions where mobile apps handle sensitive data, because static scanning alone may not prove that runtime behavior is controlled or observable.
Technical view
For Android, validate whether telemetry can correlate the sequence described by the analytic: opaque blob arrival or write, rapid decode/unpack activity or memory protection change, creation of a new code artifact or byte-array class definition, and immediate dynamic load or execution using mechanisms such as DexClassLoader, dlopen, or helper process spawning. Because no official detection logic is supplied, teams should treat this as a detection design pattern rather than a ready rule. Focus on timing correlation, app-writable paths, transient .dex/.so artifacts, executable memory transitions, and dynamic loader activity inside sandboxed app context.
Likely telemetry
- Android application file writes, especially app-writable paths and transient .dex or .so artifacts
- Signals of high-entropy or opaque blob arrival or storage
- Runtime decode, decrypt, or unpack activity observable through endpoint/mobile instrumentation
- Memory protection or executable memory events, including RW-to-RX or execmem-related behavior where available
- Dynamic code loading events such as DexClassLoader or dlopen usage
Detection direction
- Validate that mobile telemetry captures runtime behavior, not only static app metadata or installation events.
- Build correlation around the full behavior chain; single events such as DexClassLoader use or .dex writes may be legitimate and need context.
- Tune for tight timing between blob handling, unpacking or memory permission change, artifact creation or byte-array class definition, and load or execution.
- Review false positives from legitimate apps that use dynamic modules, plugin frameworks, compression, encryption, or native libraries.
- Identify blind spots where Android sandboxing, limited mobile EDR visibility, lack of memory telemetry, or missing app-writable path monitoring prevents correlation.
Mitigation priorities
- Start with inventory and policy: know which Android apps are approved to use dynamic code loading or native library loading at runtime.
- Require mobile app security review to assess runtime code-loading behavior, not only static package contents.
- Improve mobile telemetry collection for file writes, dynamic loader activity, process creation, and executable memory behavior where supported.
- Use application control, mobile device management, and app vetting policies to reduce exposure to untrusted or unmanaged apps.
- Prepare IR playbooks to preserve app artifacts, device logs, timestamps, and affected app context when runtime code-loading behavior is observed.
Analyst notes and limits
The supplied object is a detection analytic for Android in the mobile ATT&CK domain. It provides a strong behavioral description but no official detection implementation, no tactics, and no relationship context. The most defensible use is as a hypothesis-driven detection and validation pattern for Android runtime code loading and unpacking behavior.
No official detection text, related techniques, groups, software, mitigations, or tactics were supplied. This take does not assert maliciousness, active exploitation, attribution, or existing coverage. Local Android telemetry, app architecture, and enterprise mobile management data are required to determine detectability and priority.
Analytic 1722
From the defender view: a sandboxed app handles a high-entropy executable blob, performs rapid decode/decrypt in memory (often with RW→RX or execmem friction), optionally emits a transient .dex/.so into app-writable paths, then immediately loads/executes it (DexClassLoader/dlopen) or spawns a helper. We correlate: (1) opaque blob write/arrival → (2) decode/unpack or memory protection change → (3) new code artifact or byte[] class definition → (4) dynamic load/exec 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 | e51f67134da4… |
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 AN1722Open 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.