Real World Malware Analysis Part 4: Dynamic Analysis

Last time we used Malwr.com to automate a lot of our analysis, but the process was not without a few sticking points. Malware analysis typically falls into two categories, static and dynamic. These two really go hand-in-hand, and while it is possible to alternate between them, today we will focus on dynamic analysis.

Remember to properly set up your lab environment! We are now going to be running malware on our systems, and we certainly don’t want it spreading. Practice safe analysis!

Getting Started

CaptureBAT: Before we start, there are several tools we should get running. First off let’s start CaptureBAT. I recommend the options highlighted in the following screenshot. In order from top to bottom, they log the results to a file, capture any files that are dropped, placed, or deleted and save them, and finally put all traffic into a pcap. You could alternatively use Wireshark to capture this traffic.

INetSim: The next tool I recommend setting up is INetSim. To do so, first install it from here on a separate device in your isolated network. Once the installation finishes, configure your victim machine to send its DNS requests and gateway to point to the INetSim box.

On the INetSim box, open the /etc/inetsim/inetsim.conf file. Find the DNS section that looks like the following.

inetsim2 — INetSim Config File (DNS Section)

Set the IP to your INetSim box’s IP. There are multiple services such as http, ftp, smtp, etc. that you can configure to respond. As the original phish calls out to a site to download the payload, you can even emulate that interaction by configuring the server to respond with the dropped file. Pretty cool! Check out this guide if you want a more in-depth look at INetSim and how to configure it in more detail.

RegShot: The last tool we are going to want before we run the malware is RegShot. This will allow us to take an image of the registry before and after running the malware which will allow for a comparison between the two. Also remember to snapshot your entire VM if possible. It is nice to be able to start from a clean system.

Start RegShot up, click the “1st shot” button as seen below, and then, after running the malware, take the second shot.

Network Layer

The first thing we want to discern is whether or not the malware will call out to a C2 server. When it was run in the sandbox previously, we did not see any traffic. Maybe in our own environment it will be a little more cooperative. Traffic could yield some useful indicators of compromise that could be subsequently used to identify additional infected devices and block the appropriate egress vectors.

Originally, I just placed the malware on the desktop and ran it. The document did rename the file to putty.exe, perhaps it is performing a check to see if it is the correct name? That ultimately was a dead end. How about placing it in the temp directory? This too was a dead end. What is the deal? Maybe it waits for awhile and then calls back, maybe it is detecting that it is being run in a sandbox, maybe it sets a listening port.

Well I checked listening ports, nothing is looking out of the ordinary.

Maybe I downloaded the file wrong, what if it is looking for a User Agent that matches an Office macro. This is what that looks like:

officeUserAgent — GET Request with MS Office User Agent

That didn’t work either. This is baffling. Hopefully static analysis will help figure out what is going on.

Process

Now we are going to take a look at the process itself. Pull up Process Hacker and find the process in question. Right click and go to Properties. There are several tabs that we can choose, but start with “Modules.” Remember when we unpacked the malware and noted the DLL? In the Modules tab, we can see it being used. One of the first things we see is the label Putty SSH authentication agent like below.

We have already noted that it renamed the malware to putty.exe. So this appears to be yet another attempt to hide it. Here is what a current version of PuTTY looks like in Process Hacker when I run it.

Two DLLs of note that the Malware uses are winhttp.dll and ws2_32.dll (winsock). Both of these are network related. Putty also uses winsock, but not winhttp.dll so they probably aren’t there for show. Despite our frustrations with the lack of network traffic, the malware appears to be network-ready. Further investigation is required.

If you just ran the malware, you might notice that it does not list the lamprey.dll on the page. What if we missed it between the time we ran it and the time we looked at the list of handles? This time, pull up the malware in your favorite debugger and rerun it, step by step. We can then monitor the different calls that it makes.

As we step through the code you might notice some Windows API calls begin to materialize out of nowhere. It is common for malware to encode itself to evade detection and this sample is no different. That is a subject for a future blog post.

Eventually we get to a LoadLibraryExA call which is what actually loads the lamprey.dll we saw earlier (if you want to learn more, go here).

Once this occurs, lamprey.dll appears when we search for handles and DLLs.

What it does is for us to explore later. For now, we have a better picture of what is happening.

System

Next we will take a look at the changes the malware has made to the system. CaptureBAT saves its information by default in C:\Program Files\Capture\logs. In that directory, several tmp files have been saved with notations on where they were created/deleted. It looks something like below:

captureBatFiles1 — Logged Temporary Files and Associated Metadata

Nothing damning so far, although these may require more analysis in the future. On to RegShot! RegShot prints its results like this:

As we can see, a fair amount of changes to the file system were made. The ones I am most interested in are keys added, values added, and values modified (the last two are not shown in the screenshot as the amount was too significant for a single screenshot). This will also require further analysis.

Conclusion

There are a lot of things that need more attention from what we have seen thus far. Dynamic analysis has given us some direction for when we take the jump into static analysis. It also leaves us with a lot of questions, once again. In future posts, we will take a look at the malware encoding, static analysis using IDA, and more. Keep posted and keep hacking!