Technique T1218.011

Rundll32

Adversaries use this native Windows process to execute malicious code through dynamic link libraries (DLL), often to bypass application controls.

#2

Parent technique rank

30%

Organizations affected

2380

Confirmed threats

Analysis

Why do adversaries use Rundll32?

Like many of the most prevalent ATT&CK techniques, Rundll32 is a native Windows process that’s installed by default on nearly every Microsoft computer dating back to Windows 95. It is a functionally necessary component of the Windows operating system that can’t be simply blocked or disabled. This necessity and ubiquity makes Rundll32 an attractive target for adversaries intent on blending in.

From a practical standpoint, Rundll32 enables the execution of native dynamic link libraries (DLL). Executing malicious code as a DLL allows an adversary to keep their malware from appearing directly in a process tree, as a directly executed EXE would. Additionally, adversaries are known to abuse export functionality in legitimate DLLs, including those that can facilitate connection to network resources to bypass proxies and evade detection. Under certain conditions, particularly if you lack controls for blocking DLL loads, the execution of malicious code through Rundll32 can bypass application controls.

Beyond DLLs, Rundll32 can also execute JavaScript via the RunHtmlApplication function.

How do adversaries use Rundll32?

Adversaries abuse Rundll32 in a wide variety of ways, so we’ll limit our focus to variations we encounter regularly.

Adversaries often leverage Rundll32 to load code from DLLs within world-writable directories (e.g., the Windows temp directory), a pattern of behavior that you might see from legitimate enterprise software as well as not-so-legit tools like Cobalt Strike.

As we’ve covered on the Red Canary blog, adversaries use Rundll32 to load the legitimate comsvcs.dll, which calls the MiniDump function, allowing adversaries to dump the memory of certain processes. We’ve observed adversaries leveraging this technique to retrieve cached credentials from lsass.exe, which is illustrated below.

DllRegisterServer is a legitimate function of Rundll32 that is used for a variety of innocuous reasons. However, we’ve also seen several threats—from droppers for Qbot, Dridex, and others to ransomware such as Egregor and Maze—leverage it as a mechanism to bypass application controls. The following illustrates a generic example of an adversary using DllRegisterServer to bypass application controls.

Another detectable example we encounter frequently with Rundll32 involves Cobalt Strike, which leverages the StartW function to load DLLs from the command line. The use of that export function is a telltale sign you are dealing with Cobalt Strike. The following is an example of what that might look like:

In what might be an example of a malicious scheduled task, we’ve also observed backdoors that leverage taskeng.exe to spawn Rundll32 and execute malicious code.

Last and perhaps least frequently, we observe a decent amount of USB worm activity wherein Rundll32 executes in conjunction with a command line containing non-alphanumeric or otherwise unusual command-line characters. We most frequently see this with Gamarue, as in the example below.

Definition

Detection

Collection requirements

Command-line monitoring

Process command-line parameters are one of the most reliable sources to detect malicious use of Rundll32, since you need to pass command-line arguments for Rundll32 to execute.

Process monitoring

Process monitoring is another fruitful data source for observing malicious execution of Rundll32. Understanding the context in which Rundll32 executes is critically important to an investigation. Sometimes the execution of Rundll32 by itself won’t be enough to determine malicious intent, and that’s when you can rely on process lineage to gain additional context.

Detection suggestions

Some successful analytics for detecting malicious use of Rundll32 include the following:

Execution from world-writable folders

Since adversaries will try to use Rundll32 to load or write DLLs from world or user-writable folders, it makes sense to watch for rundll32.exe writing or loading files to or from any of the following locations:

  • %APPDATA%
  • %PUBLIC%
  • %ProgramData%
  • %TEMP%
  • %windir%\system32\microsoft\crypto\rsa\machinekeys
  • %windir%\system32\tasks_migrated\microsoft\windows\pla\system
  • %windir%\syswow64\tasks\microsoft\windows\pla\system
  • %windir%\debug\wia
  • %windir%\system32\tasks
  • %windir%\syswow64\tasks
  • %windir%\tasks
  • %windir%\registration\crmlog
  • %windir%\system32\com\dmp
  • %windir%\system32\fxstmp
  • %windir%\system32\spool\drivers\color
  • %windir%\system32\spool\printers
  • %windir%\system32\spool\servers
  • %windir%\syswow64\com\dmp
  • %windir%\syswow64\fxstmp
  • %windir%\temp
  • %windir%\tracing

Export functionalities

You should also 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.

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.

Unusual 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 or untrusted parent processes. This will vary from one organization to another, but some examples of process that usually won’t spawn Rundll32 might include:

  • Microsoft Office products (e.g., winword.exe, excel.exe, msaccess.exe, etc.)
  • lsass.exe
  • taskeng.exe
  • winlogon.exe
  • schtask.exe
  • regsvr32.exe
  • wmiprvse.exe
  • wsmprovhost.exe

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

Getting Started With Atomic Red Team

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:
Data sourceTelemetry
Data source:

Process monitoring

Telemetry:

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

Data source:

Process command-line parameters

Telemetry:

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

Data source:

DLL monitoring

Telemetry:

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

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.

Rodrigo Garcia
Detection Engineer
Rodrigo is a detection engineer at Red Canary, where he spends his time finding new threats, building automation to reduce workloads, and delivering consistent threat detections to customers and partners. Prior to Red Canary, Rodrigo worked at General Electric in various roles spanning incident response, detector development, and threat hunting. In his spare time, he enjoys working on smart home automation, playing tennis, traveling, and spending time with his family.
Rodrigo is a detection engineer at Red Canary, where he spends his time finding new threats, building automation to reduce workloads, and delivering consistent threat detections to customers and partners. Prior to Red Canary, Rodrigo worked at General Electric in various roles spanning incident response, detector development, and threat hunting. In his spare time, he enjoys working on smart home automation, playing tennis, traveling, and spending time with his family.