Hunting for rogue RunDLL32

After reviewing Veramine's detection gaps in the Mitre ATT&CK matrix matrix, we decided to research the feasibility of adding stronger detection of rogue rundll32.exe processes. The first step was to login to the Veramine portal for a customer with a few hundred hosts installed and search for all processes where the process binary was named rundll32.exe.

24,047 processes is too many to review by hand even for a very dedicated analyst. However, its clear from paging through a few hundred search results that many processes have the same command line. So the next step is to review one 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 DLL 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 results from 24047 down to 23020. The next filtered command line dropped total matches to 20863. And then down to 19923, then 17121, and so on. After reviewing and filtering out just 18 unique command lines, the total match count was below 10,000. After reviewing 45 unique processes, the number of matches was down to a manageable 1831:

At this point, most of the excluded commandlines eliminated only a few processes at a time. The Veramine search interface also started to become a little bit unwieldy with so many excluded criteria. After getting down under 1000 matches, we decided to review the remaining matches 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:

Here's what the exported rows looked like in Excel:

With the Veramine portal open in the browser and the exported rows opened in Excel, the process to eliminate safe command lines in the Excel workbook sped up considerably. This would have been the quicker way to do it from the start. 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. This is a small enough number to go through every process in more detail:

We can start by looking at the rundll32.exe that involves mdi064.dll passing argument fjasdfn:

First we look at the process tree to see how it was launched:

This particular rundll32.exe was launched by a user with parent process explorer.exe. The blue [A] next to the process in this case means that the process is currently active at the moment. Just in case it ends up being interesting, we can very easily ask the sensor to upload a process memory dump to review 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 files stand out first by their location on the file system, the temp folder and the AppData folder. If we click on the link to the mdi064.dll file, 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. This file was also only loaded on this single host but in this case it was loaded by many many different processes. This one probably 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's from our search 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 process launches a SysWOW64\rundll32.exe and that process launches a system32\rundll32.exe. At first glance, those filenames sure do look suspicious. And the parent process binary is flagged by a small number of AV engines as malicious. Finally, it is always a little suspicious to see 32-bit processes on x64 version of Windows. However, the most curious thing about this process tree 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 fairly low prevalence metrics for a binary that claims to be published by Google. This file has been uploaded to VirusTotal only once and has only been seen in the last couple weeks despite claiming to be a version of GoogleUpdate.exe from months and months ago:

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. Something seems fishy so despite the Google, Inc legitimate authenticode certificate we look closer at this process and see this image load:

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

It seems like the attack goes something like the following:

• Attacker who already has privileged access creates a new randomly-generated Program files directory
• Attacker places a randomly-named legitimate copy of GoogleUpdate.exe into this directory
• Attacker places a malicious goopdate.dll into the same directory that executes their intended functionality
• Attacker triggers the execution of the randomly-named Google Update and it loads goopdate.dll from its directory

This is a nice example of attacker tradecraft where a privilege process can persist and bypass detection tools that evaluate the trustworthiness of a process by its process binary digital signature. We can use the Veramine portal to pivot on this technique and find other instances of similar tradecraft.

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 tasks
3. It passes in a url recently registered on GoDaddy as an ominous sounding "bindurl" parameter

Each of these individual processes and persistence mechanisms can be dealt with and remediated individually. However, these discoveries also reveal attacker tactics. We can use this single discovery to find more instances of similar attacker activity. In this particular case, a command line search for "client.DownloadFile" revealed 23 additional likely-malicious Powershell processes not previously triaged:

That first CloudFront DownloadFile was on a host not previously thought to have been infected. The Powershell DownloadFile tactic uncovered a process tree involving potentially malicious software (28 AV hits) that was signed by a legitimate company and running as LocalSystem:

In a true Hunt operation, we would follow that rabbit trail with the 22 other malicious Powershell processes. For this hunt operation, we will return to the next rundll32.exe process:

In following the same pattern as before, we find that the WinSAP.dll is likely malicious (9/62 VT) but more importantly we 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 end up being malicious and we use the CPK.exe association to reveal yet another malicious process tree:

The remaining rundll32.dll in the suspicious list ended up being mostly adware but 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 will result in new heuristic and machine learning algorithms for the Veramine detection engine.