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.