BASIC DYNAMIC ANALYSIS
Dynamic analysis is any examination performed after
executing malware. Dynamic analysis techniques are
the second step in the malware analysis process.
Dynamic analysis is typically performed after basic
static analysis has reached a dead end, whether due to obfuscation, packing, or the analyst having exhausted the available static analysis techniques.
It can involve monitoring malware as it runs or examining the system after
the malware has executed.
Unlike static analysis, dynamic analysis lets you observe the malware’s
true functionality, because, for example, the existence of an action string
in a binary does not mean the action will actually execute. Dynamic analysis
is also an efficient way to identify malware functionality. For example, if
your malware is a keylogger, dynamic analysis can allow you to locate the
keylogger’s log file on the system, discover the kinds of records it keeps,
decipher where it sends its information, and so on. This kind of insight
would be more difficult to gain using only basic static techniques.
40 Chapter 3
Although dynamic analysis techniques are extremely powerful, they
should be performed only after basic static analysis has been completed,
because dynamic analysis can put your network and system at risk. Dynamic
techniques do have their limitations, because not all code paths may execute
when a piece of malware is run. For example, in the case of command-line
malware that requires arguments, each argument could execute different
program functionality, and without knowing the options you wouldn’t be
able to dynamically examine all of the program’s functionality. Your best
bet will be to use advanced dynamic or static techniques to figure out how
to force the malware to execute all of its functionality. This chapter describes
the basic dynamic analysis techniques.
Sandboxes: The Quick-and-Dirty Approach
Several all-in-one software products can be used to perform basic dynamic
analysis, and the most popular ones use sandbox technology. A sandbox is a
security mechanism for running untrusted programs in a safe environment
without fear of harming “real” systems. Sandboxes comprise virtualized environments that often simulate network services in some fashion to ensure that
the software or malware being tested will function normally.
Using a Malware Sandbox
Many malware sandboxes—such as Norman SandBox, GFI Sandbox, Anubis,
Joe Sandbox, ThreatExpert, BitBlaze, and Comodo Instant Malware Analysis—
will analyze malware for free. Currently, Norman SandBox and GFI Sandbox
(formerly CWSandbox) are the most popular among computer-security
professionals.
These sandboxes provide easy-to-understand output and are great for
initial triage, as long as you are willing to submit your malware to the sandbox websites. Even though the sandboxes are automated, you might choose
not to submit malware that contains company information to a public website.
NOTE You can purchase sandbox tools for in-house use, but they are extremely expensive.
Instead, you can discover everything that these sandboxes can find using the basic techniques discussed in this chapter. Of course, if you have a lot of malware to analyze, it
might be worth purchasing a sandbox software package that can be configured to process malware quickly.
Most sandboxes work similarly, so we’ll focus on one example, GFI
Sandbox. Figure 3-1 shows the table of contents for a PDF report generated
by running a file through GFI Sandbox’s automated analysis. The malware
report includes a variety of details on the malware, such as the network activity it performs, the files it creates, the results of scanning with VirusTotal, and
so on.
Basic Dynamic Analysis 41
Figure 3-1: GFI Sandbox sample results for win32XYZ.exe
Reports generated by GFI Sandbox vary in the number of sections they
contain, based on what the analysis finds. The GFI Sandbox report has six
sections in Figure 3-1, as follows:
The Analysis Summary section lists static analysis information and a highlevel overview of the dynamic analysis results.
The File Activity section lists files that are opened, created, or deleted for
each process impacted by the malware.
The Created Mutexes section lists mutexes created by the malware.
The Registry Activity section lists changes to the registry.
The Network Activity section includes network activity spawned by the malware, including setting up a listening port or performing a DNS request.
The VirusTotal Results section lists the results of a VirusTotal scan of the
malware.
Sandbox Drawbacks
Malware sandboxes do have a few major drawbacks. For example, the sandbox simply runs the executable, without command-line options. If the malware executable requires command-line options, it will not execute any code
that runs only when an option is provided. In addition, if your subject malware is waiting for a command-and-control packet to be returned before
launching a backdoor, the backdoor will not be launched in the sandbox.
The sandbox also may not record all events, because neither you nor the
sandbox may wait long enough. For example, if the malware is set to sleep
for a day before it performs malicious activity, you may miss that event. (Most
sandboxes hook the Sleep function and set it to sleep only briefly, but there
is more than one way to sleep, and the sandboxes cannot account for all of
these.)
42 Chapter 3
Other potential drawbacks include the following:
Malware often detects when it is running in a virtual machine, and if a
virtual machine is detected, the malware might stop running or behave
differently. Not all sandboxes take this issue into account.
Some malware requires the presence of certain registry keys or files on the
system that might not be found in the sandbox. These might be required
to contain legitimate data, such as commands or encryption keys.
If the malware is a DLL, certain exported functions will not be invoked
properly, because a DLL will not run as easily as an executable.
The sandbox environment OS may not be correct for the malware. For
example, the malware might crash on Windows XP but run correctly in
Windows 7.
A sandbox cannot tell you what the malware does. It may report basic
functionality, but it cannot tell you that the malware is a custom Security
Accounts Manager (SAM) hash dump utility or an encrypted keylogging
backdoor, for example. Those are conclusions that you must draw on
your own.
Running Malware
Basic dynamic analysis techniques will be rendered useless if you can’t get
the malware running. Here we focus on running the majority of malware
you will encounter (EXEs and DLLs). Although you’ll usually find it simple
enough to run executable malware by double-clicking the executable or
running the file from the command line, it can be tricky to launch malicious DLLs because Windows doesn’t know how to run them automatically.
(We’ll discuss DLL internals in depth in Chapter 7.)
Let’s take a look at how you can launch DLLs to be successful in performing dynamic analysis.
The program rundll32.exe is included with all modern versions of Windows. It provides a container for running a DLL using this syntax:
C:>rundll32.exe DLLname, Export arguments
The Export value must be a function name or ordinal selected from the
exported function table in the DLL. As you learned in Chapter 1, you can use
a tool such as PEview or PE Explorer to view the Export table. For example,
the file rip.dll has the following exports:
Install
Uninstall
Install appears to be a likely way to launch rip.dll, so let’s launch the malware as follows:
C:>rundll32.exe rip.dll, Install
Basic Dynamic Analysis 43
Malware can also have functions that are exported by ordinal—that is,
as an exported function with only an ordinal number, which we discussed
in depth in Chapter 1. In this case, you can still call those functions with
rundll32.exe using the following command, where 5 is the ordinal number
that you want to call, prepended with the # character:
C:>rundll32.exe xyzzy.dll, #5
Because malicious DLLs frequently run most of their code in DLLMain
(called from the DLL entry point), and because DLLMain is executed whenever
the DLL is loaded, you can often get information dynamically by forcing the
DLL to load using rundll32.exe. Alternatively, you can even turn a DLL into
an executable by modifying the PE header and changing its extension to
force Windows to load the DLL as it would an executable.
To modify the PE header, wipe the IMAGE_FILE_DLL (0x2000) flag from the
Characteristics field in the IMAGE_FILE_HEADER. While this change won’t run any
imported functions, it will run the DLLMain method, and it may cause the malware to crash or terminate unexpectedly. However, as long as your changes
cause the malware to execute its malicious payload, and you can collect information for your analysis, the rest doesn’t matter.
DLL malware may also need to be installed as a service, sometimes with a
convenient export such as InstallService, as listed in ipr32x.dll:
C:>rundll32 ipr32x.dll,InstallService ServiceName
C:>net start ServiceName
The ServiceName argument must be provided to the malware so it can be
installed and run. The net start command is used to start a service on a Windows system.
NOTE When you see a ServiceMain function without a convenient exported function such as
Install or InstallService, you may need to install the service manually. You can do
this by using the Windows sc command or by modifying the registry for an unused service, and then using net start on that service. The service entries are located in the
registry at HKLM\SYSTEM\CurrentControlSet\Services.
Monitoring with Process Monitor
Process Monitor, or procmon, is an advanced monitoring tool for Windows
that provides a way to monitor certain registry, file system, network, process,
and thread activity. It combines and enhances the functionality of two legacy
tools: FileMon and RegMon.
Although procmon captures a lot of data, it doesn’t capture everything.
For example, it can miss the device driver activity of a user-mode component
talking to a rootkit via device I/O controls, as well as certain GUI calls, such
as SetWindowsHookEx. Although procmon can be a useful tool, it usually should
not be used for logging network activity, because it does not work consistently across Microsoft Windows versions.
44 Chapter 3
WARNING Throughout this chapter, we will use tools to test malware dynamically. When you test
malware, be sure to protect your computers and networks by using a virtual machine,
as discussed in the previous chapter.
Procmon monitors all system calls it can gather as soon as it is run.
Because many system calls exist on a Windows machine (sometimes more
than 50,000 events a minute), it’s usually impossible to look through them
all. As a result, because procmon uses RAM to log events until it is told to
stop capturing, it can crash a virtual machine using all available memory. To
avoid this, run procmon for limited periods of time. To stop procmon from
capturing events, choose FileCapture Events. Before using procmon for
analysis, first clear all currently captured events to remove irrelevant data by
choosing EditClear Display. Next, run the subject malware with capture
turned on. After a few minutes, you can discontinue event capture.
The Procmon Display
Procmon displays configurable columns containing information about individual events, including the event’s sequence number, timestamp, name of
the process causing the event, event operation, path used by the event, and
result of the event. This detailed information can be too long to fit on the
screen, or it can be otherwise difficult to read. If you find either to be the
case, you can view the full details of a particular event by double-clicking
its row.
Figure 3-2 shows a collection of procmon events that occurred on a
machine running a piece of malware named mm32.exe. Reading the Operation column will quickly tell you which operations mm32.exe performed on
this system, including registry and file system accesses. One entry of note
is the creation of a file C:\Documents and Settings\All Users\Application Data
mw2mmgr.txt at sequence number 212 using CreateFile. The word SUCCESS
in the Result column tells you that this operation was successful.
Figure 3-2: Procmon mm32.exe example
Filtering in Procmon
It’s not always easy to find information in procmon when you are looking
through thousands of events, one by one. That’s where procmon’s filtering
capability is key.
Basic Dynamic Analysis 45
You can set procmon to filter on one executable running on the system.
This feature is particularly useful for malware analysis, because you can set a
filter on the piece of malware you are running. You can also filter on individual system calls such as RegSetValue, CreateFile, WriteFile, or other suspicious
or destructive calls.
When procmon filtering is turned on, it filters through recorded events
only. All recorded events are still available even though the filter shows only a
limited display. Setting a filter is not a way to prevent procmon from consuming too much memory.
To set a filter, choose FilterFilter to open the Filter menu, as shown in
the top image of Figure 3-3. When setting a filter, first select a column to filter on using the drop-down box at the upper left, above the Reset button.
The most important filters for malware analysis are Process Name, Operation, and Detail. Next, select a comparator, choosing from options such as Is,
Contains, and Less Than. Finally, choose whether this is a filter to include or
exclude from display. Because, by default, the display will show all system
calls, it is important to reduce the amount displayed.
Figure 3-3: Setting a procmon filter
NOTE Procmon uses some basic filters by default. For example, it contains a filter that excludes
procmon.exe and one that excludes the pagefile from logging, because it is accessed
often and provides no useful information.
46 Chapter 3
As you can see in the first two rows of Figure 3-3, we’re filtering on Process Name and Operation. We’ve added a filter on Process Name equal to
mm32.exe that’s active when the Operation is set to RegSetValue.
After you’ve chosen a filter, click Add for each, and then click Apply. As a
result of applying our filters, the display window shown in the lower image displays only 11 of the 39,351 events, making it easier for us to see that mm32.exe
performed a RegSetValue of registry key HKLM\SOFTWARE\Microsoft\Windows
CurrentVersion\Run\Sys32V2Controller (sequence number 3 using RegSetValue).
Double-clicking this RegSetValue event will reveal the data written to this location, which is the current path to the malware.
If the malware extracted another executable and ran it, don’t worry,
because that information is still there. Remember that the filter controls only
the display. All of the system calls that occurred when you ran the malware
are captured, including system calls from malware that was extracted by the
original executable. If you see any malware extracted, change the filter to display the extracted name, and then click Apply. The events related to the
extracted malware will be displayed.
Procmon provides helpful automatic filters on its toolbar. The four filters
circled in Figure 3-4 filter by the following categories:
Registry By examining registry operations, you can tell how a piece of
malware installs itself in the registry.
File system Exploring file system interaction can show all files that the
malware creates or configuration files it uses.
Process activity Investigating process activity can tell you whether the
malware spawned additional processes.
Network Identifying network connections can show you any ports on
which the malware is listening.
All four filters are selected by default. To turn off a filter, simply click the
icon in the toolbar corresponding to the category.
Figure 3-4: Filter buttons for procmon
NOTE If your malware runs at boot time, use procmon’s boot logging options to install procmon as a startup driver to capture startup events.
Analysis of procmon’s recorded events takes practice and patience, since
many events are simply part of the standard way that executables start up.
The more you use procmon, the easier you will find it to quickly review the
event listing.
Basic Dynamic Analysis 47
Viewing Processes with Process Explorer
The Process Explorer, free from Microsoft, is an extremely powerful task
manager that should be running when you are performing dynamic analysis.
It can provide valuable insight into the processes currently running on a
system.
You can use Process Explorer to list active processes, DLLs loaded by a
process, various process properties, and overall system information. You can
also use it to kill a process, log out users, and launch and validate processes.
The Process Explorer Display
Process Explorer monitors the processes running on a system and shows
them in a tree structure that displays child and parent relationships. For
example, in Figure 3-5 you can see that services.exe is a child process of
winlogon.exe, as indicated by the left curly bracket.
Figure 3-5: Process Explorer examining svchost.exe malware
Process Explorer shows five columns: Process (the process name),
PID (the process identifier), CPU (CPU usage), Description, and Company
Name. The view updates every second. By default, services are highlighted in
pink, processes in blue, new processes in green, and terminated processes in
red. Green and red highlights are temporary, and are removed after the process has started or terminated. When analyzing malware, watch the Process
Explorer window for changes or new processes, and be sure to investigate
them thoroughly.
48 Chapter 3
Process Explorer can display quite a bit of information for each process.
For example, when the DLL information display window is active, you can
click a process to see all DLLs it loaded into memory. You can change the
DLL display window to the Handles window, which shows all handles held by
the process, including file handles, mutexes, events, and so on.
The Properties window shown in Figure 3-6 opens when you double-click
a process name. This window can provide some particularly useful information about your subject malware. The Threads tab shows all active threads,
the TCP/IP tab displays active connections or ports on which the process is
listening, and the Image tab (opened in the figure) shows the path on disk to
the executable.
Figure 3-6: The Properties window, Image tab
Using the Verify Option
One particularly useful Process Explorer feature is the Verify button on the
Image tab. Click this button to verify that the image on disk is, in fact, the
Microsoft signed binary. Because Microsoft uses digital signatures for most of
its core executables, when Process Explorer verifies that a signature is valid,
you can be sure that the file is actually the executable from Microsoft. This
feature is particularly useful for verifying that the Windows file on disk has
not been corrupted; malware often replaces authentic Windows files with its
own in an attempt to hide.
The Verify button verifies the image on disk rather than in memory,
and it is useless if an attacker uses process replacement, which involves running a
process on the system and overwriting its memory space with a malicious executable. Process replacement provides the malware with the same privileges
Basic Dynamic Analysis 49
as the process it is replacing, so that the malware appears to be executing as a
legitimate process, but it leaves a fingerprint: The image in memory will differ from the image on disk. For example, in Figure 3-6, the svchost.exe process
is verified, yet it is actually malware. We’ll discuss process replacement in
more detail in Chapter 12.
Comparing Strings
One way to recognize process replacement is to use the Strings tab in the
Process Properties window to compare the strings contained in the disk executable (image) against the strings in memory for that same executable running in memory. You can toggle between these string views using the buttons
at the bottom-left corner, as shown in Figure 3-7. If the two string listings are
drastically different, process replacement may have occurred. This string
discrepancy is displayed in Figure 3-7. For example, the string FAVORITES.DAT
appears multiple times in the right half of the figure (svchost.exe in memory),
but it cannot be found in the left half of the figure (svchost.exe on disk).
Figure 3-7: The Process Explorer Strings tab shows strings on disk (left) versus strings in
memory (right) for active svchost.exe.
Using Dependency Walker
Process Explorer allows you to launch depends.exe (Dependency Walker) on
a running process by right-clicking a process name and selecting Launch
Depends. It also lets you search for a handle or DLL by choosing Find
Find Handle or DLL.
The Find DLL option is particularly useful when you find a malicious
DLL on disk and want to know if any running processes use that DLL. The
Verify button verifies the EXE file on disk, but not every DLL loaded during
runtime. To determine whether a DLL is loaded into a process after load
time, you can compare the DLL list in Process Explorer to the imports shown
in Dependency Walker.
50 Chapter 3
Analyzing Malicious Documents
You can also use Process Explorer to analyze malicious documents, such as
PDFs and Word documents. A quick way to determine whether a document
is malicious is to open Process Explorer and then open the suspected malicious document. If the document launches any processes, you should see
them in Process Explorer, and be able to locate the malware on disk via the
Image tab of the Properties window.
NOTE Opening a malicious document while using monitoring tools can be a quick way to
determine whether a document is malicious; however, you will have success running
only vulnerable versions of the document viewer. In practice, it is best to use intentionally unpatched versions of the viewing application to ensure that the exploitation will
be successful. The easiest way to do this is with multiple snapshots of your analysis virtual machine, each with old versions of document viewers such as Adobe Reader and
Microsoft Word.
Comparing Registry Snapshots with Regshot
Listing 3-1 displays a subset of the results generated by Regshot during
malware analysis. Registry snapshots were taken before and after running the
spyware ckr.exe.
Regshot
Comments:
Datetime:
Computer: MALWAREANALYSIS
Username: username
Keys added: 0
Values added:3
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\ckr:C:\WINDOWS\system32
ckr.exe
...
...
Values modified:2
HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed: 00 43 7C 25 9C 68 DE 59 C6 C8
9D C3 1D E6 DC 87 1C 3A C4 E4 D9 0A B1 BA C1 FB 80 EB 83 25 74 C4 C5 E2 2F CE
4E E8 AC C8 49 E8 E8 10 3F 13 F6 A1 72 92 28 8A 01 3A 16 52 86 36 12 3C C7 EB
5F 99 19 1D 80 8C 8E BD 58 3A DB 18 06 3D 14 8F 22 A4
...
Total changes:5
Listing 3-1: Regshot comparison results
As you can see ckr.exe creates a value at HKLM\SOFTWARE\Microsoft\Windows
CurrentVersion\Run as a persistence mechanism . A certain amount of noise
is typical in these results, because the random-number generator seed is constantly updated in the registry.
As with procmon, your analysis of these results requires patient scanning
to find nuggets of interest.
Faking a Network
Malware often beacons out and eventually communicates with a commandand-control server, as we’ll discuss in depth in Chapter 14. You can create a
fake network and quickly obtain network indicators, without actually connecting to the Internet. These indicators can include DNS names, IP addresses,
and packet signatures.
To fake a network successfully, you must prevent the malware from realizing that it is executing in a virtualized environment. (See Chapter 2 for a
discussion on setting up virtual networks with VMware.) By combining the
tools discussed here with a solid virtual machine network setup, you will
greatly increase your chances of success.
Using ApateDNS
ApateDNS, a free tool from Mandiant (www.mandiant.com/products/research/
mandiant_apatedns/download), is the quickest way to see DNS requests made
by malware. ApateDNS spoofs DNS responses to a user-specified IP address by
listening on UDP port 53 on the local machine. It responds to DNS requests
with the DNS response set to an IP address you specify. ApateDNS can display
the hexadecimal and ASCII results of all requests it receives.
52 Chapter 3
To use ApateDNS, set the IP address you want sent in DNS responses
at and select the interface at . Next, press the Start Server button; this
will automatically start the DNS server and change the DNS settings to
localhost. Next, run your malware and watch as DNS requests appear in
the ApateDNS window. For example, in Figure 3-9, we redirect the DNS
requests made by malware known as RShell. We see that the DNS information
is requested for evil.malwar3.com and that request was made at 13:22:08 .
Figure 3-9: ApateDNS responding to a request for evil.malwar3.com
In the example shown in the figure, we redirect DNS requests to
127.0.0.1 (localhost), but you may want to change this address to point to
something external, such as a fake web server running on a Linux virtual
machine. Because the IP address will differ from that of your Windows malware analysis virtual machine, be sure to enter the appropriate IP address
before starting the server. By default ApateDNS will use the current gateway
or current DNS settings to insert into DNS responses.
You can catch additional domains used by a malware sample through
the use of the nonexistent domain (NXDOMAIN) option at . Malware will
often loop through the different domains it has stored if the first or second
domains are not found. Using this NXDOMAIN option can trick malware
into giving you additional domains it has in its configuration.
Monitoring with Netcat
Netcat, the “TCP/IP Swiss Army knife,” can be used over both inbound and
outbound connections for port scanning, tunneling, proxying, port forwarding, and much more. In listen mode, Netcat acts as a server, while in connect
mode it acts as a client. Netcat takes data from standard input for transmission over the network. All the data it receives is output to the screen via standard output.
Let’s look at how you can use Netcat to analyze the malware RShell from
Figure 3-9. Using ApateDNS, we redirect the DNS request for evil.malwar3.com
to our local host. Assuming that the malware is going out over port 80 (a
common choice), we can use Netcat to listen for connections before executing the malware.
Malware frequently uses port 80 or 443 (HTTP or HTTPS traffic, respectively), because these ports are typically not blocked or monitored as outbound
connections. Listing 3-2 shows an example.
!
$
"
Basic Dynamic Analysis 53
C:> nc –l –p 80
POST /cq/frame.htm HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; Windows NT 5.1; TWFsd2FyZUh1bnRlcg==;
rv:1.38)
Accept: text/html, application
Accept-Language: en-US, en:q=
Accept-Encoding: gzip, deflate
Keep-Alive: 300
Content-Type: application/x-form-urlencoded
Content-Length
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
Z:\Malware>
Listing 3-2: Netcat example listening on port 80
The Netcat (nc) command shows the options required to listen on a
port. The –l flag means listen, and –p (with a port number) specifies the port
on which to listen. The malware connects to our Netcat listener because we’re
using ApateDNS for redirection. As you can see, RShell is a reverse shell ,
but it does not immediately provide the shell. The network connection first
appears as an HTTP POST request to www.google.com , fake POST data that
RShell probably inserts to obfuscate its reverse shell, because network analysts
frequently look only at the start of a session.
Packet Sniffing with Wireshark
Wireshark is an open source sniffer, a packet capture tool that intercepts and
logs network traffic. Wireshark provides visualization, packet-stream analysis,
and in-depth analysis of individual packets.
Like many tools discussed in this book, Wireshark can be used for both
good and evil. It can be used to analyze internal networks and network usage,
debug application issues, and study protocols in action. But it can also be
used to sniff passwords, reverse-engineer network protocols, steal sensitive
information, and listen in on the online chatter at your local coffee shop.
The Wireshark display has four parts, as shown in Figure 3-10:
The Filter box is used to filter the packets displayed.
The packet listing shows all packets that satisfy the display filter.
The packet detail window displays the contents of the currently
selected packet (in this case, packet 47).
The hex window displays the hex contents of the current packet. The
hex window is linked with the packet detail window and will highlight
any fields you select.
54 Chapter 3
Figure 3-10: Wireshark DNS and HTTP example
To use Wireshark to view the contents of a TCP session, right-click any
TCP packet and select Follow TCP Stream. As you can see in Figure 3-11,
both ends of the conversation are displayed in session order, with different
colors showing each side of the connection.
Figure 3-11: Wireshark’s Follow TCP Stream window
!
"
$
Basic Dynamic Analysis 55
To capture packets, choose CaptureInterfaces and select the interface
you want to use to collect packets. Options include using promiscuous mode
or setting a capture filter.
WARNING Wireshark is known to have many security vulnerabilities, so be sure to run it in a safe
environment.
Wireshark can help you to understand how malware is performing network communication by sniffing packets as the malware communicates. To
use Wireshark for this purpose, connect to the Internet or simulate an
Internet connection, and then start Wireshark’s packet capture and run
the malware. (You can use Netcat to simulate an Internet connection.)
Chapter 14 discusses protocol analysis and additional uses of Wireshark
in more detail.
Using INetSim
INetSim is a free, Linux-based software suite for simulating common Internet services. The easiest way to run INetSim if your base operating system is
Microsoft Windows is to install it on a Linux virtual machine and set it up on
the same virtual network as your malware analysis virtual machine.
INetSim is the best free tool for providing fake services, allowing you to
analyze the network behavior of unknown malware samples by emulating services such as HTTP, HTTPS, FTP, IRC, DNS, SMTP, and others. Listing 3-3
displays all services that INetSim emulates by default, all of which (including
the default ports used) are shown here as the program is starting up.
- dns 53/udp/tcp - started (PID 9992)
- http 80/tcp - started (PID 9993)
- https 443/tcp - started (PID 9994)
- smtp 25/tcp - started (PID 9995)
- irc 6667/tcp - started (PID 10002)
- smtps 465/tcp - started (PID 9996)
- ntp 123/udp - started (PID 10003)
- pop3 110/tcp - started (PID 9997)
- finger 79/tcp - started (PID 10004)
- syslog 514/udp - started (PID 10006)
- tftp 69/udp - started (PID 10001)
- pop3s 995/tcp - started (PID 9998)
- time 37/tcp - started (PID 10007)
- ftp 21/tcp - started (PID 9999)
- ident 113/tcp - started (PID 10005)
- time 37/udp - started (PID 10008)
- ftps 990/tcp - started (PID 10000)
- daytime 13/tcp - started (PID 10009)
- daytime 13/udp - started (PID 10010)
- echo 7/tcp - started (PID 10011)
- echo 7/udp - started (PID 10012)
- discard 9/udp - started (PID 10014)
56 Chapter 3
- discard 9/tcp - started (PID 10013)
- quotd 17/tcp - started (PID 10015)
- quotd 17/udp - started (PID 10016)
- chargen 19/tcp - started (PID 10017)
- dummy 1/udp - started (PID 10020)
- chargen 19/udp - started (PID 10018)
- dummy 1/tcp - started (PID 10019)
Listing 3-3: INetSim default emulated services
INetSim does its best to look like a real server, and it has many easily configurable features to ensure success. For example, by default, it returns the
banner of Microsoft IIS web server if is it scanned.
Some of INetSim’s best features are built into its HTTP and HTTPS
server simulation. For example, INetSim can serve almost any file requested.
For example, if a piece of malware requests a JPEG from a website to continue its operation, INetSim will respond with a properly formatted JPEG.
Although that image might not be the file your malware is looking for, the
server does not return a 404 or another error, and its response, even if incorrect, can keep the malware running.
INetSim can also record all inbound requests and connections, which
you’ll find particularly useful for determining whether the malware is connected to a standard service or to see the requests it is making. And INetSim
is extremely configurable. For example, you can set the page or item returned
after a request, so if you realize that your subject malware is looking for a particular web page before it will continue execution, you can provide that page.
You can also modify the port on which various services listen, which can be
useful if malware is using nonstandard ports.
And because INetSim is built with malware analysis in mind, it offers
many unique features, such as its Dummy service, a feature that logs all data
received from the client, regardless of the port. The Dummy service is most
useful for capturing all traffic sent from the client to ports not bound to any
other service module. You can use it to record all ports to which the malware
connects and the corresponding data that is sent. At least the TCP handshake will complete, and additional data can be gathered.
Basic Dynamic Tools in Practice
All the tools discussed in this chapter can be used in concert to maximize
the amount of information gleaned during dynamic analysis. In this section,
we’ll look at all the tools discussed in the chapter as we present a sample
setup for malware analysis. Your setup might include the following:
- Running procmon and setting a filter on the malware executable name
and clearing out all events just before running.
- Starting Process Explorer.
- Gathering a first snapshot of the registry using Regshot.
Basic Dynamic Analysis 57
- Setting up your virtual network to your liking using INetSim and
ApateDNS.
- Setting up network traffic logging using Wireshark.
Figure 3-12 shows a diagram of a virtual network that can be set up for
malware analysis. This virtual network contains two hosts: the malware analysis Windows virtual machine and the Linux virtual machine running INetSim.
The Linux virtual machine is listening on many ports, including HTTPS,
FTP, and HTTP, through the use of INetSim. The Windows virtual machine
is listening on port 53 for DNS requests through the use of ApateDNS. The
DNS server for the Windows virtual machine has been configured to localhost (127.0.0.1). ApateDNS is configured to redirect you to the Linux virtual
machine (192.168.117.169).
If you attempt to browse to a website using the Windows virtual machine,
the DNS request will be resolved by ApateDNS redirecting you to the Linux
virtual machine. The browser will then perform a GET request over port 80 to
the INetSim server listening on that port on the Linux virtual machine.
Figure 3-12: Example of a virtual network
Let’s see how this setup would work in practice by examining the malware msts.exe. We complete our initial setup and then run msts.exe on our
malware analysis virtual machine. After some time, we stop event capture
with procmon and run a second snapshot with Regshot. At this point we
begin analysis as follows:
- Examine ApateDNS to see if DNS requests were performed. As shown in
Figure 3-13, we notice that the malware performed a DNS request for
www.malwareanalysisbook.com.
Figure 3-13: ApateDNS request for
www.malwareanalysisbook.com
Virtual Network
Windows Virtual Machine
IP Address = 192.168.117.170
DNS Server = 127.0.0.1
Browser DNS Request
Browser HTTP GET
Linux Virtual Machine
INetSim
IP Address = 192.168.117.169
DNS: 53
ApateDNS Redirect
192.168.117.169
HTTPS: 443
FTP: 21
HTTP: 80
etc.
58 Chapter 3
- Review the procmon results for file system modifications. In the
procmon results shown in Figure 3-14, we see CreateFile and WriteFile
(sequence numbers 141 and 142) operations for C:\WINDOWS\system32
winhlp2.exe. Upon further investigation, we compare winhlp2.exe to
msts.exe and see that they are identical. We conclude that the malware
copies itself to that location.
Figure 3-14: Procmon output with the msts.exe filter set
- Compare the two snapshots taken with Regshot to identify changes.
Reviewing the Regshot results, shown next, we see that the malware
installed the autorun registry value winhlp at HKLM\SOFTWARE\Microsoft
Windows\CurrentVersion\Run location. The data written to that value is
where the malware copied itself (C:\WINDOWS\system32\winhlp2.exe),
and that newly copied binary will execute upon system reboot.
Values added:3
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\winhlp: C:\WINDOWS\system32\winhlp2.exe
4. Use Process Explorer to examine the process to determine whether it creates mutexes or listens for incoming connections. The Process Explorer
output in Figure 3-15 shows that msts.exe creates a mutex (also known as a
mutant) named Evil1 . We discuss mutexes in depth in Chapter 7, but
you should know that msts.exe likely created the mutex to ensure that only
one version of the malware is running at a time. Mutexes can provide an
excellent fingerprint for malware if they are unique enough.
5. Review the INetSim logs for requests and attempted connections on
standard services. The first line in the INetSim logs (shown next) tells us
that the malware communicates over port 443, though not with standard
Secure Sockets Layer (SSL), as shown next in the reported errors at .
[2010-X] [15013] [https 443/tcp 15199] [192.168.117.128:1043] connect
[2010-X] [15013] [https 443/tcp 15199] [192.168.117.128:1043]
Error setting up SSL: SSL accept attempt failed with unknown error
Error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
[2010-X] [15013] [https 443/tcp 15199] [192.168.117.128:1043] disconnect
Basic Dynamic Analysis 59
Figure 3-15: Process Explorer’s examination of an active msts.exe process
6. Review the Wireshark capture for network traffic generated by the malware. By using INetSim while capturing with Wireshark, we can capture
the TCP handshake and the initial data packets sent by the malware. The
contents of the TCP stream sent over port 443, as shown in Figure 3-16,
shows random ACSII data, which is often indicative of a custom protocol.
When this happens, your best bet is to run the malware several more
times to look for any consistency in the initial packets of the connection.
(The resulting information could be used to draft a network-based signature, skills that we explore in Chapter 14.)
Figure 3-16: Wireshark showing the custom network protocol
!
60 Chapter 3
Conclusion
Basic dynamic analysis of malware can assist and confirm your basic static
analysis findings. Most of the tools described in this chapter are free and easy
to use, and they provide considerable detail.
However, basic dynamic analysis techniques have their deficiencies, so
we won’t stop here. For example, to understand the networking component
in the msts.exe fully, you would need to reverse-engineer the protocol to
determine how best to continue your analysis. The next step is to perform
advanced static analysis techniques with disassembly and dissection at the
binary level, which is discussed in the next chapter