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 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.
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:
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.,
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.