• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

War Room

Shells from above

RSM logo

  • Home
  • About
  • Blog
  • Talks/Whitepapers
  • Tools
  • Recreation
Home > Forensics > Real World Malware Analysis Part 4: Dynamic Analysis

Real World Malware Analysis Part 4: Dynamic Analysis

June 15, 2015 By Mark Wolters

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.

capturebat
CaptureBAT Options

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.

inetsim
IPv4 Config on the Test 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.

regshot
Regshot

 

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.

 

netstat
Network Connections

 

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.

processhandles
Process Hacker Modules tab for Malware

 

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.

putty
Real Putty in Process Hacker

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).

loadlibraryex
LoadLibraryExA in a Debugger

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

lampreydll
Lamprey Found

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:

regshot2
Regshot Results Output

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!

References

https://www.honeynet.org/node/315

http://processhacker.sourceforge.net/downloads.php

http://www.inetsim.org/downloads.html

http://sourceforge.net/projects/regshot/files/

https://techanarchy.net/2013/08/installing-and-configuring-inetsim/

Share this...
  • Reddit
  • email
  • Facebook
  • Twitter
  • Linkedin

Mark Wolters

Primary Sidebar

Categories

  • Defense
  • Forensics
  • Offense
  • Physical
  • R&D

Most Viewed Posts

  • Sophos UTM Home Edition – 3 – The Setup 10.7k views
  • DLL Injection Part 1: SetWindowsHookEx 10.6k views
  • Leveraging MS16-032 with PowerShell Empire 9.9k views
  • Bypassing Gmail’s Malicious Macro Signatures 9.8k views
  • How to Bypass SEP with Admin Access 8.7k views

Footer

  • RSS
  • Twitter
  • Tools
  • About
  • RSM US LLP

+1 800 903 6264

1 S Wacker Dr Suite 800
Chicago, IL 60606

Copyright © 2021 RSM US LLP. All rights reserved. RSM US LLP is a limited liability partnership and the U.S. member firm of RSM International, a global network of independent audit, tax and consulting firms. The member firms of RSM International collaborate to provide services to global clients, but are separate and distinct legal entities that cannot obligate each other. Each member firm is responsible only for its own acts and omissions, and not those of any other party. Visit for more information regarding RSM US LLP and RSM International.