A new variant of Cerber ransomware is in the wild and has built-in anti-sandbox tools to detect hooking-based sandbox environments, as explained in this article by Cyphort . The limitations of a hooking-based approach, where a driver is injected into the target environment and ‘hooks’ API calls, allow the malware to easily detect the analysis environment. This variant of Cerber ransomware will attempt to call a few functions assumed to be monitored with illegal parameters (such as an invalid address). If this sample is executed in a non-sandboxed environment, an exception handler would kick in. In the case of hooking-based sandbox solutions, however, this may lead to a crash.
Figure 1: Possible Hooking Locations in Windows Kernel VMRay Analyzer is not detected by this anti-sandbox (or sandbox evasion ) technique because we have an agentless hypervisor-based approach (Figure 2). This approach does not rely on API hooking or Emulation (the other main technology used for sandboxing) but instead uses our innovative Intermodular Transition Monitoring (ITM). Through the use of ITM, nothing in the analysis environment is modified. We transparently monitor all activities between the malware and any part of the system. You can read more about the specifics of our approach in our Technology Whitepaper .
Figure 2: VMRay Analyzer Runs on a Type 2 Hypervisor One huge advantage of the hypervisor-based approach is that we always intercept at the highest possible semantic level. This is useful for detecting malicious behavior, especially for the Reverse Engineer who wants to find out what the malware actually does.
If you upload one of the samples mentioned in the Cyphort article, you’ll notice that we score a VTI of 91/100 (shown in Figure 3).
Figure 3: Cerber Ransomware VTI Score 91/100 In the analysis report, we see an indicator for an encryption attempt, which is to be expected for a Cerber ransomware sample. An interesting behavior is that the sample tried to call an internal Windows function directly. This is a known technique to avoid detection in hooking-based sandbox solutions that only monitor some functions and have to neglect the rest. In our analysis, however, thanks to Intermodular Transition Monitoring, we detect function calls in the highest semantic level and we’re able to tell that CreateProcessInternal was called directly. There is no legitimate reason to do this – so it’s classified as suspicious behavior.
As mentioned in the beginning, this sample tries to crash the monitoring module by calling some functions with illegitimate parameters. According to the Cyphort article, two of these functions are recvfrom and CryptCreateHash. To verify this, let’s take a closer look at the Function Logfile, which is found on the start page of any finished analysis (under “Overview”), highlighted in Figure 4:
Figure 4: Function Logfile for Cerber Ransomware Once we save this simple text file, we can open it in our favorite text editor to see in Figure 5 that these functions were called with the wrong parameters (0x1c):
Figure 5: Cerber Ransomware Called Wrong Parameters (0x1c) Additionally, this variant of Cerber tries to implement its own version of sleep by calling GetClientRect in a big loop. On some sandboxed systems, this will stop the execution long enough to hide any malicious behavior that would follow after that. However, as seen in Figure 6, it only takes 6 seconds for VMRay Analyzer to finish the loop:
Figure 6: Cerber Ransomware Calling GetClientRect All of the anti-sandbox methods fail to detect VMRay Analyzer. We can see in Figure 7 the result of Cerber’s malicious intent to encrypt files on the target machine
Figure 7: Cerber Ransomware Encrypting the Target Machine This analysis shows how VMRay Analyzer is evasion-resistant against variants of malware, like Cerber Ransomware, that leverage anti-sandboxing techniques. For additional details about how VMRay defeats anti-sandboxing techniques download our new whitepaper Defeat Evasive Malware.
Access the full Cerber Ransomware Analysis Report.
References
