Virtualization/Sandbox Evasion: System Checks

Adversaries may employ various system checks to detect and avoid virtualization and analysis environments. This may include changing behavior after checking for the presence of artifacts indicative of a virtual environment or sandbox. If the adversary detects a virtual environment, they may alter their malware’s behavior to disengage from the victim or conceal the core functions of the implant. They may also search for virtualization artifacts before dropping secondary or additional payloads.

Checks could include generic system properties such as host/domain name and samples of network traffic. Adversaries may also check the network adapters addresses, CPU core count, and available memory/drive size.

Hardware checks, such as the presence of motion sensors, could also be used to gather evidence that can be indicative a virtual environment. Adversaries may also query for specific readings from these devices.

ID: T1633.001
Sub-technique of:  T1633
Tactic Type: Post-Adversary Device Access
Tactic: Defense Evasion
Platforms: Android, iOS
Version: 1.1
Created: 30 March 2022
Last Modified: 20 March 2023

Procedure Examples

ID Name Description
S1061 AbstractEmu

AbstractEmu can check device system properties to potentially avoid running while under analysis.[1]

S0525 Android/AdDisplay.Ashas

Android/AdDisplay.Ashas can check that the device IP is not in the range of known Google IP addresses before triggering the payload and can delay payload deployment to avoid detection during testing and avoid association with unwanted ads.[2]

S0422 Anubis

Anubis has used motion sensor data to attempt to determine if it is running in an emulator.[3]

S1094 BRATA

BRATA can check to see if it has been installed in a virtual environment.[4]

S0480 Cerberus

Cerberus avoids being analyzed by only activating the malware after recording a certain number of steps from the accelerometer.[5]

S1083 Chameleon

Chameleon can perform system checks to verify if the device is rooted or has ADB enabled and can avoid execution if found.[6]

S0301 Dendroid

Dendroid can detect if it is being ran on an emulator.[7]

S0509 FakeSpy

FakeSpy can detect if it is running in an emulator and adjust its behavior accordingly.[8]

S0423 Ginp

Ginp can determine if it is running in an emulator.[9]

S0544 HenBox

HenBox can detect if the app is running on an emulator.[10]

S0485 Mandrake

Mandrake can evade automated analysis environments by requiring a CAPTCHA on launch that will prevent the application from running if not passed. It also checks for indications that it is running in an emulator.[11]

S0411 Rotexy

Rotexy checks if it is running in an analysis environment.[12]

S0545 TERRACOTTA

TERRACOTTA checks whether its call stack has been modified, an indication that it is running in an analysis environment, and if so, does not decrypt its obfuscated strings[13].

S0427 TrickMo

TrickMo can detect if it is running on a rooted device or an emulator.[14]

G0112 Windshift

Windshift has deployed anti-analysis capabilities during their Operation BULL campaign.[15]

S0489 WolfRAT

WolfRAT can perform primitive emulation checks.[16]

Mitigations

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Detection

ID Data Source Data Component Detects
DS0041 Application Vetting API Calls

Application vetting services could look for applications attempting to get android.os.SystemProperties or getprop with the runtime exec() commands. This could indicate some level of sandbox evasion, as Google recommends against using system properties within applications.

References