Agent Foskett • Microsoft Defender XDR • Threat Hunting

Rundll32 Looked Legitimate

Signed Microsoft binary.

Running from System32.

No malware alert. No user complaint. No obvious red flag on the dashboard.

Everything looked legitimate — until we looked closer.

The process was rundll32.exe, a normal Windows component used to run functions inside DLL files. But behind that trusted filename was behaviour that did not fit the environment: unusual command-line arguments, execution from temporary locations, strange parent process activity and unexpected outbound network connections.

This Agent Foskett briefing looks at how trusted Windows binaries can be abused, why filenames alone are not enough, and how Microsoft Defender XDR advanced hunting can expose the behaviour behind the process.

Agent Foskett investigates suspicious rundll32 activity in Microsoft Defender XDR
Briefing summary

Attackers often abuse trusted Windows binaries like rundll32.exe to blend into normal activity. This briefing explores how Defender XDR hunting can expose suspicious command lines, DLL execution paths, process lineage and unusual network activity.

Investigate suspicious rundll32 behaviour
Hunt with DeviceProcessEvents
Review process lineage and DLL execution
🚨 A trusted filename does not always mean trusted behaviour.
Rundll32.exe may be legitimate, but what it launches, where it launches from and who launched it can completely change the investigation.
Book a security review →

Why rundll32.exe matters

Rundll32.exe is a legitimate Microsoft Windows binary used to execute functions stored inside DLL files. Because it is trusted and commonly present on Windows systems, attackers can abuse it to hide suspicious behaviour behind a normal process name. This is often described as abusing a LOLBin: a Living Off The Land Binary.
It looks legitimateRundll32.exe normally exists inside Windows system paths, so many users and defenders automatically trust it.
Attackers abuse trusted binariesThreat actors often use trusted Windows processes to reduce suspicion and avoid simplistic filename-based detections.
Behaviour matters more than filenamesThe question is not only: was rundll32.exe running? The better question is: what was rundll32.exe actually doing?

First hunt: suspicious rundll32 activity

Start by reviewing rundll32.exe executions across the environment. Focus on unusual command lines, suspicious parent processes and unexpected execution paths.
rundll32-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "rundll32.exe"
| project Timestamp,
          DeviceName,
          AccountName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          FolderPath
| order by Timestamp desc
What to reviewLook for rundll32 command lines referencing temporary folders, AppData, unusual DLL names or unexpected parameters.
Why it mattersA legitimate process can still be used to launch suspicious code, especially when the DLL path or command line does not match normal behaviour.
Best next pivotReview the initiating process, user context, device timeline, network connections and any related alerts.

What investigators should look for

Rundll32 investigations are rarely about the filename alone. The real story is usually found in the command line, parent process, folder path and related network activity.
DLL execution from temp foldersLegitimate DLLs usually execute from trusted Windows or application paths. Temporary folders and AppData locations deserve attention.
Strange parent processesRundll32 launched by browsers, Office apps, scripts, archive tools or unusual executables may indicate suspicious behaviour.
Outbound connectionsIf rundll32.exe starts communicating externally, pivot into DeviceNetworkEvents and investigate the destination.

Second hunt: did rundll32 connect externally?

Process execution alone may not tell the full story. Network telemetry can reveal suspicious outbound communication linked to rundll32.exe.
rundll32-network-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "rundll32.exe"
| project Timestamp,
          DeviceName,
          RemoteIP,
          RemoteUrl,
          InitiatingProcessCommandLine
| order by Timestamp desc

Third hunt: suspicious parent-child process relationships

Parent process context is often the clue that changes the investigation. Rundll32 launched by expected Windows components may be normal. Rundll32 launched by Office, a browser download, script host or unknown executable should be reviewed carefully.
rundll32-parent-process-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "rundll32.exe"
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe", "chrome.exe", "msedge.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc

Where defenders get caught

This type of activity can be missed when teams focus only on alerts, antivirus results or the process name itself.
They trust the filenameRundll32.exe is legitimate, but the activity it performs still needs context.
They ignore the command lineThe command line often reveals the DLL path, export function, parameters and unusual execution location.
They miss the timelineThe process may only make sense when viewed beside downloads, email activity, script execution or network connections.

How GEMXIT approaches this type of investigation

At GEMXIT, we focus on behaviour, not just alerts. A quiet dashboard does not always mean a clean endpoint. Sometimes the real signal is hiding inside process telemetry.
We review the process storyWe look at what launched the process, what command line was used, where it ran from and what happened next.
We correlate the signalsProcess, network, identity, email and timeline data are more useful together than separately.
We make Defender data usefulMicrosoft Defender XDR becomes more powerful when the data answers real investigation questions quickly.
Rundll32 looked legitimate. The behaviour did not.
GEMXIT helps organisations investigate Microsoft Defender XDR telemetry, suspicious processes, LOLBins, endpoint behaviour and practical KQL hunting workflows.
Contact GEMXIT

Final thought

Trusted processes can still perform suspicious actions.

That is why behavioural investigation matters.

Attackers know defenders trust familiar process names. They rely on someone seeing “rundll32.exe” and moving on.

But the filename is only the beginning of the story.

Sometimes the real investigation starts after asking:

“What was the trusted process actually doing?”
At GEMXITWe help organisations investigate Microsoft Defender XDR, endpoint behaviour, suspicious process activity, KQL hunting, Sentinel visibility and real-world security operations workflows.
Agent Foskett mindsetThe important question is not only: “Is the file trusted?”

It is: “Does the behaviour make sense?”

Rundll32 Looked Legitimate

This Agent Foskett briefing explains how rundll32.exe can look legitimate while hiding suspicious behaviour, DLL execution, suspicious parent processes and unexpected outbound activity inside Microsoft Defender XDR telemetry.

Microsoft Defender XDR Rundll32 Hunting

GEMXIT helps organisations investigate rundll32.exe, LOLBins, DeviceProcessEvents, DeviceNetworkEvents, process command lines, process lineage, endpoint telemetry and Microsoft Defender Advanced Hunting with KQL.

Suspicious Windows Process Investigation

Trusted Windows binaries can be abused by attackers. Defender investigation should review command line arguments, DLL paths, parent processes, folder paths, user context, network activity and endpoint timelines.