Skip Navigation
Request Demo
 
 
 
 
 
 
 
 
 
 

Sub-technique T1218.011

Rundll32

Rundll32’s necessity, capabilities, frequency of execution, and legitimacy make it an attractive target for adversaries intent on blending in.

Pairs with this song

#3

Sub-technique rank

23.3%

Percent of customers affected

1713

Total threat volume
 

Analysis Icon

Analysis

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.

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

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, including Grief ransomware, IcedID, Qbot, TrickBot, and Ursnif, among others.

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.

For its part, the command and control (C2) tool Cobalt Strike often delivers beacon payloads in the form of DLLs. We reliably observe Cobalt Strike leveraging Rundll32 to call the StartW export function and load DLLs from the command line. We also occasionally see Cobalt Strike and a wide variety of other tools leverage Rundll32 to load code from DLLs within world-writable directories (e.g., the Windows temp directory).

Visibility icon

Visibility

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.

Collection Icon

Collection

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.

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.

Icon-threat detection

Detection

 

Red Canary has developed more than 75 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 DllRegisterServer function

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_line_includes ('DllRegisterServer')

There are many built-in DLLs that export a DllRegisterServer function. Here is an example of executing a DllRegisterFunction with rundll32.exe:

rundll32.exe C:\Windows\System32\jscript.dll,DllRegisterServer

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 wmiprvse.exe:

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
&&
command_line_includes ('MiniDump')

Similarly, we’ve detected a lot of Cobalt Strike activity over the years using a detection analytic that largely looks for a known malicious export functionality.

process == rundll32.exe
&&
command_line_includes ('StartW') 

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_line_includes (“”)*
&&
has_network_connection
||
has_child_process

*Note: “” 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.

Testing Icon

Testing

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.

Getting started

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 rundll32.exe.

Useful telemetry will include:
VisibilityTelemetryCollection
Visibility:

Process monitoring

Telemetry:

A rundll32.exe process will start. A notepad.exe process will also start as a child process of rundll32.exe.

Collection:

EDR tools, Sysmon Event ID 1, and Windows Security Event ID 4688 should collect relevant telemetry.

Visibility:

Command monitoring

Telemetry:

Command-line logging will capture the context of what is executed.

Collection:

EDR tools, Sysmon Event ID 1, and Windows Security Event ID 4688 should collect relevant telemetry.

Visibility:

Module monitoring

Telemetry:

pcwutl.dll will load in the rundll32.exe process.

Collection:

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.

 
Back to Top