Most sandboxes typically have some API monitoring module to be able to identify and describe what the program is trying to do. In order to do this, they hook APIs that they want to monitor using various techniques. Typically, a hook works by modifying the first address of the API call instructions to insert a jump to a specific address of the hooking module. The hooking module then proceeds to do whatever it wants to do with that code and then will jump back to the original API address. The following diagram depicts the typical flow of execution.
Just recently, we found Cerber samples that behave differently when hooked. When it is not hooked, the sample will just proceed with its normal malware routine. The sample is a NSIS compiled malware and it has the following files:
Initially, it will create another process of itself in SUSPENDED state. The idea is to unpack itself in the memory and inject this unpacked code into the next process. This technique is sometimes called “process hollowing”.
After creating a suspended process, it loads fosullas.dll. This dll is responsible for decrypting/unpacking the second stage of malware by reading the file “Blackbuck”, decrypting it and injecting it into the suspended process.
When the second stage is loaded, it starts the typical cerber ransomware routine. The next thing you know, you are looking at the following message on your desktop which says all your files are encrypted.
You can also see the following files in folders with encrypted files.
Network Communication
The malware connects to specific IP ranges and port 6892 via UDP for its Command and Control.
What happens when there is hooking?
Based on this research, we have identified the following techniques used by Cerber as Anti-Sandbox tricks:
- Crash the hooking module
- Call useless window APIs in a long loop
- Steal API addresses from the main executable’s IAT
When we try to hook APIs to monitor its behavior, the following window appears, and no Cerber Ransomware routine is observed.
Clicking on the “Next” to see if it does something but no malicious routine was observed.
We have tried a few sandboxes and different API monitors and observed the same behavior, which leads us to think that this malware detects for any active hooking. But how?
Intention to Crash the Hooking Module
To find this out how does it detect the hook, we attached a debugger to the API Hooking module and see its behavior.
This is where we observed some exceptions. The exception was an access violation in address 0x0000001C.
We looked at the stack to see where is this exception originating from. It originates from an API call in fossulas.dll. It is a call to recvfrom and it has the following interesting parameters.
Notice the parameters, socket, bufsize, flags, and pfromlen all have the same value (28 or 0x1C). Looks familiar? Isn’t it the same address causing an exception?
So we fired up IDA pro to see what is inside fossulas.dll.
The mentioned parameters above are referenced to a value in address 0x1001014C with hardcoded value of 0x1C.
We tried to bypass the exception above and executed the program. Then, we found another exception, this time on a call to CryptCreateHash.
The call to CryptCreateHash would again contain hardcoded values.
We looked at the other routines of fossulas.dll and it seems to be calling APIs with hardcoded values. For instance, the hKey in the call to RegQueryValueW is the same value in address 0x1001014C.
Based on the observation above, fossulas.dll appears to try to create an exception by arbitrarily calling APIs with invalid arguments. So what does this mean to the sandbox?
Normally, when there is no hooking involved, it will not be a problem. Most of the time, windows libraries have some exception handling in place.
However, when a hooking module is involved, it will possibly pose a problem because it would cause an exception to the hooking module when those APIs are hooked. Thus it would crash the program when there is no exception handling in place.
In summary, it does not try to detect the hook, instead it tries to crash the hooking module.
Call Useless window APIs in a long loop
We have also observed the samples we checked try to delay and call useless APIs in a long loop. Normally, in a sandbox, the execution period is cut into short time. When a delay is introduced, the full behavior of the malware will not be monitored. We observed that in a sandbox where these APIs are hooked, these calls did really take a long time to finish.
GetClientRect inside a long double loop on sample 260c4918a8655949d58b2e8d11d1562a
FindWindowExA and GetCurrentProcesId inside a long double loop on sample 037a8be0c33ab5f34c150de153402048
Steal API addresses from the main executable’s IAT
Before unpacking the second stage, Cerber needs some APIs for reading and decrypting the second tage. However, the way it retrieves those APIs is interesting. It traverses through the main executable’s (in this case the NSIS compiled file) Import Directory Virtual Address and retrieve the APIs that it need by enumerating all the import APIs and do some partial string matching.
Our friends at McAfee have a detailed explanation of how this work. https://securingtomorrow.mcafee.com/mcafee-labs/ransomware-families-use-nsis-installers-to-avoid-detection-analysis/
What happens in a sandbox?
In some of the Sandbox we tested where they employ IAT Hooking method, the above routine will fail as in an IAT Hook, the Import Address table after hook points first to the hooking module.
The following 2 diagrams show what changed in the Import Address when there is a hook or not. Notice the difference in the First Thunk Address. In the first image, there is no hook so it was able to traverse through the IAT and retrieve the first API imported by the main executable which is GetFileAttributesA. In the second image where there is hook, the First Thunk points the address space of the hooking module, 0x6D64415C. This could result into some invalid address de-referencing as we noticed in this sample or the malware will just fail to retrieve those APIs and will not proceed on unpacking routine.
No Hooking
With Hook
Why display an installation window?
Interestingly, the malware could have just chosen to make itself crash but why would it need to display that installation window? We believe that this is an added step of the malware to trick the sandbox into thinking that the program is a normal installation. Going through the typical installation routine would add or contribute to the conviction of the sandbox that the program is “normal”.
What can sandbox do to protect itself against this technique
Sandboxes always need to look for new armoring techniques. In the first anti-armoring technique discussed here, a sandbox can employ exception handlers to handle these types of errors. This gives a protection to the hooking module to not crash. For the long loop, a sandbox can identify the behavior as suspicious or it can try to accelerate those long loops if it is capable to do so.
We believe that these Cerber samples are related to an ongoing spam campaign called ‘Blank Slate‘. Cyphort detects this malware as TROJAN_ZERBER.DC.
Special thanks to Alex Burt, Anoop Saldanha, Abhijit Mohanta and the rest of the Cyphort Labs Team for helping with analysis.
Indicators of Compromise
MD5
260c4918a8655949d58b2e8d11d1562a
037a8be0c33ab5f34c150de153402048
IP Ranges
149.202.122.0/27
149.202.248.0/22
149.202.64.0/27
The post New Breed of Cerber Ransomware Employs Anti-Sandbox Armoring appeared first on Cyphort.