Shmoocon 2006: Behavioral malware analysis using sandnets

sandnet

A common approach to analyzing malware is to turn it loose inside of a VMware session, but some malware have methods for detecting virtual machines and will refuse to run if they encounters one. Joe Stewart has developed a tool called Truman that can be used to construct a sandnet. The sandnet expands on the idea of using VMware as a sandbox. The malware runs inside of a normal OS environment not a virtual one and it interacts with what it thinks is an entire network.

This is how the setup works: You have two machines connected using a crossover network cable. Machine 1 is the server and machine 2 is the client that the malware will be run on. Machine 2 is booted via PXE into a clean Windows install (or whatever OS your malware is for). Once booted it begins watching a directory on the server for the malware’s exe. Once you copy the executable into the directory the Windows machine copies the file and executes it. After 10 minutes the Windows machine dumps its physical memory to disk and then shuts down. An image of the newly infected Windows file system is then saved. The client machine then boots into Linux for analysis of the new Windows image. Truman improves analysis speed because you don’t have to constantly reimage the client machine by hand.

The PXE server also acts as a fauxinternet for the client machine. By watching tcpdump you can see what outbound connections the malware is trying to make. To aid in this process, Truman includes several fauxservers which are just simple Perl scripts designed to act like servers. The fauxservers tell the malware exactly what it wants to hear in hopes that it will cough up logins, passwords and other useful information.

Comments

  1. wraezor says:

    One of the coolest security ideas in a while. Very nice.

  2. william says:

    wow, interesting concept.

  3. Fahad says:

    Why not just modify the VM-program to prevent detection by the malwares. Perhaps the malware’s designed to detect a BIOS type that is only specific to VMware, or even a certain drive type, etc. Some of the CD-drive emulation programs are clever at concealing their existence, and copy-protection schemes are often fooled by it.

  4. Joe mentioned a specific flaw with VMware that lets it be detected using just a few lines of assembly.

  5. Krunch says:

    Sounds like honeyd.

    The “specific flaw” probably refers to the “red pill”.

    http://invisiblethings.org/papers/redpill.html

  6. Jordan says:

    There are more than a few ways to detect vmware. Here’s a couple I know of offhand:

    – Drivers if you’ve installed the vmware tools are vmware specific.
    – MAC address is vmware specific.
    – There’s the red pill and a few other similar techniques that are way beyond my understanding that do either memory or timing attacks
    – Then there’s the vmware backdoor (http://chitchat.at.infoseek.co.jp/vmware/backdoor.html)
    – Plus, the custom vmware bios could be probed.

    And probably a whole lot of other ones I’ve never heard of. It’s pretty darn hard to catch code as it’s executing and keep it from detecting it’s being sandboxed unless you’re going incredibly carefully and really know what you’re doing. So instead, just make the entire world the sandbox (Like the Truman show!! Great name, Joe!). Yeah, definitely a cool idea.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 94,463 other followers