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.
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.
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.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Application vetting services could look for applications attempting to get
getprop with the runtime
exec() commands. This could indicate some level of sandbox evasion, as Google recommends against using system properties within applications.