Welcome back, my aspiring malware analysts!

In my introductory tutorials on reverse engineering malware (Part 1-5) we introduced many new concepts. Now its time to put some of those concepts to work and begin analyzing some sample malware!

In Part 1 of this series, I pointed out that there are two primary ways of analyzing malware; (1) code level and (2) system level or behavioral. As a general rule, one should always use the simplest method first in doing just about anything (otherwise, you may expend considerable time, energy and resources when it wasn’t necessary) and the same applies to analyzing malware. System or Behavioral analysis is much simpler than code level analysis, so let’s begin there.

In this type of analysis, we are more interested in what the malware does. Does it make any (1) changes to the registry, (2) what processes does it run, (3) what files run, and (4) what network connections does it make? A lot can be determined from this easily garnered information.

In this tutorial, we will be using a simple piece of malware known as as the svrcp.exe trojan, for a lack of a better name. Different software vendors identify and name it differently such as IRC.SRVCP.Trojan, TROJ_SRVVP or Troj/Narnar, among others.

It is often used for beginning malware analysis because of its relative simplicity. This Trojan was first identified around 2000 and could be controlled by private messaging over an IRC cahnnel. It was likely used for distributed password cracking and/or DDoS attacks.

We will use it here to introduce some introductory concepts of behavioral/system analysis of malware.

Step #1: Create a Safe Workspace

The first step is create a safe environment. I will be using a VirtualBox with Windows 7 installed. I’ve made certain that network connections are set to host-only or Internal Network, so that the malware can not connect outside my sandboxed environment. Now, make certain that you take a snapshot of your system before you start, so that you can return your system to its initial state after running the malware.

Step #2 Install SysInternals

Next, if you have not already, install sysinternals from Microsoft to you your sandboxed system (you will likely need to NAT your sandboxed system to do so, but remember to isolate it from the internet once your have done so). You can download sysinternals here. (for more on sysinternals see my tutorial, Digital Forensics, Part 8)

Step #3: Run the Malware

Once you have installed the svrcp.exe directory to your sandboxed system, right click and run as administrator the file srvcp.exe

When you do, open your task manager to make certain the malware is running.

Step #4: Check the Registry for Persistence

If the malware is to be persistent (restart each time the system reboots) it will likely need to alter the registry under one of the many keys that initiate software at bootup (see my article on Digital Forensics, Part 5: Finding Evidence in the Registry for more information on registry keys).

In this case, because svrcp.exe was originally designed for the Win NT environment, it attempts to add a registry key at;

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft|Windows\CurrentVersion\Run

It adds an entry named Service Profiler and a key srvcp.exe that will start the malware each time the system boots.

If we open Process Monitor and filter for the process by name (svrcp.exe) we can view each of the actions the malware attempts to perform. If we scroll down a bit, we can see the process querying the HKLM and setting a value at HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run making the malware persistent.

If we return to the Process Explorer and remove the filter for svrcp.exe, we can once again see all the processes. Note that svrcp.exe is running as PID (Process ID) 67988.

Now, let’s right click on the svrcp.exe process and select “Properties”.

You should get a screen like that below. Let’s click on the Strings tab to the upper right.

The Strings tab will initiate a search for recognizable strings (ASCII text) within the code. Very often, we can find comments and other useful information among the strings. As we will see later in these lessons, these strings were used to decrypt some of the code and passwords.

Step #7: Viewing TCP Sockets and Connections with TCPView

To view all the TCP sockets and connections to our test Win 7 system, we can open TCPView from the sysinternals suite. Once again, we can see the svrcp.exe process has opened a TCP socket, but has not yet completed a connection. If we allowed the sandboxed system to connect to the Internet, this process would reach out to its C & C server via this process.

Step #8: Open the gus.ini

Now, let’s open that gus.ini file that was in the same directory as our executable. This file contains key information the malware uses to login to its C & C server. Notice that it uses a Nick (nickname) of “mikey”, a Channel of “mikag soup” and then attempts to connect to multiple IRC servers on port 6666 (e.g. irc.mcs.net:6666).

When it connects to the IRC server, the attacker can then send commands to the malware via private messages thereby controlling the malware and the infected system.

Conclusion

Malware analysis is among the most valuable skills within the field of digital forensics. It requires a high level of understanding of Windows processes and some assembler. The first and easiest step in analyzing malware is simply to watch its behavior. From its behavior we can discern quite a bit about the malefactor’s intent.

In my next tutorial, we’ll dig a bit deeper and look at this malware at the code level.

If you want to become a malware analyst or just expand your forensic skills, sign up for our “Reverse Engineering Malware” course coming up soon.