While monitoring malwares being actively distributed, ASEC analysis team discovered a new dynamic analysis bypass technique. To avoid detection, many of the malwares being distributed check the malware execution environment first, and if it matches the requirement, they crash not to activate.
The technique that will be introduced in this blog is a method of using a certain assembly command and checking if a large-sized memory can be allocated.
1. AVX support availability (VXORPS command)
If a malware that uses ‘VXORPS’ command to run in an environment where AVX is not supported crashes, this malware is likely created with Visual Basic. As mentioned in the recent blog post ‘Distribution of a Visual Basic Malware that Assumes Identity of a Korean Company’ (https://asec.ahnlab.com/1286), many of the malwares that are being distributed use Visual Basic.
This ‘VXORPS’ command is included in AVX (Advanced Vector eXtensions) command set, and it is an XOR logical operator that uses floating-point arithmetic. For CPU to process this command, OS and CPU that support AVX command set must be used.
If malware is executed in an environment where AVX is not supported, it crashes due to an illegal instruction.
Some dynamic analysis tools intentionally configure an old version environment where security update hasn’t been done. Due to such, the environment may not support certain technologies. In the set environment, when the samples composed of the VXORPS command are run, dynamic analysis is bypassed as a malware is not activated due to AppCrash.
Most of the CPUs produced after 2011 support AVX command set, and major OSs that support them are shown in Figure 1.
|Windows||Windows 7 SP1, Windows Server 2008 R2 SP1,|
Windows 8, Windows 10
|Linux||Kernel version 2.6.30 or later|
|macOS||10.6.8 (Snow Leopard) or later|
Table 1. List of the major OS that supports AVX
To check whether the current environment supports AVX, use Coreinfo tool provided by Windows Sysinternals.
2. Memory Allocation Availability
This technique uses VirtualAlloc() API to allocate a memory with the size of 0x3B9AC00 (about 1GB). If this size cannot be allocated, it causes the environment to refer a wrong address leading to crash.
Since the normal dynamic analysis environment (Sandbox) runs various virtual machines (VM) in a PC at once, a great amount of resources is required. Thus, the maximum efficiency can only be achieved by properly allocating resources to each virtual machine (VM), and usually during this process, only the bare minimum RAM is required to run the malware.
This is why 1GB or less memory is allocated most of the time, and the malware was designed to target it. The method to check the memory size and similar techniques have been introduced before.
Upon checking RAPIT result (see Figure 5), we can see that the malware has a feature of injection & time delay for svchost.exe after the technique is conducted and it is a NetWiredRC Backdoor which connects with a specific C2 server.
In the past, some malware used the method of immediately terminating itself if the execution environment was found to be VM or Sandbox. However, the recent-found version forcibly causes crash if such environment is detected as an analysis environment. This is done to stall the discovery of the cause.
Crash can occur if a file is damaged, but a crash that stems from the technique above requires the code responsible for the crash to be found within the malware, and VM must be adjusted in accordance with the troubleshooting procedure. Furthermore, like the method introduced in one of the previous posts (https://asec.ahnlab.com/1202), if it leads to design problems of the VM, more time will be wasted than now, and will eventually lead to the decline of dynamic analysis efficiency.
In addition, as for Cuckoo Sandbox which is commonly known, there is a method of causing a crash on a target monitoring process. We believe that there will be more diverse bypass techniques in the future.
AhnLab’s V3 products detect the malware under the following aliases:
- Trojan/Win32.Inject (2020.02.20.00)
- Malware/Win32.RL_Gerneric (2020.02.14.00)