Rundll32

Why do adversaries use Rundll32?

Like other prevalent ATT&CK techniques, Rundll32 is a native Windows process and a functionally necessary component of the Windows operating system that can’t be blocked or disabled without breaking things. Adversaries typically abuse Rundll32 because it makes it hard to differentiate malicious activity from normal operations. More often than not, we observe adversaries leveraging Rundll32 as a means of credential theft and execution bypass.

From a practical standpoint, Rundll32 enables the execution of dynamic link libraries (DLL). Executing malicious code as a DLL is relatively inconspicuous compared to the more common option of executing malicious code as an executable. Under certain conditions, particularly if you lack controls for blocking DLL loads, the execution of malicious code through Rundll32 can bypass application control solutions.

How do adversaries use Rundll32?

Adversaries abuse Rundll32 in many ways, but we commonly observe the following generic patterns of behavior:

• using legitimate functions to bypass application control solutions
• abusing legitimate DLLs or export functions to perform malicious actions
• executing malicious, adversary-supplied DLLs
• renaming or relocating legitimate DLLs and using them for malicious purposes

Adversaries also abuse legitimate DLLs and their export functions. We’ve seen adversaries use Rundll32 to load comsvcs.dll, call the minidump function, and dump the memory of certain processes—oftentimes LSASS. More broadly, adversaries particularly like to leverage export functions capable of connecting to network resources and bypassing proxies to evade security controls.

Similar to minidump, we commonly see adversaries injecting rundll32.exe into lsass.exe to gain access to the memory contents of LSASS.

We commonly observe adversaries executing Rundll32 with unusual command-line parameters, from unexpected file paths, with uncommon filenames that do not use DLL or PE file extensions for execution, or with obfuscated export functions. For example, DllRegisterServer is a DLL export function intended for use with regsvr32.exe, but adversaries commonly call it with Rundll32 as a means of bypassing application controls. We’ve observed a variety of threats leveraging the DllRegisterServer function in this way. Common examples include the following commands:

"C:\Windows\system32\cmd.exe" /c start rundll32 \cdfabdefacdeabcdfabdefacdeabcdfabdefacdfbf.cdfabdefacdeabcdfabdefacdeabcdfabdefacdfbf,JskFxphZumezrjnI

"C:\WINDOWS\system32\rundll32.exe" "C:\ProgramData\45f51194.dat",DllRegisterServer

Last but not least, we detect adversaries abusing alternate data streams to conceal malicious content inside otherwise normal-seeming DLL export functions. Take the following as an example.

"rundll32.exe" C:\Users\[redacted]:temp.dll,Start

Associated threats

• Gamarue
• Conficker
• IcedID
• Cobalt Strike
• Dumpert
• Danabot

Application control solutions such as Windows Defender Application Control, VMware App Control, Airlock, and others can provide functionality to limit which DLLs can be loaded and executed into memory.

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Like much of Red Canary’s detection logic for native Windows binaries, analytics for catching adversaries who abuse Rundll32 lean heavily on process, process access, and command monitoring. Network connection and module-related telemetry can provide additional enrichment for detections as well. These telemetry sources are widely available via commercial EDR products, native logging, and free or open source tooling.

Command monitoring

Command-line parameters are some of the most reliable telemetry for detecting malicious use of Rundll32, since adversaries often need to pass command-line arguments for Rundll32 to execute. Eight of our top 10 detection analytics for Rundll32 include a command-line component. Capturing command-line activity will capture the both name of the DLL that was launched by rundll32.exe and any additional command-line arguments.

Process monitoring

Process monitoring is another useful data source for observing malicious execution of Rundll32. Nearly all of our Rundll32-related detection analytics look for the execution of a process that seems to be Rundll32 in conjunction with either another process (parent or child), a corresponding command line, or some other data source. Since adversaries can rename binaries, you’re better off identifying a process via binary metadata rather than executable filename.

Process access monitoring

Cross-process events warrant monitoring as well, considering the high volume of credential theft activity we observe that involves Rundll32 opening a handle into LSASS.

Network monitoring

While not nearly as reliable or common as processes or command lines, network connections occasionally play a supporting role in our behavioral detectors for Rundll32. In conjunction with certain combinations of process lineage or command-line parameters, any network connection might be suspicious. In other circumstances, network connections might only be suspicious if they’re made to unexpected or newly registered domains.

Module monitoring

DLL monitoring will supply context about the malicious DLL that was supplied at the command line, including its file hash and directory. Module load monitoring can be useful on its own, particularly if an adversary is supplying overtly malicious or suspicious DLLs, but the telemetry source works best in conjunction with others.

Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Sysmon Event ID 1: Process creation

Sysmon Event ID 1 logs information about process execution and corresponding command lines. This is a great starting point for gaining visibility into adversarial abuse of Rundll32, as most Red Canary detection analytics for this and other techniques lean heavily on a combination of process and command monitoring.

Sysmon Event ID 3: Network connection

Sysmon Event ID 3 logs network connections and ties those connections to corresponding processes. Disabled by default, the log includes information about source and destination IP addresses, ports, and more. While this Sysmon event log can provide important context for an investigation, it can also generate a lot of distraction. Fortunately, Sysmon offers powerful filtering, enabling network connection monitoring to be limited to specific processes.

Sysmon Event ID 7: Image loaded

Sysmon Event ID 7 logs all DLL loads. It is also disabled by default because it generates a large amount of noise. Tuning will be critical if you hope to operationalize this data source in any meaningful way. That said, it can provide detailed context about the malicious DLL an adversary executed, including its file hash and directory.

Sysmon Event ID 8: CreateRemoteThread

Sysmon will log an event when it detects a process creating a thread in another process. In the case of process injection, it could be possible to identify Rundll32 injecting into LSASS to perform credential theft.

Windows Security Event ID 4688: Process Creation

Event ID 4688 logs both process command line and process executable details. While this data source is somewhat redundant with Sysmon Event ID 1, it’s also entirely native to Windows.

Weeding out false positives

While process monitoring and command-line parameters are great sources for telemetry that can be useful for detecting malicious Rundll32, they require environment-specific tuning. As you can imagine, Rundll32 is used by many legitimate tools. To avoid flooding your security team with a ton of false positives, establish a baseline on what activity is normal in your environment and then write rules that will exclude the known activity. This is a great starting point, but keep in mind that these analytics will likely require a lot of tuning and monitoring to get to the point where they reliably produce high-fidelity alerting.