Mobile ATT&CK Defence Evasion Tactic: Exposing Hidden Mobile Malware With MDM, MTD and Forensics

Mobile malware survives because users and security tools do not see it: it hides its icon, poses as a trusted app, fetches its real code only after review, and switches off the protections that would catch it. The Defense Evasion tactic (TA0030) in MITRE ATT&CK for Mobile collects these behaviours, and in v20 it is the largest Mobile tactic, with 17 techniques and 16 sub-techniques. Unlike the Enterprise matrix, where v20 split defence evasion into separate Stealth and Defense Impairment tactics, the Mobile matrix keeps a single Defense Evasion tactic. This hub explains what the tactic means on Android and iOS, which techniques matter most to defenders and why, how evasion chains with the rest of a mobile intrusion, and which MDM, mobile threat defence (MTD), attestation and forensic signals expose it. It is written for mobile security engineers, SOC analysts and incident responders. For the matrix as a whole, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Evasion is everywhere in mobile malware. 97 distinct software, group and campaign entries in ATT&CK v20 use at least one technique in this tactic, the third highest of any Mobile tactic after Collection (106) and Discovery (102).
• Three techniques dominate the data. Obfuscated Files or Information (T1406), Masquerading (T1655) and Download New Code at Runtime (T1407) account for most recorded use, and all three target app review and signature scanning.
• Many techniques have no preventive mitigation. ATT&CK v20 maps no mitigation to T1406, T1575, T1604, T1631 and T1633, so detection through app vetting, behaviour and attestation carries the load.
• Attestation is the strongest single signal. Device and app integrity checks (Play Integrity on Android, MDM compliance and supervision state on iOS) catch the techniques that subvert the platform itself: hooking, code signing changes and disabled defences.
• Accessibility abuse is the Android pivot. Input Injection, Prevent Application Removal and Disable or Modify Tools are usually achieved through the Accessibility Service, so controlling who may grant it removes several techniques at once.

What defence evasion means on a phone

ATT&CK describes Defense Evasion as techniques "an adversary may use to evade detection or avoid other defenses", and adds that it "may be considered a set of attributes the adversary applies to all other phases of the operation". On a mobile device the defences being evaded are specific and few:

• Store review and app vetting: Google Play and Apple App Store checks, enterprise app vetting, and sandbox analysis. Evaded by obfuscation, packing, runtime code download, sandbox checks, geofencing and benign-then-malicious updates.
• On-device protection: Google Play Protect, MTD agents and the operating system's code signing rules. Evaded by disabling tools, subverting trust controls, hooking and virtualisation.
• The user: the only person who might notice. Evaded by hiding the icon, masquerading as a trusted brand, suppressing activity while the screen is on, and blocking removal.
• Forensics: evaded by deleting files, uninstalling the payload and disguising root or jailbreak indicators.

The practical consequence is that no single control covers this tactic. Defenders need layered evidence: what the app looked like when vetted, what it does at runtime, what state the device is in, and what is left behind for forensics.

Every technique in the tactic

The table lists every current technique and sub-technique under TA0030 in ATT&CK for Mobile v20, with the number of distinct software, group and campaign entries that use it and the mitigations ATT&CK maps to it. Each technique has its own guide on this site.

Method: counts come from the ATT&CK for Mobile v20.0 STIX bundle. "Users" is the number of distinct, non-revoked, non-deprecated software, group and campaign objects with a "uses" relationship to the technique or any of its sub-techniques. Several techniques sit in more than one tactic: T1516 also in Impact, T1541 in Persistence, T1575 in Execution, T1631 in Privilege Escalation, and T1661 in Initial Access. Across the tactic, ATT&CK records four groups (APT-C-23, Bouncing Golf, MoustachedBouncer and Windshift) and two campaigns, one of them Operation Triangulation.

Ranked: the techniques to cover first

1. T1406 Obfuscated Files or Information (52 users). Nearly universal in mobile malware and with no mitigation mapped, it defeats static signatures. Examples in ATT&CK include Bread payloads using commercially available packers and Gustuff code that is both obfuscated and packed. Defenders answer with behaviour-based vetting rather than signatures.
2. T1655 Masquerading (51 users). Mostly the .001 sub-technique: apps named and styled after banks, tax authorities, cryptocurrency wallets and system updates. ATT&CK records Chameleon posing as the CoinSpot wallet, a Polish banking app and an Australian Taxation Office app. The control is to restrict installation sources so a lookalike cannot reach a managed device.
3. T1407 Download New Code at Runtime (40 users). The app passes review, then fetches its payload. ATT&CK records Triada using a backdoor in a Play Store app to install further trojanised apps from its server. This is why a clean store scan is not a clean app.
4. T1630 Indicator Removal on Host (29 users). File deletion and self-uninstall, used on both platforms. During Operation Triangulation, ATT&CK records that the operators deleted the initial exploitation message and exploit attachment. Forensics must therefore look for what is left elsewhere, such as backups, logs and network records.
5. T1628 Hide Artifacts (26 users). Mostly hiding the app icon (Cerberus hides its icon after first launch), plus suppressing activity while the user is looking. Detectable by MDM app inventory, which does not depend on the launcher.
6. T1629 Impair Defenses (22 users). Preventing removal (OBAD abusing device administrator access), locking the device, and disabling security tools (Chameleon disabling Google Play Protect). High impact for defenders because it blinds the controls that would catch everything else.
7. T1633 Virtualization/Sandbox Evasion (17 users). System checks such as Chameleon checking whether the device is rooted or has ADB enabled and avoiding execution if so. Directly undermines dynamic analysis.

