Hunting for rogue RunDLL32

After reviewing the Mitre ATT&CK matrix matrix, we decided to research the feasibility of adding stronger detection of rogue rundll32.exe processes. We started with a quick search for all processes where the process binary was named rundll32.exe.

In a few hundred milliseconds, this search returned 24,047 processes - too many to review by hand even for a very dedicated analyst! However, we can tell from paging through a few hundred search results that many processes have the same command line. This set of 24,047 processes may have only a few hundred unique command lines. So the next step is to review a single process for each unique command line and decide if that particular command line is safe enough to ignore. One criteria to use for this kind of trust decision is whether all loaded images are either Microsoft-signed DLLs or binaries signed by a trusted publisher. The first few processes loaded only Microsoft-signed binaries so we began filtering out unique command lines using the search GUI:

This eliminated significant numbers of processes very quickly. The first excluded command line dropped the search matches from 24,047 down to 23,020. The next filtered command line dropped total matches to 20,863. And then down to 19,923, then 17,121, and so on. After reviewing and filtering out just 18 unique command lines, the total match count was below 10,000 making it suitable for further review in Excel. Every data table on the Veramine portal includes a small button to export the displayed results making it very easy to switch between analysis tools:

With the Veramine portal open in the browser and the exported rows opened in Excel, it was very easy to quickly eliminate probably-safe command lines. After just a few more minutes of selecting and deleting Excel rows, we were left with 31 rows that looked suspicious, most of which were DLLs loaded from user-writable folders. 31 is a small enough number to go through every process in more detail:

As you can see from the screenshot, the first process command line was a rundll32.exe involving mdi064.dll passing argument fjasdfn:

Our analysis starts by looking at the process tree to see how it was launched:

This particular rundll32.exe was launched by explorer.exe. The blue [A] next to the process in this case means that the process is currently running at this moment. Just in case it ends up being interesting, we can very easily ask the sensor to upload a process memory dump to review with volatility or another memory analysis tool later. (because, "why not?")

Next we switch from the process tree to the list of loaded modules and we see 44 image loads that loaded Microsoft Signed files and three image loads of Unsigned binaries (two unique binaries):

Both those unsigned files stand out first because of their location on the file system, the AppData Temp folder and the ProgramData (not Program Files) folder. If we click on the link to review the mdi064.dll file detail, we see that 43 AV engines flag it as suspicious and that it was loaded on only a single host:

Goldeneco.dll looks similarly suspicious with 46 AV engines flagging it as suspicious. Goldeneco.dll was similarly loaded on only this single host but in this case it was loaded by many many different processes. This one has probably established some sort of persistence whereby Windows is instructed to load it into many different processes. The next step to investigate this situation would be to quarantine this particular host and download both goldeneco.dll and mdi064.dll to build a yara expression suitable for finding similar files across all hosts.

The next set of potentially interesting rundll32.exe processes in our list after mdi064.dll are the following eight that seem to be similar to each other:

In the portal Process Tree view, we can see the relation between the rundll32.exe processes from our search results and other suspicious looking processes:

In this case, msiexec.exe launches a process whose name looks randomly-generated. That process launches a copy of itself and that child process launches a SysWOW64\rundll32.exe and that SysWOW64 rundll32 process launches a child system32\rundll32.exe process. At first glance, those filenames sure do look suspicious. The parent process binary is flagged by a small number of AV engines as malicious but we have found that to not be a super accurate measure of maliciousness. It is, however, always a little suspicious to see 32-bit processes on x64 version of Windows. The most curious thing about this entire process tree, though, is that the parent process (xplvaght.exe in this case) appears to be signed by "Google, Inc" as indicated by its light yellow highlighting in the portal view.

If we go to VirusTotal for a second opinion, we see low prevalence metrics for a binary that claims to be published by Google. This file had been uploaded to VirusTotal only once and only in the last couple weeks despite claiming to be a version of GoogleUpdate.exe from last year:

Notice also that the samples uploaded to VirusTotal seem to have similarly random (but different) filenames. On our customer network, the two rundll32.exe process trees have parent process names programfiles\Drerrertchitopy\xplvaght.exe and programfiles\Serhekreat\xatulole.exe. VirusTotal reports having seen in the wild filenames aripgharisose\xatulole.exe and Lsitanafach/xatulole.exe. These filenames are naggingly suspicious. Despite the "Google, Inc" legitimate Authenticode certificate, we look closer at the process image loads - particularly this unsigned file that was loaded:

A quick look at that goopdate.dll unlocks the mystery:

The attack probably proceeded as follows:

