AN1807: Analytic 1807
Correlates (1) abnormal application or system resource resolution behavior (e.g., library loading, path resolution, or intent redirection), (2) execution of code or resources not aligned with the originating application’s package identity or expected runtime context, and (3) follow-on execution or network activity originating from the hijacked flow. The defender observes a causal chain where execution is redirected from an expected code path to an alternate resource or payload, resulting in execution under a trusted context but with untrusted origin.
Analyst context for executives and security teams
AN1807 is an Android-focused detection analytic for identifying when an app or system flow is redirected away from its expected code or resource path and then executes or communicates from that hijacked context. For leaders, the practical issue is trust boundary failure: activity may appear to come from a legitimate application context while the origin of the code or resource is untrusted.
Executive priority
Prioritize this analytic where Android devices or apps support sensitive business processes, regulated data access, workforce mobility, or operational workflows. The decision value is in validating whether mobile telemetry can prove the full causal chain: abnormal resource resolution, unexpected execution context, and follow-on execution or network activity. Without that evidence, incident teams may struggle to distinguish normal app behavior from abuse occurring under a trusted package identity.
Technical view
SOC, detection engineering, and IR teams should treat AN1807 as a correlation analytic rather than a single-event rule. Validate whether Android telemetry can connect resource resolution anomalies such as library loading, path resolution, or intent redirection with execution of code or resources that do not align to the originating package identity or expected runtime context, followed by execution or network activity from that redirected flow. Because no ATT&CK tactic, relationship context, or official detection implementation is supplied, local baselining and app-specific expected behavior are required.
Likely telemetry
- Android application runtime events related to library loading and resource access
- Path resolution or file/resource access records where available
- Intent handling or redirection evidence
- Package identity, signing, and runtime context metadata
- Process execution or spawned activity from mobile apps
Detection direction
- Validate correlation logic across the three required stages: abnormal resource resolution, execution inconsistent with package identity or runtime context, and follow-on execution or network activity.
- Baseline legitimate Android app behavior to reduce false positives from expected dynamic loading, deep linking, inter-app communication, or update mechanisms.
- Prioritize detections that preserve causality and timing, because isolated network or library-load events may not be meaningful without the redirected execution chain.
- Check for blind spots in mobile telemetry: many environments collect device compliance status but not detailed runtime, intent, resource-resolution, or package-context evidence.
- Use the official MITRE analytic as a detection strategy reference, not as proof of current coverage, because no concrete detection query or relationship context is provided.
Mitigation priorities
- Inventory Android use cases where trusted app context protects sensitive data or operational access.
- Confirm mobile management, logging, and response tooling can capture package identity, runtime context, resource resolution, and follow-on network activity.
- Harden application and mobile security controls around trusted package identity, application provenance, and allowed app behavior using existing enterprise mobile policies.
- Establish IR playbooks for suspected mobile app flow hijacking, including device isolation, app/package review, and preservation of event timelines.
- For internally developed Android apps, coordinate with application security teams to review assumptions around library loading, path handling, intent handling, and runtime trust boundaries.
Analyst notes and limits
This object is a detection analytic, not a technique description. Its value is strongest for detection validation and incident triage design: defenders should prove they can observe a redirected execution chain under a trusted Android context. The absence of relationships means no specific ATT&CK technique, adversary behavior, or campaign context should be inferred from this object alone.
Official detection content is not provided, tactics are not specified, and no relationship context is supplied. Coverage depends heavily on local Android telemetry depth, managed device visibility, application architecture, and whether event ordering can be reconstructed. This summary uses only the supplied ATT&CK fields and external reference.
Analytic 1807
Correlates (1) abnormal application or system resource resolution behavior (e.g., library loading, path resolution, or intent redirection), (2) execution of code or resources not aligned with the originating application’s package identity or expected runtime context, and (3) follow-on execution or network activity originating from the hijacked flow. The defender observes a causal chain where execution is redirected from an expected code path to an alternate resource or payload, resulting in execution under a trusted context but with untrusted origin.
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 | d37682b80a1e… |
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 AN1807Open 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.