AN1677: Analytic 1677
From the defender’s view: an app retrieves opaque code (DEX/SO/JAR/JS) over the network or IPC, writes it into an app-writable path, optionally performs verification-bypass behaviors (reflection, addJavascriptInterface exposure, or execmem friction), and then loads/executes that code via DexClassLoader/PathClassLoader, dlopen, or WebView bridge invocation within a short window. The analytic correlates Network Content → File Creation/Modification → OS API Execution (loader/syscall/SELinux friction) → Module Load (DexClassLoader/dlopen) and, for WebView paths, Application Log signals of JavaScript interface attachment.
Analyst context for executives and security teams
AN1677 is a mobile detection analytic for Android apps that fetch opaque code over a network or IPC path, write it into app-writable storage, and then load or execute it shortly afterward. For leaders, the significance is not attribution; it is whether mobile security monitoring can distinguish normal app update/plugin behavior from risky runtime code loading that may bypass expected app review, change application behavior after deployment, or complicate incident response.
Executive priority
Prioritize this analytic where Android devices, managed mobile apps, or mobile access to business systems are material to operations. The business question is whether the organization can produce evidence that mobile apps are not silently retrieving and executing new code outside approved release and change-control paths. This supports mobile threat detection readiness, incident scoping, compliance evidence for monitored endpoints, and decisions about where mobile telemetry collection or app governance needs investment.
Technical view
The official analytic describes a correlation chain on Android: Network Content followed by File Creation/Modification in an app-writable path, followed by OS API Execution related to loaders, syscalls, or SELinux friction, followed by Module Load through DexClassLoader, PathClassLoader, or dlopen. For WebView paths, it also considers Application Log evidence of JavaScript interface attachment such as addJavascriptInterface. SOC and detection engineering teams should validate whether they can time-correlate these event classes within a short window per app/process and separate expected application framework behavior from unusual code retrieval and execution patterns.
Likely telemetry
- Android network content or network connection evidence showing retrieval of opaque code-like artifacts such as DEX, SO, JAR, or JavaScript
- File creation or modification events in app-writable paths
- OS API execution or instrumentation evidence for loader activity, relevant syscalls, reflection, execmem friction, or SELinux-related signals
- Module load evidence for DexClassLoader, PathClassLoader, or dlopen activity
- Application logs or mobile runtime telemetry showing WebView JavaScript interface attachment
Detection direction
- Validate the full correlation sequence rather than alerting on a single weak signal such as a downloaded file or class loader use alone.
- Tune for short-window correlation by app identity, process, file path, and retrieved content source where telemetry permits.
- Review expected app behaviors, plugin frameworks, embedded WebView usage, and legitimate dynamic loading to manage false positives.
- Pay special attention to blind spots where mobile EDR, MDM, app logs, or OS instrumentation cannot observe file writes, module loads, WebView bridge activity, or network content.
- Because no ATT&CK relationships or tactics are supplied, avoid mapping this analytic to a broader intrusion stage without local evidence.
Mitigation priorities
- Establish approved mobile app release, update, and plugin-loading practices for managed Android environments.
- Require mobile telemetry that can capture network retrieval, app-writable file changes, loader activity, module loads, and relevant application logs where privacy and platform constraints allow.
- For internally developed apps, review use of dynamic code loading, WebView bridges, reflection, and native library loading against secure development and change-control expectations.
- Use incident response playbooks that preserve app identity, timestamps, retrieved artifacts, written paths, and loader evidence for triage.
- Where telemetry is incomplete, document the gap as a mobile monitoring and compliance evidence limitation rather than assuming coverage.
Analyst notes and limits
This is a detection analytic object, not a technique or campaign report. The most useful application is coverage validation: can the organization observe and correlate the Android behaviors MITRE lists, and can analysts explain which apps are expected to behave this way?
The supplied ATT&CK fields provide no official detection text, tactics, relationships, aliases, labels, or threat attribution. The take is therefore limited to the official analytic description, Android platform scope, and the single MITRE external reference. Local app inventory, telemetry depth, and policy context are required to determine risk or alert severity.
Analytic 1677
From the defender’s view: an app retrieves opaque code (DEX/SO/JAR/JS) over the network or IPC, writes it into an app-writable path, optionally performs verification-bypass behaviors (reflection, addJavascriptInterface exposure, or execmem friction), and then loads/executes that code via DexClassLoader/PathClassLoader, dlopen, or WebView bridge invocation within a short window. The analytic correlates Network Content → File Creation/Modification → OS API Execution (loader/syscall/SELinux friction) → Module Load (DexClassLoader/dlopen) and, for WebView paths, Application Log signals of JavaScript interface attachment.
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 | 893e5c7330e9… |
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 AN1677Open 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.