AN1847: Analytic 1847
The defender correlates application loading or invoking native libraries through JNI or NDK-backed execution paths with subsequent lower-level activity such as native thread creation, sensor access, file operations, or outbound network communication that is inconsistent with the app's declared role or recent user interaction. The analytic prioritizes defender-observable control-plane effects: native library load or JNI bridge use, transition into native execution context, and immediate post-load behavior occurring from background state, locked-device state, or non-baselined app categories.
Analyst context for executives and security teams
This analytic matters because it focuses on Android apps that cross from normal application behavior into native code execution and then quickly perform sensitive lower-level actions such as thread creation, sensor access, file activity, or outbound network communication. For leaders, the decision value is whether mobile security monitoring can distinguish expected app functionality from suspicious native-library-backed behavior, especially when it occurs in the background, on a locked device, or from app categories where that behavior is not baselined.
Executive priority
Prioritize this as a mobile security and resilience coverage question: can the organization produce evidence that Android application behavior is monitored beyond package reputation and permissions, including native execution paths and post-load activity? This is relevant to SOC readiness, incident response scoping, mobile risk governance, and compliance evidence where corporate Android devices or managed apps are in scope. Budget and control decisions should focus on whether telemetry exists to correlate native library loading with subsequent behavior, not just whether devices are enrolled.
Technical view
For Android, validate whether defenders can observe application loading or invoking native libraries through JNI or NDK-backed execution paths, identify transition into native execution context, and correlate immediate post-load behavior. The analytic calls out native thread creation, sensor access, file operations, and outbound network communication, especially when activity occurs from background state, locked-device state, or app categories without an established baseline. Because no official detection logic is supplied, SOC and detection engineering teams should treat this as a correlation and baselining requirement rather than a ready-to-run rule.
Likely telemetry
- Android application native library load or JNI bridge use events
- Indicators of transition into native execution context
- Native thread creation activity
- Sensor access events
- File operation telemetry by app/process context
Detection direction
- Validate that mobile telemetry can correlate native library loading or JNI/NDK-backed execution with behavior occurring immediately afterward.
- Tune around app role and category baselines so legitimate apps with expected native components do not dominate alert volume.
- Prioritize cases where post-load activity occurs while the app is in the background, the device is locked, or there is no recent user interaction.
- Review blind spots where mobile management tooling records app inventory and permissions but not native execution context or post-load activity.
- Use this analytic as a hypothesis for triage enrichment because ATT&CK provides no official detection query or relationship context for this object.
Mitigation priorities
- Establish managed Android visibility requirements for native library usage, app state, sensor access, file operations, and network activity where feasible.
- Define baselines for approved business apps and app categories that legitimately use JNI or NDK-backed execution paths.
- Integrate mobile telemetry into SOC and incident response workflows so native execution signals can be correlated with network, file, and device-state evidence.
- Apply mobile application governance to reduce unmanaged or non-baselined apps on corporate devices.
- Use incident response playbooks to preserve relevant mobile evidence when suspicious native execution and follow-on activity are observed.
Analyst notes and limits
This is a detection analytic object for the mobile ATT&CK domain, platform Android, external ID AN1847. The supplied description is control-plane focused: native library load or JNI bridge use, transition into native execution, and immediate lower-level behavior inconsistent with app role or user interaction. No tactics, detection implementation, aliases, labels, or relationships were supplied.
No official detection text, rule logic, data component mapping, tactics, or related techniques were provided. The take therefore cannot assert specific ATT&CK technique coverage, active exploitation, actor use, impact, or guaranteed detectability. Local Android telemetry depth and app baselines are required to determine practical coverage.
Analytic 1847
The defender correlates application loading or invoking native libraries through JNI or NDK-backed execution paths with subsequent lower-level activity such as native thread creation, sensor access, file operations, or outbound network communication that is inconsistent with the app's declared role or recent user interaction. The analytic prioritizes defender-observable control-plane effects: native library load or JNI bridge use, transition into native execution context, and immediate post-load behavior occurring from background state, locked-device state, or non-baselined app categories.
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 | ba959c1196ff… |
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 AN1847Open 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.