Detecting analysis environments
Detecting analysis environments
Implementing sandbox detection/anti-analysis checks is a low-effort way to reduce detection surface and bypass security products. Majority of these checks are trivial to implement. Regardless, this is suprisingly effective against online tools such as VirusTotal, however it is unlikely to be very effective (alone) in a real environment with an EDR, since they are typically not reliant on sandboxing.
The idea behind these checks is to detect an unusual environment, such as a virtual machine, indicating a sandbox. If a sandbox environment is detected, we can stop execution. This is done by inspecting things such as the specs of the host machine, display size, mouse movement, hostname, looking for certain files, sleeping before executing and so on.
As some checks are not completely reliable in differentiating real environments from virtual environments, it is a good idea to instead create some sort of scoring system, taking into account all of the checks; a so-called swiss cheese -model. Let's go over some of these checks now.
Inspecting the environment
Running processes
When a program is under manual or automated analysis in a virtual environment, there are typically certain processes active in the system.
We can define a list of forbidden processes which are used by analysts. If one of these processes is running, it indicates that our program is under some form of analysis. Such programs include debuggers, network analyzers, system internals tools such as Procmon, and so on.
We may also inspect the number of processes running on the system. Because of the virtual environments limited resources, the number of processes is typically also limited. In a real system it can be assumed there will be atleast 50 processes running, so if the number of processes is less than that, it indicates a virtual environment
File attributes
We may have a specific filename or path, that is to be expected. However in a sandbox the file is likely to be renamed or located in a different path. This can be used to detect a sandbox environment. We may also have some specific parent process, such as svchost.exe. If the parent is another process, this indicates it is being analysed.
Another useful attribute is the Mark of The Web. When a file is downloaded from the internet, something called a Mark Of The Web (MOTW) will be appended to it. This is a so-called alternative data stream, named "Zone.Identifier". It tells the operating system where the file originates from. In a real situation, the malware would likely have this, but in a sandbox it very possibly could have been stripped out.
Internet access
Sandbox environments may have no internet access. In general, if your payload requires internet access, it is logical to only execute if there is internet access.
Files and registry
Virtual environments often have artifacts indicating the presence of a VM, which you may look for. These include things such as drivers, libraries, programs and more.
List of directories worth checking for these artifacts include C:\Windows\System32 and C:\Windows\System32\Drivers. Interesting registry keys are HKLM\SYSTEM\ControlSet001\Services, HKLM\HARDWARE\Description\System, HKLM\SYSTEM\CurrentControlSet\Control\SystemInformation and others
Virtual environments are often fresh installs, which we can leverage as another detection surface. We can look at things such as recently opened files, previously inserted USB devices. A virtual environment is likely to have none of these or a very small amount.
Inspecting hardware
RAM, storage, CPU and display
Virtual environments have limited resources, and often list completely abnormal specifications for hardware, which can be used as another detection surface for virtual environments.
Virtual environments often have an unusually low amount of memory. Modern machines have atleast 4GB RAM, practically always 8GB or more. Virtual machines on the other hand may list amount of RAM as low as 1GB.
Similarly they are often also only given a small chunk of storage in comparison to real environments. Modern hard drives are practically never under 250GB, while a virtual environment may have something like 60GB of total storage listed.
Modern processors typically have 4 or more cores, but in a virtual environment it the amount of CPU cores may be listed as low as 1 or 2, which is another great point of detection. Display resolution is also often abnormally low, in the likes of 500x500 or less
Device names
Virtual environments often have predictable device names, typically containing strings associated with the hypervisor in question. These can be retrieved through WMI queries.
We can also look for specific virtual devices that would not be present in a typical host system, like pipes and other interfaces used for guest-host communication
BIOS information
BIOS information for virtual environments is typically different from BIOS info in a real machine, and they often contain strings associated with VMs. Malware can create a list of these strings and check if any exist in the BIOS information. This same list may be used in other checks as well.
User interaction
In automated or semi-automated analysis environments, there is often no user interaction, which can be used to detect such environments. Some advanced environments are able to handle user interaction though.
For example, you may check if there is any mouse movement over some period of time, and don't begin execution if there is none. Sandbox environments are unlikely to have any mouse movement. This can be efficiently combined into sleep patching.
Another thing you may do is to explicitly ask for user interaction with some form of prompt. You could pop a simple MessageBox or a fancier dialog box requiring user interaction. Most sandbox environments are not able to click on these boxes.
Sleep patching
Sandbox environments often have a time limit for analysis. To abuse this, we can sleep before executing, hoping the sandbox will timeout.
To counter this, sandbox environments may "speed up time" or patch sleep functions. Ironically, this itself can also be used to detect such an environment. We can sleep for a specific amount of time and then check the time that has passed, from a reliable, preferably external source. Cross-checking multiple sources may be a good idea as well.