DET0690: Detection of Uninstall Malicious Application
This detection strategy is about recognizing when mobile malware removes itself from an Android device. For security leaders, the practical risk is loss of...
Analyst context for executives and security teams
This detection strategy is about recognizing when mobile malware removes itself from an Android device. For security leaders, the practical risk is loss of evidence: if a malicious app can uninstall itself, incident responders may have less time to confirm compromise, preserve artifacts, and determine scope.
Executive priority
Prioritize this as an incident response and mobile security readiness issue rather than a standalone control. Leaders should ask whether managed mobile devices generate enough app inventory, uninstall, device-owner, root, and accessibility-service evidence to support investigations after a suspicious app disappears. This matters for business continuity, audit evidence, and timely incident decisions because the behavior can reduce visibility into what happened on the endpoint.
Technical view
The ATT&CK detection strategy DET0690 has no official detection text or platform field, but it is related to mobile technique T1630.001, Uninstall Malicious Application, which is identified as Android. SOC and IR teams should validate whether Android mobile telemetry can show app removal events and surrounding context, especially where device owner permissions, root-level file deletion, or accessibility service abuse may be involved. Detection engineering should focus on correlating app uninstall events with prior suspicious app behavior and privileged capability use, rather than treating every uninstall as malicious.
Likely telemetry
- Android application install/uninstall history
- Mobile device management or enterprise mobility management app inventory changes
- Device owner or device administrator state changes where available
- Accessibility service enablement and activity logs where available
- Root or filesystem modification indicators where available
Detection direction
- Confirm whether uninstall events are collected from Android devices before, during, and after an incident window.
- Correlate uninstall activity with suspicious app identity, recent permission changes, accessibility service usage, device owner status, or root indicators.
- Tune for context: legitimate user-initiated or administrator-initiated app removal is common and should not be treated as inherently malicious.
- Look for visibility gaps where personal devices, unmanaged devices, limited mobile logging, or post-uninstall evidence loss prevent reliable investigation.
- Because the ATT&CK object provides no official detection logic, validate any analytic against local mobile management and mobile threat defense data sources.
Mitigation priorities
- Ensure managed Android devices provide timely app inventory and uninstall visibility.
- Limit and monitor use of high-risk capabilities such as device owner privileges, root access, and accessibility services where policy permits.
- Preserve mobile security and management logs long enough to support post-uninstall investigations.
- Define IR procedures for quickly collecting mobile evidence when a suspicious app disappears.
- Use mobile governance and compliance checks to identify devices with insufficient telemetry or policy enforcement.
Analyst notes and limits
This take is derived from DET0690 and its relationship to T1630.001. The value is mainly in validating whether a mobile security program can retain useful evidence when a malicious app attempts to remove itself. The supplied object does not include official detection guidance, tactics, or platforms; Android context comes from the related technique.
Official description and detection fields are not provided for DET0690. Platforms are not specified on the detection strategy itself. The related technique description is partially truncated in the supplied data, so recommendations are limited to the stated Android behaviors and general defensive validation.
Detection of Uninstall Malicious Application
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1630.001 | Uninstall Malicious Application Sub-technique | This object detects Uninstall Malicious Application. |
All related ATT&CK context
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.0 | Current bundle | 8047a5461296… |
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 DET0690Open 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.