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.
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.
Why signed processes matter
First hunt: signed Microsoft processes with suspicious context
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 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
Common signed processes attackers abuse
Second hunt: signed processes launched by suspicious parent processes
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 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?
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 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
How GEMXIT approaches this type of investigation
Final thought
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?”
It is: “What did the process actually do?”
Continue the investigation with Rundll32 Looked Legitimate, The PowerShell Never Triggered An Alert, Microsoft Defender KQL Threat Hunting Guide, KQL Threat Hunting in Defender and Sentinel, Agent Foskett Academy, Microsoft Security and the GEMXIT Security Review.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD