Information about Anti-Virtualization and Anti-Sandboxing malware

  • Thread starter Deleted member 21043
  • Start date
D

Deleted member 21043

Thread author
Hello,

I decided to make a thread related to the discussion of "Anti-Virtualization" and "Anti-Sandboxing" explanation and the techniques used by malware writers to accomplish such a thing.

I will start off by Anti-Virtualization:
Anti-Virtualization is basically when a sample will be aware of it being virtualized (e.g. executing in a Virtual Machine) and will prevent itself from executing any actions which are malicious to attempt to trick the user who is testing the sample.

I will list a few ways as to how it may go about doing this:
- Enumerating all the processes on the system and checking for known processes which are related to and link to being ran in a virtualized environment such as: processes used by VMWare for the VMWare Tools, processes used by VirtualBox Guest Additions,...

- Checking the BIOS information.

Anti-Sandboxing:
Anti-Sandboxing is a technique used by malware writers to try to avoid being sandboxed. For example, it may enumerate all the processes and try to pickout ones used by sandboxes. If it is targetting Sandboxie (doesn't want to be sandboxed under Sandboxie), it may have tried to look for SbieCtrl.exe and when found it, make a faked error message about how the sample won't work on this system or an error about it loading and then terminate, or just terminate instantly. As an alternative, it may load but chan


I must make a thread with a sample which is Anti-Virtualization/Anti-Sandboxing to show a real, live example.

There are many ways it can be accomplished. Feel free to leave any questions/ideas you have or any techniques you know of which they use.

Spot any mistakes? Let me know so I can fix them.

Cheers. ;)
 
D

Deleted member 178

Thread author
you want be a serious malware tester ? use an old PC with Winxp or win7 dedicated for malware testing.
 

SecureRoutine

New Member
Aug 15, 2015
3
NOTE: If you find it difficult to read with the small text, please zoom in your browser and it may look much nicer to read! :)

But How we can test the sample if it's Anti-Virtualization and Anti-Sandboxing ?
Well there are many methods for malware to check if it is running in an Virtual Environment or not, and malware authors can write the code differently to make the instruction sequence different as well as find new methods, which could potentially be completely new and unknown. In fact, there are so many methods...

For example, malware could check the drivers/registry keys to help it in detecting if it is being ran in a Virtual Environment, an example of use for this would be for checking if it is being run under a Virtual Machine with VMWare. (e.g. checking for the registry key which shows sign of use for VMWare video driver).

Another example (for Sandboxie especially) which .NET malware tends to like is enumerating processes and checking for Sandboxie prescence.

Checking of GUIDs is a popular method I would say. In case you were unsure, a GUID stands for "Globally Unique Identifier". The checking of device drivers falls under checking of GUIDs.

If you are using VirtualBox/VMWare, make sure not to use Guest Additions/VMware Tools, since these can also be an easy sign of VM detection, for example checking for VirtualBox Gues Additions. A simple API call to RegOpenKeyEx would do the trick. ;)

You may find this paper interesting, it was written by Symantec: http://www.symantec.com/avcenter/reference/Virtual_Machine_Threats.pdf

I mean if you were a programmer and had experience in security programming you could write some code to inject into a process and hook a bunch of functions used for registry access for example and then let you know when they are called and the parameters (for example using this method you could check the parameters to see if it was trying to check if VMWare Tools was installed via the registry)... If not you could look into API logging tools. A good one would be API Monitor, but I wouldn't say for malware analysis. Please see this thread which @Klipsh wrote: http://malwaretips.com/threads/worm-morto-a-malware-analisys.44665/ - during the thread he uses a tool called SysAlyzer which has an API logger feature. However user-mode hooking can be bypassed, for example if the malware unhooked the hooks dynamically or just used a kernel-mode driver to perform the actions... Then you're getting into more advanced things such as kernel debugging, haha! Malware analysis is like a cat-and-mouse game and it gets harder all the time, everyone can be stuck sometimes or miss obvious things...

