Mobile T1630 Indicator Removal on Host: Catching Mobile Malware That Cleans Up

Mobile malware and spyware routinely delete their own files, crash logs and even themselves, so the evidence a responder needs may be gone before anyone looks. MITRE ATT&CK for Mobile tracks this as T1630 Indicator Removal on Host, under Defense Evasion (TA0030). The technique is listed for both Android and iOS; of its three sub-techniques, Uninstall Malicious Application and File Deletion are listed for Android, and Disguise Root/Jailbreak Indicators for both platforms. This guide explains each sub-technique with the cases ATT&CK documents, including the iOS Operation Triangulation campaign, then covers detection through off-device telemetry, attestation and forensic acquisition, and how to respond. It is for mobile security engineers and incident responders and goes deeper than the MITRE ATT&CK for Mobile Guide.

Key takeaways

• On-device evidence is perishable. ATT&CK documents malware deleting files after exfiltration, deleting call log entries and crash logs, and uninstalling itself on command.
• Collect off the device. Network logs, MDM inventory history and server-side attestation results survive when the device is cleaned, so forward them before you need them.
• iOS is affected too. ATT&CK records the Operation Triangulation actors deleting the exploit message and attachment, and the Binary Validator component deleting crash logs from the iOS CrashReporter directory.
• Do not trust local root checks. T1630.003 exists because simple checks, such as looking for an su binary, are easy to defeat; prefer hardware-backed attestation.
• A disappearing app is itself a signal. An unapproved package that appears and then vanishes from MDM inventory deserves investigation, not relief.

What T1630 covers

ATT&CK describes T1630 as deleting, altering or hiding artifacts generated on a device, including files, jailbreak status or the malicious application itself, in ways that interfere with event collection, reporting or notifications used to detect intrusion. At the technique level ATT&CK lists Chameleon removing artifacts of its presence and uninstalling itself, GodFather requesting WRITE_EXTERNAL_STORAGE to delete files in external storage, and Operation Triangulation deleting the initial exploitation message and exploit attachment. The technique mirrors Enterprise T1070 Indicator Removal; see the T1070 Indicator Removal Defensive Guide.

File Deletion is mapped to Android in ATT&CK v20, yet its procedure examples include the iOS Operation Triangulation campaign and its TriangleDB and Binary Validator components. Defenders of iOS fleets should read it as relevant to them.

T1630.001 Uninstall Malicious Application

ATT&CK lists three ways malware removes itself on Android: abusing device owner permissions for silent uninstallation through device owner API calls, abusing root permissions to delete its files, or abusing the accessibility service to request uninstallation and then click through the confirmation. TrickMo uninstalls itself on command through the accessibility service; SharkBot and Cerberus have C2 commands to uninstall; BRATA uninstalls itself and removes traces of infection; Escobar can uninstall itself and other applications.

• Why it matters: self-removal usually follows a completed fraud or collection run, or a sign that the operator thinks it has been noticed. By the time the user reports a problem, the app may be gone.
• Mitigations: ATT&CK maps M1001 Security Updates (patches for rooting vulnerabilities), M1002 Attestation (detecting rooted devices) and M1011 User Guidance (warning that rooting and unnecessary accessibility access carry risk).

T1630.002 File Deletion

ATT&CK notes that wiping a whole device needs administrator access, while deleting individual files may need no special permission depending on where they are stored. Procedure examples range from clean-up to impact. Hornbill deletes locally gathered files after uploading them; Monokle deletes arbitrary files, uninstalls itself and cleans up staging files; CarbonSteal deletes call log entries coming from known C2 sources; Fakecalls can delete incoming calls from the call log; Agent Smith deletes infected apps' update packages to stop them updating; GPlayed and Mandrake can wipe the device.

On iOS, ATT&CK records that during Operation Triangulation the actors removed files from the device, that TriangleDB deleted an implant module or specified files, and that Binary Validator deleted crash logs created during initial exploitation, stored in /private/var/mobile/Library/Logs/CrashReporter. Crash logs are exactly the kind of artifact forensic tools look for after exploitation, which is why they are cleaned.

• Mitigation M1011 User Guidance: ATT&CK advises training users on what device administrator prompts look like and how to avoid granting permissions on phishing pop-ups, because full wipe requires that grant.

T1630.003 Disguise Root/Jailbreak Indicators

ATT&CK describes an adversary using knowledge of how security software detects compromised devices to evade it: renaming an su binary to defeat a check that searches for it, or using polymorphic code to defeat signature checks. ATT&CK lists no procedure examples. Its detection strategy for Android looks at file metadata from forensic acquisition, such as setuid binaries outside known system binary paths; for iOS it correlates Apple MDM device information, security info and installed application lists with network flow metadata.

