With the ever changing facets and trends of the Cyber attacks , Sandboxing technology using virtual machines has become the inevitable tool for researchers to analyze the behaviour of the malwares in abbreviated period of time. With the huge inflow of the samples , sandboxes based on virtualized environment is another premier tool in the armoury. Sandboxing provides the isolated setup which can execute the malware binaries within , without effecting the underneath host resources . This can help researchers quickly analyze and locate the malicious behaviour of the sample and produce the heuristic / behavioural signatures .
But there are two sides of the every coin . Sandboxes usually leaves too many traces and evidences into the system to make itself a completely imperceptible environment. Malware authors tend to come out with the innovative methods to detect the virtualized / sandboxing territory and cease to execute the moment they discover it. Subsequently, obscuring the setup has become very significant when they are builded to execute tons of malwares.
There have been several researched and documented methods of distinguishing the sandbox area . For instance , traditionally , malwares use to search for the known artifacts like running process , registry keys , file systems for noticing the sandbox . These methods are easily noticeable by the researchers. Today , Advance persistent threats and targeted attacks tend to wait for the human interaction with the system to activate the malicious code . Since automated malware analysis frameworks process millions of samples per day , human interaction is bare minimal and malwares does not replicate as a result. One of the very interesting papers that has been published and presented by FireEye researchers here , documents bunch of interesting techniques to perceive the sandbox.
Few days back , I was researching a malware that showed a lot of behaviour on the physical system and other sandboxes but refused to execute on the vmware . I was pretty keen to figure out what exactly it did . Eventually , after a session of debugging , I was able to determine that it accessed the registry key to detect if it was running under VMware , Vbox and Qemu but the interesting aspect was it never used the known registry APIs . If we look at the imports of the binary :
Malware importing device APIs |
If we look at the nature of the APIs that is imported by the malware , experienced eyes can make an educated guess. These are the device APIs , though very seldomly used , but can fetch you the properties of the underlying device / hardware . Malware trying to extract the device properties is most likely performing environment checks.
After all the deobfuscation , it calls SETUPAPI.SetupDiGetClassDevsA( ) API to get the handle to the device information set that contains device information elements for a local computer
At this point , if we check the memory of the process , the strings to match has already been decrypted:
Next , it passes the returned handle to the SetupDiEnumDeviceInfo ( ) that returns the structure relating to the device information set . More information about the API and structure is available on MSDN.
Then eventually calls SETUPAPI.SetupDiGetDeviceRegistryPropertyA ( ) to access the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\SCSI\Disk&Ven_VMware_&Prod_VMware_Virtual_S&Rev_1.0\4&5fcaafc&0&000
They key that it accesses is the "FriendlyName" of the above registry key:
And then finally calls the functions to match the value against the Vbox , Virtual HD , Vmware and Qemu .
Below is the top level view of the rest of the code checking for variety of virtual environments :
Interesting ingredient of this malware was all the checks that it performed does not seem to be obviously visible to the reverser. Above that , all of these validation code was concealed below few layers of obfuscation which kind of makes it harder to expose.
As malware authors get smarter , I am pretty certain that level of discretion in detecting the virtualized / sandbox environment is going to grow.
No comments:
Post a Comment