Rundll32’s necessity, capabilities, frequency of execution, and legitimacy make it an attractive target for adversaries intent on blending in.Pairs with this song
Percent of customers affected
Total threat volume
While there are plenty of legitimate reasons to run this native Windows process, we’ve seen adversaries run it to commit misdemeanors…and worse.
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.
minidump, we commonly see adversaries injecting
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:\users\public\delay(1).txt,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.
- Cobalt Strike
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-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 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.
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.
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.
Red Canary has developed nearly 100 distinct detection analytics to catch malicious and suspicious Rundll32 behaviors. The following section summarizes some of our most successful analytics for detecting malicious use of Rundll32.
Note: These detection analytics may require tuning.
Application bypass with
DLLs that are designed to be loaded by Regsvr32 are expected to have a
DllRegisterServer export function implemented. Adversaries will often supply the same DLL to
rundll32.exe as well. Executing the
DllRegisterServer export function with
rundll32.exe is tradecraft that’s unique to adversary behavior and is rarely seen in legitimate scenarios. We’ve observed this behavior in threats including Qbot, Ursnif, and Zloader, to name a few examples.
process == rundll32.exe && command_includes ('DllRegisterServer')
There are many built-in DLLs that export a
DllRegisterServer function. Here is an example of executing a
Rundll32 with suspicious process lineage
As is the case with most techniques in this report, it’s critical that you are able to take stock of what is normal in your environment if you hope to be able to identify what isn’t. In the context of Rundll32, you’ll want to monitor for executions of
rundll32.exe from unusual parent processes, and the following pseudo-analytic—based on an amalgamation of Red Canary detection logic—should help security teams do just that.
parent_process == ('winword.exe' || 'excel.exe' || 'msaccess.exe' || 'lsass.exe' || 'taskeng.exe' || 'winlogon.exe' || 'schtask.exe' || 'regsvr32.exe' || 'wmiprvse.exe' || 'wsmprovhost.exe') && process == rundll32.exe
One way to replicate this behavior is to launch
rundll32.exe via WMI. The following example will launch
rundll32.exe as a child process of
wmic process call create "rundll32.exe C:\Windows\System32\jscript.dll"
Suspicious export functionalities
Consider monitoring for instances of
rundll32.exe running Windows native DLLs that have export functionalities that adversaries commonly leverage for executing malicious code and evading defensive controls. The following pseudo-analytic applies specifically to adversaries who use the
MiniDump export functionality of
comsvcs.dll to dump the contents of LSASS, but this logic could be adapted to detect other malicious activity as well.
process == rundll32.exe || modload == comsvcs.dll && command_includes ('MiniDump' || '#24')
Rundll injection into LSASS
The following pseudo-detector should help security teams detect instances where Rundll32 opens a cross process handle into LSASS to collect credentials.
process_name == rundll32.exe && cross_process == lsass.exe
The following example will dump process memory using the
MiniDump export. Just replace the process ID (7084 below) to the process ID of your choosing.
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump 7084 memory.dmp full
Rundll32 without a command line
Rundll32 does not normally execute without corresponding command-line arguments and while spawning a child process. Given this, you may want to alert on the execution of processes that appear to be
rundll32.exe without any command-line arguments , especially when they spawn child processes or make network connections.
process == rundll32.exe && command_includes (“”)* && has_network_connection || has_child_process
“” indicates a blank command line.
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.
Start testing your defenses against Rundll32 using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
View atomic tests for T1218.011: Rundll32. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using Command Prompt:
rundll32.exe pcwutl.dll,LaunchApplication C:\Windows\System32\notepad.exe
What to expect
notepad.exe will spawn as a child process of
Useful telemetry will include:
EDR tools, Sysmon Event ID 1, and Windows Security Event ID 4688 should collect relevant telemetry.
Command-line logging will capture the context of what is executed.
EDR tools, Sysmon Event ID 1, and Windows Security Event ID 4688 should collect relevant telemetry.
EDR tools and Sysmon Event ID 7 should collect relevant telemetry.
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.