Friday Cyber Briefing • Microsoft Defender XDR • LOLBins • Rundll32.exe
Rundll32.exe Was Only Following Orders
Microsoft trusted it.
Windows signed it. The file lived exactly where defenders expected it to live: System32.
But the command line told a different story.
rundll32.exe was not the attacker.
It was simply executing the instructions someone else had given it.
LOLBins Investigation
The alert named rundll32.exe, but the investigation was not about the filename. It was about the DLL, the parent process, the command line and what happened next.
Inspect the command line
Find the DLL path
Follow child processes and network activity
The signed binary was not the whole story
At first glance, the process looked legitimate. The behaviour changed the investigation.
09:14 — DLL written
A DLL appeared in a user-writable location. The filename did not immediately scream malware.
09:15 — rundll32.exe executed
The trusted Microsoft binary launched and loaded the DLL. The process name looked normal. The arguments did not.
09:17 — the chain continued
PowerShell, network activity and persistence followed. The executable was only one step in the chain.
Why attackers abuse rundll32.exe
rundll32.exe is a legitimate Windows component used to execute exported functions from DLL files. That legitimacy is exactly why attackers like it.
It is trusted
Many environments expect rundll32.exe to exist and run. The filename alone rarely tells the full story.
It executes instructions
The real evidence often sits in the command line: which DLL, which export and which path was used.
It can hide in normal noise
Living-off-the-land activity can blend into routine endpoint telemetry unless the process tree is reviewed.
Find rundll32.exe execution
Start by finding rundll32.exe and projecting the command line, initiating process and account context.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
DeviceProcessEvents | where Timestamp > ago(7d) | where FileName =~ "rundll32.exe" | project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine | order by Timestamp desc
Look for suspicious DLL paths
A DLL loaded from AppData, Temp, Downloads or Public deserves more attention than a standard Windows path.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "rundll32.exe"
| where ProcessCommandLine has_any ("AppData", "Temp", "Downloads", "Users\\Public")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc
Follow child processes from rundll32.exe
If rundll32.exe launches PowerShell, CMD or another script host, the executable name is only the start of the investigation.
- 1
- 2
- 3
- 4
- 5
- 6
DeviceProcessEvents | where Timestamp > ago(7d) | where InitiatingProcessFileName =~ "rundll32.exe" | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine | order by Timestamp asc
Check whether rundll32.exe contacted the network
Network activity from rundll32.exe is not always malicious, but it should be explained by the command line, parent process and timeline.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
DeviceNetworkEvents | where Timestamp > ago(7d) | where InitiatingProcessFileName =~ "rundll32.exe" | project Timestamp, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessCommandLine | order by Timestamp desc
What the investigation revealed
The trusted executable did not answer the question. The timeline did.
The DLL path mattered
rundll32.exe loading from a user-writable folder changed the meaning of the event.
The process tree mattered
The parent process explained how rundll32.exe started. The child processes explained what it enabled.
The command line mattered most
The executable looked legitimate. The arguments revealed the instruction it had been given.
Investigation lessons
This is why analysts should investigate behaviour, not just signed binaries.
Do not stop at the process name
A trusted Windows executable can still be used to execute attacker-controlled instructions.
Follow the instructions
For rundll32.exe, the key question is not only that it ran. It is what DLL and export it was told to execute.
Build the timeline
File write, rundll32 execution, child process, network connection and persistence only make sense together.
Related Agent Foskett investigations
This briefing connects naturally to other LOLBin, PowerShell, process tree and persistence investigations.
Mshta.exe Wasn't The Real ProblemA LOLBin investigation where the process tree mattered.
The Process Was Signed By MicrosoftWhy a signature does not automatically explain behaviour.
The Child Process Shouldn't Have ExistedUnexpected child processes can change the entire incident story.
The User Closed The Browser... The Process Didn'tA browser disappeared, but the child process kept running.
Nothing Flagged The PowerShell DownloadWhy no alert does not mean no activity.
The Scheduled Task Was Created At 2:41AMPersistence hidden inside legitimate Windows automation.
Final thought
The trusted process did exactly what it was told to do. That was the problem.
The Logs Already Knew.
The evidence was not missing. It was sitting in the command line, waiting for someone to ask what rundll32.exe had been told to run.
The binary followed orders
rundll32.exe was not malicious by itself. The instruction, path and sequence changed the meaning of the event.
The timeline changed everything
The DLL write, rundll32 command, child process, network activity and persistence only made sense together.
