Intro to Malware Dynamic Analysis: Part 4

Intro to Malware Dynamic Analysis: Part 4

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.

Link to Part 1

Link to Part 2

Part 3 Link

Network Analysis

Alright, we’ve made it this far, we have two virtual machines on an isolated network. There is a virus on the Windows desktop. REMnux is set up as the internet gateway so that all traffic produced will be steered towards it. What do we do next? Here is the general overview of how I capture network traffic from a virus: The process is to start from nothing, and slowly build up the services the malware will be looking for, taking data at each stage.

This is where your “Infection Ready” snapshot comes in. After each stage described here, I reset the snapshot after all the information is gathered and launch the virus again. What I do is start the malware and watch Wireshark for all connection attempts and what ports they use. After this is done, I reset and move to the second stage. This is usually when I start the “fakedns” script on REMnux to act as a DNS server. This will resolve any domains the malware tries to get to 10.0.0.10, continuing the plan of sending all traffic to REMnux.

REMnux and Traffic

Another benefit of not starting any other services is that when a domain is successfully resolved, the service at that IP isn’t available. Malware will often check another domain name assuming the first one was taken down. This ensures that you will find ALL the domains it tries to contact. Not just the first one in a list of viable options. The other option at this stage is to run the REMnux “accept-all-ips” script, this causes REMnux to receive traffic bound for all IP addresses so that even if your malware communicates with bare IP addresses instead of DNS resolved locations. REMnux will still accept it in the next stage. After all the domain names or IP addresses are gathered here, and the ports are known, I reset it and move on to stage 3.

The third stage is to start up inetsim or another fake service that will produce the expected layer 7 application interactions the malware will be looking for (usually HTTP or SMTP). This means starting Wireshark capturing packets, running the fakedns script in one terminal window, and running inetsim in a second terminal windows.

REMnux as a Decoy

Thus far, REMnux is pretending to be all the internet and has fake services offered for most common protocols. It can be helpful to do “tail -f /var/log/inetsim/service.log” to watch interactions from the Windows victim (see pic below). If your malware is, for example, going to try to contact 3 different domains: evilsite1.com, evilsite2.com, and evilsite3.com.Then download the file /virus.exe over HTTP, you will now have all this information from the various stages of running the virus. You can then act to block these domains and the IP addresses they resolve to in your organization! Another optional step is to manually pull evilsite1.com/virus.exe using wget on REMnux and submit it to your AV vendor for a signature, block the hash from running, or continue with another analysis of this 2nd executable.

As an example, I recently ran WannaCry using this exact setup and was easily able to recover the “kill-switch” domain and the format of the HTTP request made by using this exact setup. You can see the malware make the request which is answered by fakedns, then the HTTP web request is sent which is received and answered by inetsim.

This covers the main tasks needed to understand what a malware sample will on the network. The goal is once you obtain this info, you should check all past network activity in your environment. Then ensure that you prevent any future attempts to reach these malicious sites. At this point, the malware can generally be considered “contained”. Any new infections will either not be able to run or will be stopped due to network level blocks. The next step is to figure out what changes malware made on the victim VM.

About John

John Hubbard

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