• Prefer attestation to local checks: on Android, the Play Integrity API's MEETS_DEVICE_INTEGRITY verdict on Android 13 and later relies on hardware-backed proof that the bootloader is locked and the OS is a certified image, and MEETS_STRONG_INTEGRITY adds a recent security update requirement. Verdicts are checked on your server, not on the device. See the Mobile App Attestation guide for iOS and Android options.
• Verified Boot: Android Verified Boot checks each stage from hardware to the system partitions, which is the basis for those hardware-backed verdicts.

Detection and measurement

ATT&CK v20 detection strategies for T1630 correlate permission grant state and managed inventory with app vetting traces of apps invoking file deletion, database truncation or cache clearing on artifacts outside their normal behaviour. Because the device is the thing being cleaned, design detection so the evidence lives elsewhere.

Metrics:

• Percentage of managed devices whose inventory changes are retained off-device for at least 90 days.
• Percentage of company-owned Android devices with security logging forwarded to the SIEM.
• Count of "appeared then removed" unapproved packages investigated per month.
• Percentage of high-value app sessions backed by a server-verified integrity verdict.
• Time from suspected compromise to forensic acquisition for high-risk users.

Implementing the controls

1. Forward, do not just collect. Configure MDM and MTD to stream inventory and alert events to the SIEM so history survives a device wipe.
2. Enable security logging on company-owned Android devices. Only a device owner can call setSecurityLoggingEnabled(); Android's DPC documentation notes retrievePreRebootSecurityLogs() can return logs from the previous reboot cycle on supported devices. Pilot first for volume.
3. Route mobile traffic through inspectable paths. Use per-app VPN or a secure web gateway for managed apps so network evidence exists independent of the device.
4. Move root and jailbreak checks to the server. Request attestation verdicts and decide on the backend; treat client-side checks as one input only.
5. Prepare consensual forensics. For executives and other high-risk users, agree in advance how a device will be acquired and analysed. MVT, from Amnesty International's Security Lab, supports consensual analysis of iOS backups, filesystem dumps and sysdiagnose files, and of Android data, against published indicators.

Responding when indicators have been removed

• Start from off-device evidence: inventory history, network logs and integrity verdict history set the timeline when the device itself looks clean.
• Acquire before reset: even a cleaned device can hold traces; take an iOS backup and sysdiagnose, or an Android acquisition, before any factory reset.
• Consider Lockdown Mode for targeted iOS users: Apple describes Lockdown Mode as an optional, extreme protection for people who may be personally targeted, blocking most message attachment types and link previews among other restrictions. Lockdown Mode also blocks MDM enrolment and configuration profiles, so plan management for those users.
• Rotate credentials: a self-removed banking trojan or spyware implant has usually already taken what it wanted.

See the Mobile Spyware Infection Response Playbook and the Mobile Forensics Guide.

Framework mapping

Common failure patterns

• Logs only on the device: mobile telemetry kept locally or in a console with short retention, so self-removal leaves no trail.
• Closing the ticket when the app vanishes: an unapproved package removing itself is treated as resolved rather than as a likely completed operation.
• Client-side root detection as the only check: string matches for su or known jailbreak paths, which T1630.003 is designed to defeat.
• Factory reset first: service desks reset a suspect device to restore service and destroy the remaining traces.
• Ignoring iOS: assuming indicator removal is an Android problem, despite ATT&CK's iOS procedure examples.

Practitioner checklist

• Stream MDM and MTD inventory changes to the SIEM with at least 90 days of retention.
• Enable and forward Android Enterprise security and network logging on company-owned devices.
• Investigate any unapproved package that is installed and later removed.
• Make root and jailbreak decisions on the server from attestation verdicts.
• Acquire a backup or forensic image before resetting any suspect device.
• Agree a consensual forensics process for high-risk users, including MVT analysis.
• Rotate passwords and revoke tokens for any device where indicator removal is suspected.

Standards and references

• MITRE ATT&CK: Indicator Removal on Host (Mobile T1630)
• MITRE ATT&CK: File Deletion (T1630.002)
• MITRE ATT&CK: Operation Triangulation (C0054)
• Android Developers: Security for device policy controllers
• Android Developers: Play Integrity API integrity verdicts
• Android Open Source Project: Verified Boot
• MVT Project: Mobile Verification Toolkit documentation
• Apple: About Lockdown Mode

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Forensics Guide · Mobile Communications Protection for High-Risk Individuals Guide · Mobile Malware Guide