Mobile T1633 Virtualization/Sandbox Evasion: Exposing Mobile Evasion With MDM, MTD and Forensics

Mobile malware that checks whether it is running in an emulator or analysis sandbox can stay dormant during app store review and enterprise vetting, then activate on a real phone. MITRE ATT&CK for Mobile tracks this as T1633 Virtualization/Sandbox Evasion, a Defense Evasion technique listed for Android and iOS, with one sub-technique, T1633.001 System Checks. Because the behaviour is designed to defeat analysis, this technique matters most to the people who vet apps: mobile app security teams, MTD and app vetting operators, and SOC analysts who decide whether a "clean" result can be trusted. This guide covers what ATT&CK records, how to make analysis environments harder to fingerprint, and what signals still give the behaviour away. For the matrix as a whole, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• A clean sandbox verdict is not proof of safety. ATT&CK lists more than a dozen mobile families that check for emulators or analysis before running their payload.
• Detection happens mostly at vetting time. ATT&CK's detection strategy places T1633 in application vetting and controlled analysis, not on a live device feed.
• The checks themselves are the indicator. Reads of emulator properties, sensor availability tests and CAPTCHA gates on launch are suspicious in apps that have no business reason for them.
• Use real devices for high-value vetting. Physical test devices with realistic data, sensors and user activity defeat many of the recorded checks.
• Legitimate apps use similar checks. Banking and anti-fraud apps detect emulators and rooting for defensive reasons, so judge context, not the API call alone.

What T1633 covers

ATT&CK describes Virtualization/Sandbox Evasion as detecting and avoiding virtualisation and analysis environments: changing behaviour after finding artefacts that indicate a virtual machine or sandbox, disengaging from the victim, concealing core functions, or checking before dropping further payloads. Adversaries may also check for legitimate user activity.

The sub-technique T1633.001 System Checks lists the kinds of checks: generic system properties such as host or domain name and samples of network traffic, network adapter addresses, CPU core count, available memory and drive size, and hardware checks such as the presence of motion sensors or specific sensor readings. T1633.001 replaced the older ID T1523 Evade Analysis Environment, now revoked. The Enterprise equivalent is T1497, covered in MITRE ATT&CK T1497 Virtualization/Sandbox Evasion.

Procedure examples from ATT&CK

ATT&CK also records Windshift (G0112) deploying anti-analysis capabilities during Operation BULL and SpyC23 using anti-virtualisation techniques. Most recorded examples are Android families; ATT&CK lists the technique for iOS as well, and its iOS detection guidance looks for code that tests UIDevice.currentDevice.model for Simulator strings or compares CMMotionManager device motion availability.

Detection: where the evidence is

ATT&CK's strategy for T1633 is explicit that detection happens primarily during application vetting or controlled analysis, rather than assuming a live device SOC feed. That gives three places to look.

A practical rule for vetting teams: if an app's static analysis shows environment checks, never accept a dynamic "no malicious behaviour" result from an emulator alone. Rerun on a physical device, as described in the Mobile App Security Testing Guide.

Making analysis harder to evade

1. Use physical devices for high-risk apps: real sensors, realistic storage size and a SIM defeat motion, hardware and telephony checks.
2. Seed realistic state: contacts, photos, installed apps and some usage history, because ATT&CK notes checks for legitimate user activity.
3. Drive the UI: automated or manual interaction gets past launch gates such as Mandrake's CAPTCHA.
4. Run long enough: Ashas delayed payload deployment, so extend observation windows and watch fleet telemetry after approval.
5. Vary egress: analyse from network ranges that do not look like known review infrastructure.
6. Compare runs: diff network, file and permission behaviour between emulator and device runs; a difference is itself a finding.

These are defensive analysis practices. The Malware Sandbox Guide covers sandbox design more broadly.

Prevention on the device

ATT&CK lists no specific mitigation for T1633, which fits a technique aimed at analysts rather than device controls. Device-side controls still reduce the damage once evasive malware reaches a phone:

• Android: Play Protect scans apps at install and periodically, including apps from outside Play, and can disable or remove harmful apps; block unknown-source installs on managed devices.
• iOS: distribute apps only through the App Store or MDM and keep devices on current releases.
• Both: gate corporate access on device integrity (Play Integrity MEETS_DEVICE_INTEGRITY, or managed device attestation on Apple) and on MTD risk scores, so a dormant app that later activates meets a second line.

Legitimate use and false positives

OWASP MASVS-RESILIENCE describes defence-in-depth measures such as anti-tampering and runtime application self-protection, and also notes that malware authors use the same techniques to evade analysis. Banking apps commonly detect emulators to block fraud farms. Google's own Play Integrity API returns MEETS_VIRTUAL_INTEGRITY only for emulators in a specific Google Play Games for PC context, and an empty device verdict for an emulator that does not pass Google Play integrity checks. So an environment check alone is not malicious. Raise severity when it is combined with obfuscated strings, dynamic code loading, accessibility service requests, or behaviour that changes after the check. See the Mobile App Attestation guide for the defensive use.

Metrics

• Share of high-risk app submissions analysed on physical devices.
• Count of apps flagged for environment checks during static vetting, and how many were confirmed malicious.
• Number of apps whose behaviour differed between emulator and device runs.
• Time from app approval to first post-approval behaviour alert from fleet telemetry.

Common failure patterns

• Emulator-only vetting: the families in the table above were built to pass exactly this test.
• Short dynamic runs: delayed payloads never execute within a five-minute sandbox window.
• No user interaction: launch gates stop the app from reaching its malicious code paths.
• Vetting once, never again: later updates or downloaded code change behaviour after approval; re-vet on update and watch telemetry.
• Treating every root check as malicious: this floods analysts with banking and DRM apps and hides the real signal.

Framework mapping

Practitioner checklist

• Add environment-check patterns (emulator properties, sensor tests, Simulator strings) to static vetting rules.
• Run high-risk or high-privilege apps on physical, realistically populated test devices.
• Drive the UI and extend dynamic analysis windows to catch delayed payloads.
• Diff emulator and device behaviour and treat a difference as a finding.
• Re-vet apps on every update, not only on first submission.
• Gate corporate access on device integrity and MTD risk, so evasive apps meet a second control.
• Allow-list known legitimate root and emulator checks to cut noise.

Standards and references

• MITRE ATT&CK: T1633 Virtualization/Sandbox Evasion (Mobile)
• MITRE ATT&CK: T1633.001 System Checks
• OWASP: Mobile Application Security Verification Standard (MASVS-RESILIENCE)
• Android Developers: Play Integrity API integrity verdicts
• Google Play Help: Use Google Play Protect to help keep your apps safe
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Android Banking Trojans Guide · Mobile Threat Defense Buyer's Guide