Practical Malware Analysis
Lab 3 — Basic Dynamic Analysis
Solutions for Lab 3 within Practical Malware Analysis.
Dynamic Analysis
Basic dynamic analysis examines a file by executing it and observing the behaviour while it runs on a host system. It allows us to analyse the malware’s effect on the host.
Note, it is important to perform dynamic analysis in a sandbox environment to prevent the malware from actually infecting production systems.
Practical Malware Analysis
Download Labs
Labs skip from 1 to 3, there is no Lab 2-x as in the book, this chapter covers setting up an analysis environment, covered here (coming soon)
Lab 3–1
1. What are this malware’s imports and strings?
2. What are the malware’s host-based indicators?
3. Are there any useful network-based signatures for this malware? If so,
what are they?
1 This dynamic analysis starts with initial static analysis to hopefully gain a baseline understanding of what might be going on. Straight in with PEiD and PE Explorer we see that Lab03–01.exe is evidently PEncrypt 3.1 packed, and only visible import of kernel32.dll
and function ExitProcess
(figure 1.1). Also, there are are no apparent strings visible.
It’s difficult to understand this malware’s functionality with this minimal information. Potentially the file will unpack and expose more information when it is run. One thing we can do is execute strings
to scan the file for UNICODE or ASCII characters not easily located. Doing this we can identify some useful information.
There is a bit of noise here which have been removed, and the main ones are highlighted in red (table 1.1).
Looking at these, we can make some rough assumptions that Lab03–01.exe is likely to do some network activity and download and hide some sort of file in some of the registry directories, under one of those string names.
2 To identify host-based indicators, we can make assumptions from the previous strings
output, such as potentially attaching itself to SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VideoDriver
— however, it is more useful to perform dynamic analysis and see what it’s doing. Take a snapshot of the VM so you’re able to revert to a pre-execution state!
Set VM networking to Host-only, and manually assign the preferred DNS server as iNetsim, or configure the DNS reply IP within ApateDNS to loopback, and set up listeners using Netcat (ports 80 and 443 are recommended as a starting point as these are common).
Clear all processes within Procmon, and apply suitable filters to clear out any noise and find out what the malware is doing. Initially filter to include Process Lab3–1.exe so we can see its activity. Likewise, start Process Explorer for collecting information about processes running on the system.
The first thing we notice when executing Lab03–01.exe is the series of Registry Key operations (Figure 2.1). This doesn’t tell us too much about what the malware is doing specifically however, it’s always useful to see an overview of the activities. We can filter this further to only show WriteFile
and RegSetValue
to see the key operations (figure 2.2)
We can investigate these operations further, and we see that they are related. First, a file is written to C:\WINDOWS\system32\vmx32to64.exe
(note, this filename is a string we’ve identified as part of the initial static analysis) however, this appears to be set to the registry of HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VideoDriver
(another identified string!). This is a strong host-based indicator that the malware is up to something (Figure 2.3). Most likely the malware is intended to be run at startup.
Upon further investigation, it appears as though files vmx32to64.exe and Lab03–01.exe share the same hash (figure 2.4), indicating the malware has established persistence through creating and hiding a copy of itself, as well as to execute at startup via the VideoDriver
registry.
Further host-based indicators can be identified through analysis of Process Explorer, to show which handles and DLLs the malware has opened or loaded.
Process Explorer shows us that Lab03–01.exe has created at mutex of WinVMX32
(again, another identified string) (Figure 2.4). A mutex (mutual exclusion objects) is used to ensure that only once instance of the malware can run at a time — often assigned a fixed name. We also see Lab03–01.exe utilises ws2_32.dll
and wshtcpip.dll
for network capabilities.
3We’re able to analyse network activity either locally on the victim, or utilising iNetSim. I have demonstrated both, having configured DNS to either the iNetSim machine or loopback (for the netcat listeners). Turning our attention to ApateDNS and our iNetSim logs, we see some pretty significant network-based indicators of this malware activity. ApateDNS show regular DNS requests to www.practicalmalwareanalysis.com
every 30 seconds (figure 3.1).
The ApateDNS capture suggests the malware is beaconing — possibly to either to fetch updates/instructions or to send back stolen information.
Also, the associated iNetSim logs show a recognised DNS request for the malicious website, providing further indication of beaconing intent.
Finally, the Netcat listener (with DNS configured for loopback) has picked up a transmission on port 443. This shows a series of illegible characters emitted from the malware (Figure 3.3). On subsequent executions or periodic ticks, the transmission is unique.
The combination of host and network-based indicators provide significant grounding to make assumptions regarding the malware’s activity.
- From Static Analysis, not a lot was uncovered other than the output of what might use as hard-coded parameters.
- Dynamic Analysis to uncover further host-based indicators show that the malware has replicated and masked under another file name has associated with the registry for execution on startup and has network functionality.
- Network-based activity is identified through capturing periodic DNS requests, as well as intercepting random character transmissions of HTTP & SSL
___________________________________________________________________
Lab 3–2
1. How can you get this malware to install itself?
2. How would you get this malware to run after installation?
3. How can you find the process under which this malware is running?
4. Which filters could you set in order to use procmon to glean information?
5. What are the malware’s host or network-based indicators?
Before beginning, it’s important to reset and reconfigure the environment before malware execution so that network traffic can be captured and registry/process changes can be properly identified. Revert to an earlier snapshot here.
1 At first glance, we have Lab03–02.dll. As this is not a .exe file, we are unable to directly execute it. rundll32.exe
is a windows utility which loads and runs 32-bit dynamic-link libraries (.dll).
First, however, we likely require any exported functions to pass in as an argument. This can be identified through PE analysis, which shows us a set of exported and imported functions. The imported functions (Figure 1.1) give us an idea of the .dll’s capabilities. Speculation into these might suggest there will likely be some networking going on, as well as some file, directory and registry manipulation. Functions included as part of ADVAPI32.dll
suggests the malware may need to be run as a service, which is backed up by Lab03–02.dll’s exports (Figure 1.1)
Running streams
also gives us a lot of useful insight into potential actions. Most of which are found as imported functions, however, there are others worth noting that my be useful host/network-based indicators. These include some very distinctive strings, potential registry locations and file or network names, as well as some base64 encoded strings hinting at some functionality (Figure 1.2).
Now we have a starting point to look out for, we can prepare our environment for trying to run the malware — clearing procmon, taking a registry snapshot, and setting up the network.
2 To install the malware, pass one of Install
or installA
(found from the exports) into rundll32
.
Executing C:\rundll32.exe Lab03-02.dll,install
doesn’t give any immediate feedback on the command line, within process explorer, or Wireshark/iNetSim, however taking a 2nd registry snapshot and comparing the two, it’s clear that keys and values have been added — many of these matching up with what we found from strings
(Figure 2.1)
We can see within the regshot comparison that something called IPRIP
has been added as a service, with some of the more identifiable strings as \DisplayName
or \Description
. The image path has also been set to %SystemRoot%\System32\svchost.exe -k netsvcs
which shows the malware is likely to be launched within svchost.exe with network services as an argument.
3 Since we have installed lab03–02.dll as a service, we can now run this and we see the same \DisplayName
+ update found from the added reg values (Figure 3.1).
Checking out ProcessExplorer to see what’s happened, we can search for the Lab03–02.dll which will point us to the svchost.exe instance that was created.
We can identify various indicators which attribute Lab03–02.dll to this instance of svchost.exe thorough the inclusion of the .dll, the service display name “Intranet Network Awareness (INA+)”, and the command line argument matching what has been found in strings. This helps us to confirm that Lab03–02.dll has been loaded — note the process ID, 1148. We’ll need this to see what’s going on in ProcMon!
4 Checking out ProcMon, filtered on PID 1148, we see a whole load of registry RegOpenKey
and ReadFiles
, however, seems mostly svchost.exe related and nothing jumps out as malicious.
5 Turing our attention to look for network-based indicators, we have traffic captured within Wireshark, as well as logged within iNetSim. To give us an idea of what to look for, we can check out the iNetSim logs first (Figure5.1), which show us that we have seen 2 notable types of activity; DNS and HTTP connections. The DNS appears to be periodic requests to practicalmalwareanalysis.com
(which we previously saw similar with Lab03–01.exe), as well as a HTTP GET
request to http://practicalmalwareanalysis.com/serve.html
which attempts to download a file. Fortunately, as we had iNetSim set up to respond, it provides a dummy file to complete the request — /var/lib/inetsim/http/fakefiles/sample.html
. If we didn’t have this, we might have downloaded something real nasty.
We’re able to look at these within Wireshark and inspect the packets in more detail. Filtering on DNS, we’re able to see the DNS request to practicalmalwareanalysis.com
(Figure 5.2, Left). Finding the conversation between the host and iNetSim and following the TCP stream, we’re able to see the content within the HTTP GET
request to http://practicalmalwareanalysis.com/serve.html
(Figure 5.2, Right). This also shows iNetSim’s dummy content replacing serve.hmtl
.
Reverting to snapshot and reinstalling & launching the malicious .dll/service, we can also capture traffic by using ApateDNS to redirect to loopback were we have a Netcat listener on port 80 (Figure 5.3). Here, we see the same HTTP GET
header as we did within Wireshark.
Referring back to the strings
output, “practicalmalwareanalysis.com”, “serve.html”, and “Windows XP 6.11” are also evident within the network analysis and can be used as signatures for the malware.
To recap on the main host/network-based indicators we see:
IPRIP
installed as a service, including strings such as “Intranet Network Awareness (INA+)”- Network activity to “practicalmalwareanalysis.com/serve.html” as well as the User-Agent %ComputerName% Windows XP 6.11.
___________________________________________________________________
Lab 3–3
1. What do you notice when monitoring this malware with Process Explorer?
2. Can you identify any live memory modifications?
3. What are the malware’s host-based indicators?
4. What is the purpose of this program?
Before answering the lab’s dynamic analysis focused questions, it’s always good to quickly do some static analysis to see if there’s anything worth being aware of.
- The only import/export is an import of
kernel32.dll
. This primarily has functions for process, resource, file and string manipulation. There is also no import of something likews2_32.dll
(which is used to hand network connections) so potentially there is no network activity. - Running
strings
doesn’t give away many other clues. There are a few strings which resemble error-handling, as well as the samekernel32.dll
functions seen in the imports. There is reference to \svchost.exe which should be something to keep an eye on, as well as a load of A characters which may just be padding.
A first guess at functionality might be some sort of keylogger, due to the string/file/window stuff going on.
1 After prepping for dynamic analysis, launch Lab03–03.exe and you may notice it appear briefly within Process Explorer with a child process of svchost.exe
. After a moment however, it disappears leaving svchost.exe
orphaned (Figure 1.1).
An orphaned process is one with no parent listed in the process tree. svchost.exe
typically has a parent process of services.exe
, but this one being orphaned is unusual and suspicious.
Investigating this instance of svchost.exe
, we see it has a Parent: Lab03-03.exe(904)
, confirming it’s come from executing Lab03–03.exe. Exploring the properties further, we don’t see much anomalous until we get to the strings.
2 Utilizing strings within Process Explorer is actually a useful trick to analyse malware which is packed or encrypted, because the malware is running and unpacks/decodes itself when it starts. We’re also able to view strings in both the image on disk and in memory.
Taking advantage of this, we can inspect the strings in Image and in Memory, as well as compare against what we found from strings
during quick static analysis.
The strings on image appear pretty consistent with other instances of svchost.exe
however, within Memory, these much greater resemble what we discovered earlier, but with a few distinct differences — practicalmalware.log
and a set of keyboard commands (Figure 2.1). This is an indicator that the keylogger guess might be accurate.
3 To test the keylogger hypothesis, we can open something and type stuff. To target explicitly on the malware, filter on the suspect svchost.exe
(PID, 3936) within Process Monitor, and we see a whole load of file manipulation for practicalmalwareanalysis.log
(Figure 3.1).
4 Opening practicalmalwareanalysis.log
, we find that the file captures inputted strings and distinctive keyboard commands as seen within the memory strings from Process Explorer (Figure 4.1). This confirms that Lab03–03.exe a keylogger using process replacement on svchost.exe
.
___________________________________________________________________
Lab 3–4
Lab 3–4 deletes itself when executing and will likely need some command line argument, which will be explored deeper in chapter 9.
___________________________________________________________________