AN1801: Analytic 1801
Correlates (1) a malicious application gaining or using a removal-capable control path, such as device owner or delegated app-management authority, accessibility service control over uninstall UI, or rooted filesystem access, (2) initiation of uninstall or package-removal behavior, and (3) disappearance of the application from installed-state inventory or app runtime immediately afterward, often with a short-lived final burst of local cleanup or outbound communication. The defender observes a causal chain where the application first establishes the ability to remove itself, then triggers uninstall or deletion, and then vanishes from expected app presence while device activity continues.
Analyst context for executives and security teams
This analytic is about spotting an Android app that appears to remove itself after gaining a control path capable of uninstalling or deleting applications. For leaders, the practical concern is evidence loss and reduced incident visibility: if a malicious mobile app can disappear from normal inventory shortly after acting, SOC and IR teams may miss the window to confirm exposure, scope affected devices, or preserve useful artifacts.
Executive priority
Prioritize this where Android devices are used for business operations, privileged access, regulated workflows, or field activity. The decision value is to verify whether mobile security, device management, and incident response processes can reconstruct app presence and removal events after the app is no longer installed. This supports operational resilience, compliance evidence, and mobile incident readiness more than simple point-in-time app inventory does.
Technical view
For Android, validate whether telemetry can correlate three events in sequence: the app obtains or uses a removal-capable path, uninstall or package-removal behavior begins, and the app disappears from installed-state inventory or runtime shortly afterward. The supplied object does not specify tactics or ATT&CK relationships, so detection engineering should focus on the causal chain described by the analytic rather than inferring adversary intent. Useful validation includes device-owner or delegated app-management authority changes, accessibility-service involvement with uninstall UI, rooted filesystem access indicators where available, package removal events, post-removal inventory deltas, and any short final burst of local cleanup or outbound communication.
Likely telemetry
- Android installed application inventory over time
- Android app runtime or process presence/absence
- Device owner and delegated app-management authority state
- Accessibility service enablement and interaction with uninstall flows
- Package uninstall or package-removal events
Detection direction
- Test correlation logic across time, not just single events: authority/control path, uninstall/removal initiation, then disappearance from inventory or runtime.
- Confirm whether inventory snapshots are frequent enough to detect short-lived app presence and post-removal disappearance.
- Tune for legitimate administrative uninstall workflows, enterprise app management, device resets, and user-initiated removals to reduce false positives.
- Preserve pre-removal and post-removal device context so analysts can still scope incidents after the app vanishes.
- Because no official detection text or relationships are supplied, avoid mapping this analytic to unsupported tactics, threat groups, or guaranteed coverage claims.
Mitigation priorities
- Ensure Android device management policies limit which apps or accounts can obtain device-owner or delegated app-management authority.
- Review accessibility service permissions and approval processes, especially for apps outside expected business use.
- Maintain historical mobile inventory and event retention so app removal does not erase investigative visibility.
- Include mobile app self-removal scenarios in incident response playbooks and evidence preservation procedures.
- Where rooted-device telemetry is available, treat root-related removal paths as higher priority for investigation.
Analyst notes and limits
AN1801 is a mobile ATT&CK detection analytic for Android. Its value is strongest when combined with local mobile device management, mobile threat defense, and endpoint inventory data that can prove sequence and timing. The object provides a behavioral description but no ATT&CK tactic, related techniques, or official detection implementation.
The supplied ATT&CK fields do not include detection logic, relationships, mitigations, threat actors, software, campaigns, or active exploitation evidence. Any assessment of coverage, prevalence, or business exposure requires local Android telemetry, device management configuration, and retention evidence.
Analytic 1801
Correlates (1) a malicious application gaining or using a removal-capable control path, such as device owner or delegated app-management authority, accessibility service control over uninstall UI, or rooted filesystem access, (2) initiation of uninstall or package-removal behavior, and (3) disappearance of the application from installed-state inventory or app runtime immediately afterward, often with a short-lived final burst of local cleanup or outbound communication. The defender observes a causal chain where the application first establishes the ability to remove itself, then triggers uninstall or deletion, and then vanishes from expected app presence while device activity continues.
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 | ec69d61fe803… |
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 AN1801Open 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.