T1630: Indicator Removal on Host
Adversaries may delete, alter, or hide generated artifacts on a device, including files, jailbreak status, or the malicious application itself. These actions may interfere with event collection, reporting, or other notifications used to detect intrusion activity. This may compromise the integrity of mobile security solutions by causing notable events or information to go unreported.
Analyst context for executives and security teams
Indicator Removal on Host is a mobile evasion behavior where an adversary deletes, changes, or hides artifacts on Android or iOS devices, including files, jailbreak/root indicators, or the malicious app itself. The business issue is evidence integrity: if mobile controls depend on those artifacts to alert, report, or prove device health, this behavior can make a compromised device appear cleaner than it is.
Executive priority
Prioritize this where mobile devices access sensitive enterprise resources, banking/finance workflows, privileged communications, or regulated data. Leaders should ask whether access decisions depend on current patch level, attestation, jailbreak/root status, and reliable mobile event reporting—and whether unsupported or non-attesting devices are blocked or limited. This technique is also relevant to incident response and compliance evidence because missing mobile telemetry may be a sign of evasion, not absence of activity.
Technical view
For SOC, detection engineering, and IR teams, validate coverage across Android and iOS for artifact disappearance, app uninstall events, file deletion or wipe indicators, jailbreak/root status changes, and interruptions in expected mobile security reporting. ATT&CK provides no official detection text for T1630, but the object is associated with detection strategy DET0651. Relationship context highlights Android sub-techniques for uninstalling malicious applications and file deletion, and Android/iOS disguise of root or jailbreak indicators. ATT&CK also relates this behavior to Operation Triangulation on iOS and Android malware families Chameleon and GodFather, so mobile investigations should treat sudden loss of indicators or control visibility as potentially material.
Likely telemetry
- MDM/UEM device inventory, compliance, patch level, and access-control state
- Mobile security or endpoint protection alerts and health/reporting status
- Remote attestation results where available
- Application install, uninstall, and permission-change records, especially device owner, administrator, accessibility, or elevated permissions on Android
- Root/jailbreak detection results and changes over time
Detection direction
- Baseline expected mobile security reporting cadence and alert when a device stops reporting, loses key artifacts, or changes integrity state without an approved reason.
- Correlate app uninstall, file deletion, wipe, root/jailbreak status, attestation failure, and MDM compliance changes with enterprise access activity.
- Treat legitimate app removal, OS upgrades, user resets, device replacement, and privacy-driven telemetry limits as false-positive sources that need tuning.
- Validate Android-specific visibility for accessibility abuse, device owner/admin permissions, and patch-level based access decisions where those controls are used.
- For iOS, focus on attestation/device integrity signals, jailbreak-indicator reliability, and gaps in mobile security telemetry, recognizing that endpoint-level visibility may be limited.
Mitigation priorities
- Apply M1001 Security Updates: require timely mobile OS/security updates, prefer devices with vendor or carrier update commitments, and decommission devices that no longer receive updates.
- Limit or block enterprise access from devices that are not recently patched or cannot meet required security posture; Android patch-level checks are specifically supported by the mitigation text.
- Apply M1002 Attestation: enable remote attestation where available and prevent devices that fail attestation from accessing enterprise resources.
- Apply M1011 User Guidance: train users to avoid risky behaviors and follow approved configuration practices that preserve mobile security visibility.
- Make mobile access policy explicit: unknown device health should not be treated as healthy device health.
Analyst notes and limits
This technique is less about a single artifact and more about trust in mobile evidence. For Glexia-style assessment, the key validation question is whether mobile access, incident response, and compliance workflows can detect when evidence disappears or becomes unreliable. Relationship context suggests particular attention to Android app uninstallation, file deletion, accessibility/admin abuse, and Android/iOS jailbreak-root disguise behaviors.
The supplied ATT&CK object has no official detection text and no tactic listed. Platform support is limited to Android and iOS. Relationship descriptions provide useful context but not complete procedure details, and local MDM/UEM, mobile security tooling, privacy settings, and OS versions will determine what telemetry is actually available.
Indicator Removal on Host
Adversaries may delete, alter, or hide generated artifacts on a device, including files, jailbreak status, or the malicious application itself. These actions may interfere with event collection, reporting, or other notifications used to detect intrusion activity. This may compromise the integrity of mobile security solutions by causing notable events or information to go unreported.
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.
Related techniques
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 | Uninstall Malicious Application subtechnique of this object. |
| Mobile | T1630.002 | File Deletion Sub-technique | File Deletion subtechnique of this object. |
| Mobile | T1630.003 | Disguise Root/Jailbreak Indicators Sub-technique | Disguise Root/Jailbreak Indicators subtechnique of this object. |
Groups, software, and campaigns
S1083: Chameleon
Chameleon is an Android banking trojan that can leverage Android’s Accessibility Services to perform malicious activities. Believed to have been first active in January 2023, Chameleon has been observed targeting users in Australia and Poland by masquerading as official applications. A new variant of Chameleon has expanded its targets to include Android users in the United Kingdom and Italy.[1][2]
S1231: GodFather
GodFather is an Android banking malware that uses virtualization to mimic legitimate applications and abuses accessibility services and other permissions to evade detection and exfiltrate sensitive data. First identified in 2020, GodFather targets nearly 500 banking applications, cryptocurrency wallets, and exchanges worldwide; however, its virtualization-based attacks have primarily focused on several Turkish financial institutions. This capability enables threat actors to steal banking credentials and other sensitive account information. [1][2]
C0054: Operation Triangulation
Operation Triangulation is a mobile campaign targeting iOS devices.[1] The unidentified actors used zero-click exploits in iMessage attachments to gain Initial Access, then executed exploits and validators, such as Binary Validator before finally executing the TriangleDB implant.
All related ATT&CK context
Mitigation direction
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 | 64900b0606e4… |
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]
NIST Mobile Threat Catalogue APP-43Open source URL
-
[2]
mitre-attack T1630Open 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.