What about running them with Shadow Defender would they behave in the same manner.
If the Anti-Virtualization was not dependant on checking for processes/where it is being executed, but looking at other factors to check if it is being virtualized/sandboxed, then yes, it can potentially detect Shadow Defender and make itself behave differently. For example, if the Anti-Sandboxing was incredibly simple and just tried to check if Sandboxie was running with it, or was trying to check if it had a module linked inside of it which should not be linked into its execute (for example if an sandboxie which worked on API hooking had injected a DLL into the process' address space) and then you used Shadow Defender, then since it wouldn't detect Sandboxie there then no. However if it had detection methods which also included the use of Shadow Defender then it would be able to detect and behave differently.

It really depends how the malware made the detection. Sometimes malware would target one particular Virtual Machine provider and depending on the technique it may also success for other products. For example, if it was as simple as checking the registry for device drivers for VMWare then that won't work right unless you manually added them using another Virtual Machine provider for virtualization, however if it worked by checking with some CPUID checks then it may pass for multiple virtual machine products.
--------------------------------------------

Sometimes static analysis is better than dynamic analysis. Depending on how much time you have and how many samples you need to process, focus on the key parts. For example, if you find any use of anti-debugging for example, take this point and then move on to the next things. If you try to study every single detail in a sample you are processing, you'll use up to much time and it'll take too long to process the samples. (unless you specifically wanted to analyze a particular sample into detail for educational purposes for example).

However, if you performed static analysis it can be much easier for detecting these sort of virtualization techniques in some cases. Dynamic analysis is still useful though.The only thing is that unless you are dealing with an MSIL sample (therefore the Anti-VM tricks won't be as advanced anyway), you'll have to use disassembly/debugging techniques which means you'll end up result of needing to know some Assembly, well enough for disassembly/debugging.

To get started on Assembly programming/tips you could read a thread written by @Klipsh here: http://malwaretips.com/threads/assembly-quick-tutorial.48161/

Or, to learn Assembly (both x86 and x64) you could read these books:
http://www.amazon.co.uk/Modern-X86-...8&qid=1439743799&sr=8-1&keywords=x86+assembly
http://www.amazon.co.uk/Introductio...8&qid=1439743805&sr=8-5&keywords=x64+assembly

If you are trying to reverse engineer a MSIL (.NET) executable, you can try to decompile the MSIL and then have this converted back to the target language such as C#.NET or VB.NET. MSIL is the Microsoft Intermediate Language, which includes a whole range of subtopics such as CLR (Common Language Runtime), the JIT (Just In Time) compiler.

MSIL executables can also be obfuscated/packed. Therefore you can first attempt to check if the PE is packed or not, and if so then unpack it. Then check for obfuscation. If it is obfuscated then you may be in an issue since some obfuscators can be harder than others, requring you to perform dynamic analysis and use the standard disassembly techniques. However, another member wrote a thread on attempting to use de4dot against MSIL executables which supports deobfuscation for a whole wide range of obfuscators: http://malwaretips.com/threads/malware-analysis-3-reverse-engineering-net-malware.42338/

As for checking if a PE is packed, I might make a thread on it to help... (without having to use Packer Identifiers such as PEiD because sometimes these aren't enough). Unpacking tutorial is another good thing however another member @Klipsh already started this, I won't get in the way! (you can view his entry thread here: http://malwaretips.com/threads/unpacking-introduction.48683/ :)


Winxp or win7 dedicated for malware testing.
While malware is still available for Windows XP and Windows 7, some samples can be specifically engineered and made for Windows 8/8.1 and Windows 10 (since it is now released), and targetting specific things for those Operating Systems (for example a UAC exploit may be engineered towards Windows 10 and not have been specifically made for previous Windows versions). However I must admit, I always loved Windows XP and Windows 7 for malware analysis and testing over all the other Operating Systems. But even with this, static analysis can still be performed easily; just dynamic analysis may not go as expected depending on the sample target I think.


Using a dedicated machine (and not a VM) is actually a very good idea. But sadly not everyone has a spare machine to use/money for an additional one. But yes, it is certainly better and a much more effective method. With this, you can also simulate the networks haha! :) And without a VM, no VM detection to succeed (unless the malware author messed up on his part ha!).

I want to add more but this reply looks too long making it messy now!! :p
 
D

Deleted member 178

Thread author
A malware detecting it is in a virtualized environment is one thing, bypassing the said virtual environment is another thing. What makes Shadow Defender one of the best (not saying the best) is its containment area , it protect the full system and its MBR ; so only the most sophisticated malwares "may" bypass it.

in the past i counted only 2-3 malwares that bypassed SD and at that time it hasn't got its MBR protection.
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top