• Attacker with privileged access creates a randomly-generated Program Files subdirectory.
• Attacker places a randomly-renamed copy of GoogleUpdate.exe into this new directory.
• Attacker places a malicious binary named goopdate.dll into the same directory that executes their intended functionality.
• Attacker triggers the execution of the randomly-named Google Update.
• As part of its normal operation, Google Update loads and executes code within the goopdate.dll loaded from its directory.

This is a nice example of attacker tradecraft where a privilege process can persist and bypass detection tools that evaluate a process's trustworthiness based on its process binary digital signature. We can use the Veramine portal to pivot on this technique and find other instances of similar tradecraft. For the purpose of this blog post, we instead move on to the next entry in our rundll32.exe search results.

We are now halfway through the original list of 31 suspicious rundll32.exe commandlines. Next up are these two:

The process tree for that first rundll32.exe seems suspicious from top-to-bottom:

• UvConverter.exe (PID 1440) is running as a service, as LocalSystem, from AppData, and is detected by 40 AV engines.
• upd.exe (PID 7336) was only seen once across all hosts, is not signed, and is detected by 34 AV engines.
• D_Box.exe (PID 1164) is running from Temp folder, was seen only on this one host, and is detected by 21 AV engines.
• The MIO.dll loaded by rundll32 (PID 3628) has been loaded twice - once from AppData\Local\Temp\hpFEA8.tmp and a second time from C:\Windows\Temp\winsap_update. It is detected as malicious by six AV engines. However, more importantly:

1. It launches powershell.exe to download files from anonymous cloudfront URLs
2. It creates and starts new scheduled task(s)
3. It passes in an url whose domain name was registered on GoDaddy last month
4. That URL includes an ominous-sounding "bindurl" parameter (although that may only sound ominous to hackers who bind shells to ports)

Each of these individual processes and persistence mechanisms can certainly be dealt with and remediated individually. The Veramine portal includes quarantine and block functionality to make this easy, and to alert on instances where attackers run the exact same tool after it has been blocked. However, the higher goal of this hunt exercise is to discover attacker tactics so we can detect them when they come back with tools having different hashes. We want to use each single discovery to find more instances of similar attacker activity and fingerprint their operation to spot it again in the future. In this particular case, the use of cloudfront is interesting and the unobfuscated Powershell client.Download usage is interesting. When we perform a new quick command line search for "client.DownloadFile", we find 23 additional likely-malicious Powershell processes not previously triaged and zero legitimate usage of this function by our authorized users:

That first CloudFront DownloadFile was on a host not previously thought to have been infected so this ended up being a nice way to pivot on an attacker artifact to find an additional foothold. The Powershell DownloadFile tactic subsequently uncovered a process tree involving a new potentially malicious binary (28 AV hits) that was signed by a legitimate company and running as LocalSystem:

In a true Hunt operation, we would continue to follow that rabbit trail with each of those 22 other malicious Powershell processes. For the purpose of this blog post, we return to our rundll32.exe search results to get through the full list:

We followed the same pattern as before to find that WinSAP.dll is likely malicious (9/62 VT). More importantly, that discovery led us to find several other new binaries associated with this attacker set that we didn't know about before:

Both the SSS.dll and the Berserker.dll ended up being malicious. And we were able to pivot on the CPK.exe association to reveal yet another malicious process tree:

The remaining rundll32.exe processes from our original search ended up being mostly adware. The same pattern used earlier was effective in discovering other similar pieces of software on the network that were not explicitly launched by rundll32.exe. This hunt exercise was fruitful and provided the input we needed to build a new heuristic for our rundll32.exe detection algorithm documented at https://github.com/veramine/Detections/wiki/Rundll32. These notes will also be used by our machine learning expert to consider in our ML feature engineering the best way to highlight this type of attack activity using the Veramine ML Detection Pipeline.

The Veramine platform's ability to retain, correlate, and search over a vast quantity of host-based security-relevant data allows hunt operations to be limited only by the analyst's imagination. The hunt process can go from idea to every instance of a matching process in just a few seconds. Every match is correlated, enhanced, and presented for deeper analysis with all context preserved and presented exactly as needed. We encourage you to try out the Veramine platform in your environment for free connected to the Veramine cloud instance. The platform currently supports all Microsoft-supported Windows client and server SKUs (Windows 7->Windows Server 2016). If you'd rather self-host the Veramine server-side infrastructure, we can set up a test and evaluation instance in your data center in ten minutes given scp and ssh access to a single linux server you provide. Please reach out to us for a trial or with any questions at [email protected].

• The Veramine Team

Note: Thanks to Kyle Hanslovan and Jerry Bryant for reviewing drafts of this post.