Intro to Malware Dynamic Analysis: Part 3
By John Hubbard
This is the first post in a wonderfully enlightening series of five. A new post will be posted every Thursday until they’re all posted.
Networking Setup
Now that we’ve got that out of the way, on to the heart of the setup. The key in malware analysis is to keep the samples contained in your virtual machine. Since you are playing with fire, the primary concern is ensuring the malware can’t escape and infect your host or other computers on your network. The assumption in this case is that your virtualization solution is fully patched and the malware you’re analyzing does not contain a VM escape exploit (which is extremely rare). Given that is true, the only other vector an infected virtual machine would be able to use to affect other hosts is the network, which is why networking setup is the crucial piece of the virtual machine setup to get right.
Virtualization Plan A
VMWare and VirtualBox, the two most popular virtualization solutions offer 2 main choices for isolating these machines, both of which will isolate the 2 virtual machines so that they can talk to each other and not the internet or the rest of your network at large. One option is private networking. In this mode, your REMnux and Windows will machine will only be able to talk to each other, and nothing else. This is the most secure option but also has the issue that you will need to plan carefully how to load samples on to the machines, one solution is to flip the networking to bridged mode before analysis, download whatever sample you need from the internet, then go back to private mode.
The other option is to give REMnux two network interface cards, one in bridged mode, and another in private mode. You can then download samples through the bridged mode interface, move them to Windows, and then disconnect it during analysis. This is my preferred method as it avoids reconfiguring the network interfaces every time you want to load something.
Virtualization Plan B
The second networking option is host-only networking. This mode adds the ability for your host machine to talk to the REMnux and Windows victim VMs. This makes it easy to download samples to your host machine and pass them to the VMs through SSH or a web server and avoids the need to change the any networking modes on the VMs. The danger here is that unless you disconnect this interface or firewall it off, your host will be potentially subjected to any exploits the malware might try to launch across the network. For example, if you used this mode on an unpatched Windows host, something like WannaCry would be able to spread to your host and you’d be in for a very bad day. Deciding between these two modes is a balance between convenience and security, and you must choose your own adventure.
Building the Machines
Now that we have the networking modes chosen for our VMs, it’s time to set up the machines for analysis. First the REMnux machine. For dynamic analysis, the idea is to steer all the traffic from the infected VM to REMnux for capture and analysis, and the way you do that is by telling the victim VM that REMnux is your network gateway. This means setting up REMnux with a static IP address that is easy to remember and dropping the correct /etc/network/interfaces file, so it will remember the setup each time it is booted.
For this article, I’m going to pretend we set up REMnux to use IP 10.0.0.10 with subnet 255.255.255.0 on our private networking mode interface (meaning this IP will ONLY be reachable by our victim Windows VM). REMnux itself doesn’t need to have a gateway for this interface as it will never be talking to the internet through it.
Next, start up your Windows virtual machine and bring up the networking control panel window by using Start > Run > ncpa.cpl (the fastest way I’ve found to get there). Set the interface to use a static IP address, I’ll use 10.0.0.20 for this article, subnet 255.255.255.0 and the key item – a gateway of the REMnux VM at 10.0.0.10. In addition, set the DNS Server to be 10.0.0.10, this will ensure all traffic that would normally be bound for the internet will hit REMnux, and all DNS requests will also be sent there. At this point you should be able to ping 10.0.0.10 from Windows, and 10.0.0.20 from REMnux (assuming you don’t have host firewalls on). If this works, the two machines are talking and ready for use, next up is loading the malware.
Loading the Malware
As I mentioned before, how you load a piece of malware will depend upon your networking setup, my favorite method is to download the virus directly to REMnux where it won’t be able to cause harm if it is written for Windows. From there, I’ll either browse to the folder it’s in and use “python -m SimpleHTTPServer” to start up a web server serving the folder contents and browse to it in IE on Windows at 10.0.0.10:8000 or start up sshd in REMnux and download it using WinSCP from Windows. I like the SSH setup a bit more because it allows you to pass dropped files back to REMnux easily after the analysis is over. At this point we’re almost ready to infect the Windows machine, but don’t load that virus up just yet…
Virtual Machine State Preservation
The next very important step is to TAKE A SNAPSHOT. I can’t stress enough how convenient it is to have snapshots of your setup at various stages so that you can snap back to them for whatever scenario you might encounter. I always snapshot Windows in at least three key locations during the setup. One is when I have a brand new clean version of Windows with no tools installed, just the networking and OS set up like I like it, this is in case I get a piece of malware that is very good at checking the OS for analysis tools and I need something that looks like it’s not a malware analysis trap.
Clean Snapshot
I call this snapshot something like “Clean Windows Install”. The 2nd snapshot I make is after I load any dynamic analysis tools and, this is key, with them all running and as ready to go as possible. This simplifies loading a virus and pressing go and quickly getting to business without having to start up everything each time. I call this snapshot “Analysis Ready” and this is the main snapshot I’ll go back to when starting a new analysis. The third snapshot I make is per analysis after I have the malware sitting on the desktop ready to hit go to activate it. Since it is important to be able to fire off a piece of malware several times during analysis, this is a great time saver.
Infection Ready
I call this snapshot “[malware] Infection Ready”, these can also be useful to keep around if you have the hard drive space. Sometimes it’s useful to be able to jump right back in and look at an old sample. For reference, here’s my fully prepped victim VM desktop with tools installed, as well as part of my actual tree of snapshots. Notice in the analysis ready thumbnails I have multiple tools open and ready for use so that all I need to do when I go back to them is drop the malware and hit “go”.
About John
John is a dedicated blue-teamer and is driven to help develop defensive talent around the world. Through his years of experience as the SOC Lead for GlaxoSmithKline, he has real-world, first-hand knowledge of what it takes to defend an organization against advanced cyber-attacks and is eager to share these lessons with his students. As a SANS Cyber Defense curriculum instructor and course author of SEC455, John specializes in threat hunting, network security monitoring, SIEM design and optimization, and constructing defensive postures that allow organizations to protect their most sensitive data. Throughout class, he works with students to explain difficult concepts in relatable and clear language. He illustrates important ideas with stories and demonstrations. John encourages students to push themselves beyond the limit of what they thought possible.
John holds degrees in Electrical and Computer Engineering. His past research spans from malware reverse-engineering to car hacking, mobile app security, and IoT devices. In his free time, John enjoys catching every InfoSec conference he can attend, FPV drone racing, and coffee roasting. John is slowly turning his home into a data center.
Contacting John
Twitter
LinkedIn
SANS Profile
John’s Blog
You must be logged in to post a comment.