The low-count techniques still deserve a line in any coverage review. T1617 Hooking, T1670 Virtualization Solution and T1631 Process Injection are rare in the data but are used by banking malware and spyware to tamper with other apps; ATT&CK records GodFather using both a virtual environment that mimics banking apps and the Xposed hooking framework. T1661 Application Versioning, where an app turns malicious in a later update, is the reason periodic re-vetting matters.

How evasion chains with other tactics

Because ATT&CK describes defence evasion as a set of attributes applied to every phase, it is easier to read by stage of the intrusion than as a step of its own.

Two patterns recur in the procedure data. Android banking trojans combine masquerading, hidden icons, accessibility-driven input injection and removal prevention, then disable Play Protect. Advanced spyware on iOS relies less on visible tricks and more on exploit chains followed by clean-up, as in Operation Triangulation, where removal of the delivery message is the recorded evasion. Discovery often feeds evasion directly: Security Software Discovery (T1418.001) tells the app which tools to avoid or disable. See the Mobile ATT&CK Discovery Tactic hub.

Prevention priorities from the mitigation data

Counting "mitigates" relationships across the tactic in v20, User Guidance (M1011) appears 16 times, Use Recent OS Version (M1006) 9, Enterprise Policy (M1012) 6, Security Updates (M1001) 4, Deploy Compromised Device Detection Method (M1010) 4, Attestation (M1002) 3 and System Partition Integrity (M1004) 2 and Do Not Mitigate (M1059) 1. User guidance alone is a weak control against apps designed to look legitimate, so the practical priorities below lean on the enforceable mitigations. Platforms are listed alphabetically.

See the Mobile App Attestation guide and the Android Enterprise Security Guide for implementation detail.

Detection priorities

ATT&CK v20 detection strategies for this tactic repeatedly draw on four evidence sources: app vetting and instrumented dynamic analysis, EMM and device policy state, network logs, and forensic artefacts. In practice:

1. App vetting with dynamic analysis. Catches packing, runtime code loading, sandbox checks and accessibility requests before deployment. Run it again on every update, because T1661 and T1407 change behaviour after the first review.
2. Device state from MDM and MTD. Alert on Play Protect turned off, a new device administrator or accessibility grant, unknown sources enabled, a new configuration profile or certificate on iOS, integrity failure, and apps present in inventory but not on the launcher.
3. Network telemetry. Download New Code at Runtime and Proxy Through Victim both generate traffic. Android network logging records DNS lookups and TCP connections per package on device owner devices from Android 8.0 and work profiles from Android 12, though it misses UDP, fixed-IP connections and direct system calls.
4. Forensic triage. When indicator removal is suspected, use the Mobile Verification Toolkit (MVT) on iOS backups, filesystem dumps or sysdiagnose archives, and on Android backups, against current indicator sets. Deleted payloads often leave traces in databases and logs the malware did not clean.

Metrics

• Integrity pass rate: percentage of managed devices passing device integrity at last check.
• Play Protect state: number of Android devices with Play Protect off (target zero on corporate devices).
• Unapproved accessibility grants: count of apps holding accessibility access outside the allow list.
• Re-vetting coverage: percentage of app updates dynamically analysed before managed deployment.
• Mean time to quarantine: time from integrity or MTD alert to conditional access block.

Where identity fits

Most mobile evasion protects a single goal: keeping stolen credentials and session tokens flowing. Banking trojans hide so they can keep capturing one-time codes, and hooking and virtualisation are used to intercept credentials inside legitimate apps. Device integrity therefore belongs in access decisions: a device that fails attestation or has Play Protect disabled should lose access to corporate apps and tokens until it is cleaned, rather than simply raising an alert. See the Conditional Access Guide.

Common failure patterns

• Trusting the store scan. Apps that download code at runtime or turn malicious in an update pass the initial review by design.
• Vetting in an obvious sandbox. Emulators with ADB enabled and root present are exactly what System Checks look for, so the malware stays dormant.
• Integrity as a report, not a gate. Attestation failures are logged but the device keeps its access tokens.
• Ignoring accessibility grants. On Android, a single accessibility grant enables input injection, removal prevention and tool disabling.
• Relying on the launcher view. Users and help desks look for icons; hidden apps are only visible in MDM inventory or settings.
• Wiping before triage. Re-imaging a suspected device before collecting a backup or sysdiagnose destroys the traces clean-up left behind.

Coverage checklist and framework mapping

Practitioner checklist

• Map each of the 17 techniques to a prevention, a detection or an accepted gap, and review the table above for techniques with no mitigation.
• Restrict install sources on managed devices and block in-house developer trust on iOS unless needed.
• Gate access on device integrity: Play Integrity verdicts on Android, MDM compliance and MTD state on iOS.
• Alert on Play Protect disabled, new device administrator or accessibility grants, and new iOS configuration profiles.
• Re-vet app updates with dynamic analysis on hardened test devices that do not look like analysis sandboxes.
• Enforce minimum OS and patch levels, and retire devices that no longer receive updates.
• Collect network logs per app where privacy policy allows.
• Write a triage step into the mobile incident playbook: collect a backup or sysdiagnose and run MVT before any wipe.

Standards and references

• MITRE ATT&CK: Defense Evasion, Mobile (TA0030)
• MITRE ATT&CK: Mobile Mitigations
• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• Android Developers: Play Integrity API overview
• Google: Google Play Protect
• Android Developers: UserManager user restrictions
• Apple: Restrictions for iPhone and iPad
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Mobile Threat Defense Buyer's Guide · Mobile Spyware Infection Response Playbook