Sandbox Evasion Technique

It’s been a while since I’ve written anything on my blog, its been a busy few months at GDT. We’ve been working on developing some cool new security technologies and techniques, and a new type of attack that leverages steganography and DNS exfiltration. I’ll have a write up on that as soon as I get it working.

I wanted to talk a little today about sandboxing, how it works, and how to avoid them.

One of the best tools in the arsenal of a malware researcher is Sandboxes. I use Cisco’s ThreatGrid to sandbox but there are tons of other tools available, as well as options to create your own instead of relying on a service. A sandbox is a secured virtual environment where a researcher can detonate malware and see what it does. You can even go as far as giving it a fake internet connection (that replies with HTTP 200 successful for all outgoing connections) and fake files to interact with. Obviously, if you’re a malware author, you don’t want your malware to run if it means you’ll be discovered, so there are ways to detect whether or not you’ve been sandboxed. The hard part is automating these and reducing your false positive rate.

Am I running in virtualized hardware? 

  1. Querying the hardware your malware is running on should return a list of processors, a hard drive, and RAM info, but the kicker here is that virtualized environments will almost always return the virtualization processor with a “virtualized” flag.
  2. Showing the running processes always show artifacts of virtualization, whether its vmtools.exe, vboxtray.exe, or others.
  3. Checking for known MAC addresses. All VM vendors have virtualized network adapters that have the same first 6 units. 00:05:69 is VMWare, 09:00:27 is VirtualBox. Either one of those on the network adapter will flag your malware that it is running in a VM.

If malware discovers that its in a virtual environment, it can terminate itself immediately (VERY suspicious) or it can run benign processes, like fake system queries, minor file system modifications, and then exit.

So how do we detect if we’re in a VM? I think we can go based on user behavior. In almost all sandbox situations, there isn’t a user actually interacting with the computer! It has all been automated so all you have to do is upload the malware and wait to see what happens. If the malware had a user detection instead of a sandbox detection, I think the false positive rate would drop until sandbox creators started adding mouse and keyboard entropy. The obvious solution to detect a user is to take screenshots at intervals and see if there are differences. An idle VM in a sandbox would have little to no mouse movement, so no new windows would be opened. An active user session would have web browsers being used, file explorers being opened and closed, spreadsheets, and others, so the differences in the screenshots would show many more differences. A high enough entropy difference between screenshots could trigger malicious code to run.

Any other ideas for sandbox evasion?


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.