In action movies, it's often the case that when the hero walks away from an exploding object, they don't even bother to look back to see the destruction it is causing. Unfortunately for malware analysts, we don't tend to be quite as cool as action heroes, and our job requires that we closely observe the destruction being caused.
To this point, we've mostly worked with the static gathering of metadata on files from an advanced perspective. In this chapter, we'll begin executing our malware and observing the behaviors. This will allow an analyst to validate the data they have recovered from static analysis, as well as uncover Tools, Techniques, and Procedures (TTPs) that may not be apparent during the static analysis of a sample.
After we cover each of these topics, you'll also have the opportunity to try your luck against a real-world piece of malware – NetWalker Ransomware.
We'll cover the following topics:
These are the technical requirements for this chapter:
Executing malware in a virtual machine (VM) is one thing, but observing the behavior is another matter entirely. As we've previously discussed in the first Dynamic Analysis chapter, not all actions taken by malware are readily apparent to the end user who executed the malware.
This is by design—if it were obvious, the end user would alert their security team immediately, and the malware would be far less successful. As a result of the sneakiness implemented by adversaries to avoid detection, we require specialized tools to monitor each change made to the system by the malicious software.
Thankfully, there are several tools that fill this need and that will meet our purposes.
Keep in mind that during this chapter, as we utilize each tool to examine the malware, we'll either need to re-execute the malware when monitoring with a new tool or restore to a snapshot prior to execution in order to capture the pertinent information.
While Regshot is quite an old tool at this point, it still functions very well and will provide a good basis for monitoring the filesystem and registry for changes that take place after malware is executed on the system.
The Regshot pane is shown in the following screenshot:
First, we'll select the ellipses next to the Output path: box, and select our desktop for ease of access after executing our malware.
The process is illustrated in the following screenshot:
The process is illustrated in the following screenshot:
Windows makes a lot of changes to the filesystem and registry on a fairly regular basis. To keep a low signal-to-noise ratio, I recommend waiting until the last possible second before executing your malware to take the base shot. Otherwise, a large portion of the changes Regshot records will be red herrings, and unrelated to the malware.
Once complete, Regshot will present you with a window enumerating the registry keys, directories, and files it was able to enumerate during the first shot, as illustrated in the following screenshot:
With our first shot complete, we can now execute our malware and look for changes! We'll begin by executing a sample of a DoppelDridex maldoc on our system, and letting the macro run. Once we've allowed the macro to run, we can repeat the steps with the second shot.
The process is illustrated in the following screenshot:
Then, we can click the Compare and Output button. Once complete, we'll be greeted by the differences that Regshot detected between the two shots, and a text file will open that has the raw results of the comparison of shots.
Manually opening the .zip files in 7z shows they are actually PEs! From here, we could utilize our static analysis techniques from Chapter 6, Advanced Dynamic Analysis – Looking at Explosions, and ascertain that these are, in fact, dynamic-link libraries (DLLs) written by the DoppelDridex loader.
A shortcoming of Regshot should now be fairly apparent: due to the volume of changes made by software and the Windows operating system, an enormous amount of noise can be generated, making it quite difficult to ascertain malicious activity from normal system processes.
Another useful tool is Process Explorer from Sysinternals—this will allow us to monitor processes in real time and see spawned processes that may result from malware. In the following screenshot, you can see it being put to use with an Excel process:
Utilizing Process Explorer, we can see that two regsvr32.exe processes have spawned under our Excel process, and are referencing the downloaded files we previously observed in Regshot. The DLL register server binary has been run with the -s switch, indicating no dialog boxes will be shown, so the DLLs are silently executed by RegSvr32.
While Process Explorer is simple and intuitive, it may not always provide a complete picture of the malware's path of execution. For this, we'll need to take the data we've already collected, revert our snapshot, and try again with a more advanced tool.
Process Monitor (ProcMon) is another very popular tool among malware analysts from Mark Russinovich's suite of Windows Sysinternals tools. ProcMon will allow us to watch, in real time, every action a process—or set of processes—takes.
We can also filter by actions taken, process names, and myriad other conditions, as well as export to a clean comma-separated value (CSV) file or some other format. For this exercise, we'll need to re-execute the malicious document once we've completed our setup of ProcMon. Let's go ahead and get that set up now. Let's start by opening ProcMon, as follows:
As you can see, a lot of information immediately begins flowing in. Click the magnifying glass to immediately stop the capture, as we will not be interested in events that occur prior to running our malware.
Before execution, it's important that we set up filters for the activity we'd like to capture. Based on our previous dynamic analysis, we can say for certain that we'd like to watch the RegSvr32.exe and Excel.exe processes, as these will be the ones facilitating the malicious activity. Click the Filter button to open the filter dialog box shown in the following screenshot:
We'll create rules for monitoring and including if the process name is excel.exe or regsvr32.exe, and then add and apply them. Before running our malware, let's be sure to clear the log to start with a fresh slate, by clicking the Clear button at the top of ProcMon.
We'll go ahead and open the maldoc and begin monitoring again right before we enable macros for the document, since no malicious activity will take place prior to this and will only contribute to noise.
After waiting a period, we have captured a good amount of data and can begin combing through our events. First, we'll take a look at file creation events. We can utilize the same filter dialog to create a filter that will only show us file creation events, as illustrated in the following screenshot:
We can also utilize this to filter out network traffic related to the malware, as follows:
Here, we can view the sockets created and the TCP connections created by the malware.
We'll cover this a bit more later on in the chapter when we examine other network-based tooling, but ProcMon isn't the ideal tool for mapping network traffic as there are other tools that do it far better. That said, it can do it, and most adversaries will utilize HTTP for C2 traffic, so feel free to use TCPConnect events for your initial triage, though Wireshark will do it better.
Similarly, we can choose to filter on registry operations that may be utilized for persistence by the malware. In this instance, no malicious registry operations have occurred, lending some credibility to the idea that we may have failed an anti-analysis check utilized by the malware to avoid detection or analysis by incident responders.
In the next section, we'll take a look at another tool we can utilize to make our ProcMon output a bit more easily ingestible.
ProcDOT is a tool requiring external dependencies that can greatly ease the digestion of event data from ProcMon. ProcDOT's external dependencies are WinDump and Graphviz, which can be downloaded from the links included in the Technical requirements section of this chapter.
Additionally, some small configuration changes are required for ProcDOT to properly parse the files. These are outlined in detail in the readme.txt file included with ProcDOT—follow the directions in this file for simple column changes within ProcMon.
Once set up, we can export our ProcMon logs by utilizing Save… within the File menu, as illustrated in the following screenshot:
This will generate another window. Here, we'd like to save the file in CSV format, not the ProcMon Log (PML) format native to ProcMon. Choose a good location for your file and begin the export, which may take a while. The process is shown in the following screenshot:
Once we've completed this step, we can point ProcDOT to our dependencies, utilizing the popup that opens upon startup. Point ProcDOT to the correct binaries for each dependency. The process is illustrated in the following screenshot:
Here, we want to select the first relevant process—in this case, Excel, as it was the source of the malicious macro:
Here, we can see a graphical representation of the network C2 traffic captured by ProcMON to the DoppelDridex C2s, and scrolling further to the right, we can see the RegSvr32.exe processes spawned by Excel:
Unfortunately, in this instance, DoppelSpider appears to be onto our game, and the processes self-terminate, leaving us with only this activity.
While the tooling that we have discussed will be a great help to us in our analysis of adversarial software—an important point to remember is that adversaries frequently do not want to be monitored and will go to great lengths to prevent this.
For instance, let's take a look here at some anti-analysis strings that are present in the Qakbot banking Trojan threat:
We can infer from this set of tool names that are present within an encrypted array in the Qakbot threat that it is likely utilizing the CreateToolhelp32Snapshot Windows application programming interface (API) to iterate through running processes and refuse to continue along the execution path if one of the images is found to be running.
However, what if instead of running procmon.exe or procmon64.exe we were running AngryPinchyCrab.exe? AngryPinchyCrab.exe doesn't appear in the list and, as such, may not raise an alarm to halt execution. There are other factors at play, but often, simply renaming our tools is enough to proceed along to the next step.
At this point, we've covered a large portion of dynamic analysis tricks—those that interact directly with the system. But malware has been network-aware for nearly all of its existence, and networking comprises a huge part of how malware behaves. Let's take a dive into how we can examine what malware may be doing at the network level.
Often, we as analysts may want to execute malware without directly exposing our box to the internet, for a myriad of reasons covered in the first chapter. For this, tools such as the following are crucial:
We'll cover each of these and their use cases in deceiving our adversarial counterparts so that we may better understand the ends they are attempting to achieve.
FakeNet is a fairly simple application. The application hooks into the network adapter, and "tricks" the malware into believing it is the primary network adapter. As it does so, it also records all traffic, including outbound HTTP and HTTP Secure (HTTPS) requests. The FakeNet-NG logo is shown here:
FakeNet can be started by searching in the Start menu and utilizing Ctrl + Shift + Enter to run the program as administrator. You can see the tool in operation here:
As you can see, after running our malicious DoppelDridex sample, FakeNet captures traffic to the malware distribution servers for a download request for /bfe2mddol.zip—a ZIP file containing the malicious files that would later be executed with RegSvr32.
ApateDNS is a free tool from FireEye that intercepts Domain Name System (DNS) requests and—optionally—forwards them to a designated Internet Protocol (IP) of your choosing. It can be downloaded from the Uniform Resource Locator (URL) listed in the Technical requirements section of this chapter, and no setup is required as it is a portable application.
Upon opening the application, you'll be presented with the following screen:
As you can see, the DoppelDridex launcher attempts to look up several randomly generated domains as an anti-analysis measure. Because ApateDNS responds to these and returns a known IP address, the malware sample halts execution to prevent further analysis of the malware.
We can also utilize ApateDNS in another way—combining it with Python's SimpleHTTPServer to really get the most out of our ability to lie to the malware on a network level.
The real power behind ApateDNS lies in being able to lie to malware samples and droppers. We can monitor for DNS lookups and respond with the IP of a web server we control—by extension, forwarding HTTP requests meant for the C2 to ourselves. Let's take a look at an example, using a sample of the ZLoader maldoc from Q4 2020.
First, running the sample and monitoring ApateDNS, we can see a request made to jmnwebmaker.com—a likely exploited host utilized for C2 or distribution, as illustrated in the following screenshot:
Armed with this information, we can start a simple HTTP server—either on our current analysis machine or on an outside machine, as long as it is reachable by the analysis box itself—utilizing the python -m http.server 80 command line.
Once this is complete, we can then add our IP into the DNS Reply IP box in ApateDNS to lie to the malicious sample, and have it reach out to our server for further instruction or samples. The process is illustrated in the following screenshot:
We can compare the requests with the DNS queries ApateDNS has responded to in order to build a full URL, as illustrated in the following screenshot:
For instance, here are a few examples:
Why hxxp? In malware analysis, it's a good best practice to "defang" URLs by utilizing hxxp instead of http and placing brackets around dots in URLs to prevent them from being accidentally clicked by your audience and causing them to download malware!
We can then utilize this information to pull down secondary stages for analysis without actually installing those secondary stages or allowing the malware to perform actions on the secondary stage such as decryption, quick running, and overwriting with a benign executable, and so on.
In the past few instances, our malicious processes have been fairly obvious, but what happens when malware hides inside of another "legitimate" system process? Let's take a look at some examples.
Malicious processes are often obvious and stand out to experienced malware analysts or to anyone who has a familiarity with which process(es) should be running on a standard Windows installation.
As with anything in analysis and prevention, this is a bit of an arms race with the adversaries responsible for writing malicious code. A common set of techniques utilized by malware authors falls under the category of process injection.
Adversaries can employ a number of techniques in order to accomplish process injection, including spawning new processes in a suspended state, allocating memory within them, and then writing malicious code into this created memory space (process hollowing), or injecting a thread into an existing process.
Some of these techniques can be inferred by the presence of certain API calls within the binary, as outlined in Chapter 6, Advanced Dynamic Analysis – Looking at Explosions. The API calls are listed here:
Any combination of these APIs, in combination with APIs such as CreateToolHelp32Snapshot, should be viewed as highly suspect by an analyst, as it's likely the sample is enumerating running processes in order to iterate through and find the process they would like to utilize as a target for process injection.
We'll quickly cover the basics of each type of process injection. Although it's not going to be within scope to discuss the minute technical differences involved in calling the APIs and injecting into processes in myriad different ways, it's good to have a fundamental understanding of the types of process injection and how they work at a basic level.
In classic DLL injection, the malicious process will often utilize CreateToolHelp32Snapshot in order to iterate through processes until it locates the process it would like to target. Once located, the malicious process will utilize VirtualAlloc and WriteProcessMemory to write the path for a malicious DLL into the virtual address space of the target process.
Once the DLL's path is written into the virtual memory space of the target process, the malicious process will utilize CreateRemoteThread in order to force the process to load the malicious library. This injection technique is commonly utilized by Dridex/DoppelDridex to inject into Explorer.exe.
This technique is highly similar to classic DLL injection. Instead of injecting the path to the DLL into the virtual memory of the process, the malware will create address space utilizing VirtualAlloc, then write a PE directly into the memory address space using WriteProcessMemory, and ensure code execution by utilizing CreateRemoteThread or similar undocumented APIs such as NTCreateThreadEx.
In this technique, the malware will suspend an existing thread of a process. First, the malware will suspend the thread, utilize VirtualAlloc to clear memory space for the path of the DLL, and inject the path to the DLL and a call to LoadLibrary in order to load the malicious DLL into the existing thread in the process. The malware will then instruct the thread to resume.
Depending on the technique utilized, this will force legitimate processes that load certain libraries to additionally load the malicious DLL specified within the registry keys. The libraries for AppInit and AppCert DLLs are listed here:
For Image File Execution Options (IFEO), the injection mechanism is not dependent on the process loading a library. The adversary can set a malicious DLL as a Debugger value in the corresponding registry key for the target process, and the library or process will be loaded upon execution of the target process.
Process hollowing is a fairly simple technique. The malicious process will spawn a legitimate process in a suspended state and will then unmap the legitimate code from the process utilizing VirtualAlloc. The code within the process will then be replaced with malicious code utilizing WriteProcessMemory, and the process will be resumed.
Now that we've examined the most common methodologies utilized by malware to inject into legitimate system binaries, let's take a look at how we can detect process injection.
Detecting process injection can be a bit tricky since default logging within Windows does not necessarily supply this capability.
There are certain simple things we can utilize, such as the spawning of new processes as child processes of malicious ones, which would be apparent in ProcDOT. We can also utilize the AppInit DLLs section of AutoRuns in order to ascertain whether our malware has created values that will cause process injection upon startup.
However, these methods will not detect all kinds of process injection, so we require another way to be able to monitor our system for malicious processes utilizing CreateRemoteThread to inject into existing processes.
Thankfully, System Monitor (Sysmon) has this capability, and it tracks the utilization of CreateRemoteThread with Event Type 8. To install Sysmon, open Command Prompt on your FLARE VM as administrator, and simply run sysmon -i:, as illustrated in the following screenshot:
Once installed, we can emulate a thread injection utilizing the AtomicRedTeam tool, in order to test several DLL injection methods at once for detection in Sysmon, as illustrated in the following screenshot:
Once done, several windows will appear due to new processes being spawned for injection. Navigating to our Sysmon logs, we can see that process injection has been recorded with Event ID 8, and the source and destination executables are available, as illustrated in the following screenshot:
Utilizing Sysmon and tracking this event are a great way to detect process injection and track possible malicious activity in your Security Information and Event Management (SIEM). It's also likely your endpoint detection and response (EDR) platform has good detections for process injection, so be sure to not discount it.
With all of these new skills and abilities to detect under our belt, let's take a look at a real-world example in the case of TrickBot, and see how we may apply these techniques to real malware.
Let's take a look now at some real-world examples of malware that we can analyze and observe performing malicious activity, performing network requests and process injection, and being naughty in general.
TrickBot is a banking Trojan from a threat actor tracked as WIZARD SPIDER. TrickBot has many core functionalities, one of which is to utilize process hollowing to masquerade within the environment.
Unfortunately, because this does not utilize the CreateRemoteThread API, it will not trigger Sysmon event 8. However, understanding that WerMgr is the Windows process responsible for uploading and handling error reports and should almost never be running consistently gives a good hint as to the malicious purpose of the process in this scenario.
However, monitoring the sample in ProcMon, and then loading the resultant CSV file into ProcDOT tells us a much different story, as we can see here:
Here, it is very apparent that the malicious DLL being executed both spawned WerMgr.exe and has a thread on it—not to mention the fact that WerMgr.exe is currently making network calls to known TrickBot C&C servers.
Knowing a process is malicious and being able to prove a process is malicious are two very different things.
Now, let's test the knowledge we've gained in this chapter against real-world examples of malware—NetWalker!
For this challenge, you'll be tasked with dynamically analyzing the ransomware threat NetWalker. Utilizing the sample pack located in the Technical requirements section of this chapter, attempt to answer the following questions:
In this chapter, we discussed many different methods of coaxing information out of a malicious sample that is currently running within our environment. We've covered garnering information about files and registry keys changed or written with Regshot, monitoring processes with ProcMon, and increasing their legibility with ProcDOT. We've also examined how we can lie to the adversarial software about our network, and twist this to our advantage in the fight against malware.
In the next chapter, we'll take dynamic analysis even a step further, and examine how to defeat anti-analysis tricks that we may encounter and what debugging these samples looks like.