Agent Foskett • Microsoft Defender XDR • Signed Process Hunting

The Process Was Signed By Microsoft

The file was signed.

The publisher looked trusted.

Defender did not immediately block it. No malware alert fired. No user reported anything strange.

Everything appeared legitimate — until we looked at what the process actually did.

This Agent Foskett briefing looks at one of the most dangerous assumptions in endpoint investigations: believing that a trusted signature automatically means trusted behaviour.

A signed Microsoft process may be completely legitimate. But attackers often abuse legitimate Windows components, administrative tools and trusted binaries to blend into normal activity. The investigation should never stop at the signature. It should continue into the command line, parent process, folder path, user context, network activity and timeline.

Agent Foskett investigates signed Microsoft processes in Defender XDR
Briefing summary

Signed files and trusted publishers can create a false sense of safety. This briefing explains how Defender XDR hunting can reveal suspicious behaviour behind trusted Windows binaries, signed processes and legitimate tools used in unusual ways.

Review signed process behaviour
Hunt suspicious command lines
Validate parent process and network context
🚨 A trusted signature does not always mean trusted behaviour.
Signed Microsoft processes may be legitimate, but attackers often abuse trusted binaries to hide suspicious activity in plain sight.
Book a security review →

Why signed processes matter

A digital signature helps confirm where a file came from and whether it has been tampered with. That matters. But in a real investigation, the signature is only one part of the story. A legitimate signed process can still be used in a suspicious way, launched from an unusual parent process, passed dangerous command-line arguments or used to connect to unexpected destinations.
Signed does not mean safeA signed process can still perform suspicious actions if it is abused by an attacker, script, macro or compromised user session.
Attackers blend into normal toolsThreat actors often use legitimate binaries because they are already trusted, already present and often overlooked by defenders.
Behaviour is the investigationThe better question is not only who signed the file. It is what the process did, who launched it and whether the behaviour fits.

First hunt: signed Microsoft processes with suspicious context

Start by reviewing trusted Microsoft-signed processes and looking for unusual command lines, unexpected parent processes, odd folder paths or activity that does not match normal administration.
signed-process-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
  14. 14
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessVersionInfoCompanyName has "Microsoft"
| where FileName in~ ("powershell.exe", "cmd.exe", "rundll32.exe", "regsvr32.exe", "mshta.exe", "wscript.exe", "cscript.exe")
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          FolderPath
| order by Timestamp desc
What to reviewLook for unusual command lines, encoded parameters, script execution, temp folders, AppData paths or tools launched by Office and browsers.
Why it mattersA trusted binary can become suspicious when the command line, parent process or execution path does not match expected behaviour.
Best next pivotPivot into device timeline, network activity, file creation events, alerts and the user account involved.

Common signed processes attackers abuse

This is often described as living off the land: using trusted tools already present on the system to perform actions that do not immediately look malicious.
PowerShell and cmdAdministrative shells are powerful and legitimate, but suspicious when launched by Office, browsers, scripts or unknown parent processes.
Rundll32 and regsvr32Trusted Windows binaries can execute DLLs, scriptlets or unusual payloads, making command-line review essential.
Wscript, cscript and mshtaScript hosts can be abused to execute commands, launch payloads or run content that appears to come from legitimate Windows components.

Second hunt: signed processes launched by suspicious parent processes

Parent process context can change the entire investigation. A signed Microsoft process launched by normal administration may be expected. The same process launched by Word, Excel, a browser or a script host may deserve immediate review.
signed-process-parent-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "cmd.exe", "rundll32.exe", "regsvr32.exe", "mshta.exe")
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "outlook.exe", "chrome.exe", "msedge.exe", "wscript.exe", "cscript.exe")
| project Timestamp, DeviceName, AccountName, FileName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc

Third hunt: did the signed process connect externally?

A signed process making outbound connections is not automatically malicious, but it should be reviewed when the destination, timing or command line does not match normal behaviour.
signed-process-network-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("powershell.exe", "cmd.exe", "rundll32.exe", "regsvr32.exe", "mshta.exe")
| project Timestamp,
          DeviceName,
          RemoteIP,
          RemoteUrl,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp desc

Where defenders get caught

Signed-process abuse is often missed because the first visible facts look reassuring: known file name, Microsoft publisher, normal system path and no immediate antivirus block.
They stop at the signatureThe signature may prove the file is legitimate, but it does not prove the behaviour is safe.
They ignore the command lineAttackers often reveal themselves through encoded strings, download commands, unusual parameters and suspicious script execution.
They miss the parent processThe signed process may look normal until you see that it was launched by Outlook, Word, Excel, a browser or a script host.

How GEMXIT approaches this type of investigation

At GEMXIT, we treat signatures as useful context, not final proof. A signed Microsoft process should still be reviewed when the behaviour is unusual, especially if it appears in a suspicious sequence of events.
We review the full process storyWhat launched it, what command line was used, where it ran from and what happened immediately before and after?
We correlate the evidenceProcess, network, identity, email, URL click and file events become more powerful when reviewed together.
We challenge trusted assumptionsThe investigation asks whether the behaviour makes sense, not whether the file name feels familiar.
The process was signed by Microsoft. The behaviour still needed investigating.
GEMXIT helps organisations investigate Microsoft Defender XDR telemetry, signed process abuse, LOLBins, suspicious command lines and practical KQL hunting workflows.
Contact GEMXIT

Final thought

A trusted signature is helpful.

But it is not the end of the investigation.

Attackers know defenders trust familiar publishers, normal Windows paths and well-known process names. They rely on someone seeing “Microsoft Corporation” and moving on.

But the signature is only one clue.

The real investigation starts after asking:

“Does the behaviour make sense?”
At GEMXITWe help organisations investigate Microsoft Defender XDR, suspicious endpoint behaviour, signed process abuse, LOLBins, KQL hunting, Sentinel visibility and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “Who signed the file?”

It is: “What did the process actually do?”

The Process Was Signed By Microsoft

This Agent Foskett briefing explains how a signed Microsoft process can still require investigation when command lines, parent processes, execution paths or network activity do not match normal behaviour.

Microsoft Defender XDR Signed Process Hunting

GEMXIT helps organisations investigate signed process abuse, LOLBins, DeviceProcessEvents, DeviceNetworkEvents, process command lines, parent process relationships, endpoint telemetry and Microsoft Defender Advanced Hunting with KQL.

Suspicious Signed Process Investigation

A trusted digital signature does not automatically prove safe behaviour. Defender investigations should review command line arguments, folder paths, initiating processes, user context, network destinations, file events and endpoint timelines.