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.

Figure 1.1 — File Lab03–01.exe is packed, and has minimal imports

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

Table 1.1 — Processed output of strings function on Lab03–01.exe

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.

Figure 2.1 — Procmon of Lab03–01.exe

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)

Figure 2.2 — Procmon of Lab03–01.exe, filtered for WriteFile and RegSetValue

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.

Figure 2.3 — Lab03–01.exe hiding under vmx32to64.exe and set to VideoDriver registry.

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.

Figure 2.4 — Lab03–01.exe sharing the same SHA1 Hash as vmx32to64.exe.

Further host-based indicators can be identified through analysis of Process Explorer, to show which handles and DLLs the malware has opened or loaded.

Figure 2.4 — Process Explorer showing Mutex WinVMX32

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

Figure 3.1 — ApateDNS showing DNS beaconing

The ApateDNS capture suggests the malware is beaconing — possibly to either to fetch updates/instructions or to send back stolen information.

Figure 3.2 — iNetSim logs

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.

Figure 3.3 — Illegible characters transmitted by Lab03–01.exe.

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)

Figure 1.1 — Lab03–02.dll’s Imports and Exports showing likely service capabilities

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

Figure 1.2 — Lab03–02.dll’s strings showing potential functionality.

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)

Figure 2.1 — Registry keys and values added as a result of installing Lab03–02.dll

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

Figure 3.1 — Starting the IPRIP service

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.

Figure 3.2 — Process Explorer showing svchost.exe launched with Lab03–02.dll

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.

Figure 5.1 — iNetSim logs of Lab03–02.dll’s DNS and HTTP request

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 .

Figure 5.2 — Wireshark traffic for Lab03–02.dll DNS (left) and HTTP (right)

Figure 5.3 — Netcat receiving HTTP GET header

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 like ws2_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 same kernel32.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).

Figure 1.1 — Orphaned svchost.exe

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.

Figure 2.1 — Comparing strings in memory from process explorer and from running strings on Lab03–03.exe

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

Figure 3.1 — Process Monitor file manipulation from malicious svchost.exe

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.

Figure 4.1 — Evidence of Lab03–03.exe keylogging

___________________________________________________________________

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.

___________________________________________________________________