DET0651: Detection of Indicator Removal on Host
DET0651 is a mobile ATT&CK detection strategy for finding attempts to remove or hide indicators on a host device. In business terms, the risk is not only t...
Analyst context for executives and security teams
DET0651 is a mobile ATT&CK detection strategy for finding attempts to remove or hide indicators on a host device. In business terms, the risk is not only the original intrusion but the loss of evidence: if files, jailbreak status, malicious apps, or other artifacts are deleted, altered, or hidden, security teams may miss the incident, underestimate scope, or lack evidence for response and compliance reporting.
Executive priority
Treat this as an evidence-integrity and incident-readiness issue for mobile environments. Leaders should ask whether Android and iOS monitoring can still produce useful evidence when an adversary attempts to suppress events or hide artifacts, and whether incident response plans account for incomplete or tampered mobile telemetry. This matters for operational resilience, audit defensibility, and prioritizing controls that preserve visibility on managed mobile devices.
Technical view
The supplied ATT&CK object has no official detection text, platforms, or tactics of its own, but it detects the mobile technique T1630, Indicator Removal on Host, which applies to iOS and Android. SOC, detection engineering, and IR teams should validate whether mobile security tooling, MDM/UEM records, application inventory, device integrity checks, file/artifact visibility, and alert pipelines can reveal suspicious disappearance, alteration, or hiding of artifacts. Detection should focus on inconsistencies: expected events that stop arriving, security-relevant state changes, application removal or concealment, jailbreak/root-related status changes, and gaps between device inventory, security tooling, and incident timelines.
Likely telemetry
- Mobile device management or unified endpoint management inventory and compliance records
- Mobile security solution alerts and event history
- Application install, removal, and inventory records for Android and iOS devices
- Device integrity, jailbreak, or root status signals where available
- File or artifact metadata exposed by approved mobile security tooling
Detection direction
- Validate that mobile detections do not rely on a single on-device signal that can be deleted, hidden, or suppressed.
- Correlate mobile security events with MDM/UEM inventory, compliance state, application inventory, and alert delivery logs to identify unexplained gaps or reversals.
- Tune for high-value inconsistencies, such as a previously observed suspicious app or device state disappearing without an expected administrative or user-driven reason.
- Account for false positives from legitimate app uninstallations, OS updates, device resets, privacy controls, enrollment changes, or administrative remediation actions.
- Review whether alerting identifies telemetry loss or event suppression as a security condition, not merely as a device management nuisance.
Mitigation priorities
- Prioritize resilient mobile visibility through managed enrollment, inventory, compliance monitoring, and centralized event forwarding where appropriate.
- Preserve evidence by ensuring mobile incident response procedures capture available device, MDM/UEM, and security-tool records before remediation whenever feasible.
- Define administrative baselines for legitimate app removal, device resets, enrollment changes, and security-state changes so suspicious deviations can be investigated.
- Regularly test whether mobile controls still report meaningful evidence after artifacts disappear or alerts stop arriving.
- Ensure compliance and incident response documentation explains how the organization handles incomplete or potentially tampered mobile evidence.
Analyst notes and limits
This detection strategy is valuable because it frames a common defensive failure mode: the attacker behavior may reduce the evidence needed to prove or scope the incident. For Glexia-style readiness work, the key question is whether the organization can detect loss of visibility and reconcile mobile evidence across independent sources, not just whether a single mobile alert exists.
The official DET0651 object supplies no description, detection logic, tactics, or platforms. Platform context comes only from the related T1630 technique, which lists iOS and Android. Local mobile management architecture, tooling, privacy constraints, enrollment model, and logging retention are required to determine practical coverage.
Detection of Indicator Removal on Host
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 | Indicator Removal on Host | This object detects Indicator Removal on Host. |
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 | e61b2e5b0e1e… |
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 DET0651Open 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.