Microsoft Defender XDR • DeviceProcessEvents • Threat Hunting

The Child Process Shouldn't Have Existed

The alert itself was not unusual. A user opened a Word document.

Nobody worries when WINWORD.EXE starts.

But three seconds later, Word launched PowerShell. The parent process made sense. The child process did not.

Discuss your environment Back to briefings

Agent Foskett investigation into suspicious child processes using Microsoft Defender XDR DeviceProcessEvents

Briefing summary

A normal document open became suspicious when Microsoft Defender showed WINWORD.EXE spawning PowerShell. The file was not the first clue. The process relationship was.

Office document launched PowerShell

Parent and child process did not match

DeviceProcessEvents revealed execution

What happened

The alert was not dramatic. A user opened a document. The process tree changed the entire story.

The document looked legitimate Users open Word documents every day. Nothing appeared suspicious during the initial review.

A new process appeared WINWORD.EXE spawned powershell.exe moments after the file opened. That behaviour did not belong in a normal document workflow.

The timeline exposed the attack The process chain revealed execution activity hiding behind a seemingly harmless document.

The KQL that changed everything

The evidence lived in Microsoft Defender XDR. The question was simple: what child processes were launched by Office applications?

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ (
                            "WINWORD.EXE",
                            "EXCEL.EXE",
                            "POWERPNT.EXE",
                            "OUTLOOK.EXE")
| where FileName in~ (
                            "powershell.exe",
                            "cmd.exe",
                            "mshta.exe",
                            "wscript.exe",
                            "cscript.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, AccountName
| order by Timestamp desc

What it revealed Word was launching processes that normally should not exist in a standard document workflow.

No signature required The investigation was not triggered by a known malware name. It was triggered by behaviour.

The pattern was there The parent process, child process, command line and timestamp formed a timeline that explained the execution chain.

Pivot into the wider process timeline

Once the suspicious child process appears, widen the search around the device and timestamp to understand what happened before and after.

let SuspiciousDevice = "DEVICE-NAME";
let StartTime = datetime(2026-06-16T01:00:00Z);
DeviceProcessEvents
| where DeviceName == SuspiciousDevice
| where Timestamp between (StartTime .. StartTime + 30m)
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, ReportId
| order by Timestamp asc

Agent Foskett moment

Everyone focused on the document. The process tree told the real story.

Everyone looked at the document The file looked like the obvious place to start, but the most important evidence appeared after the document opened.

Nobody looked at the process tree The evidence was not inside the document itself. It was in the chain of processes that followed.

This is where strong endpoint security visibility matters.

The process chain told the story WINWORD.EXE launched PowerShell, PowerShell ran a command line, and the device activity started to make sense.

What it was not It was not just a document open. It was not just PowerShell existing on a device. It was not just normal user activity.

What it actually was Execution through a trusted application. The attacker used a normal parent process to launch an abnormal child process.

Why it matters PowerShell is not automatically malicious. But PowerShell launched by Word deserves immediate attention.

What most environments miss

Parent-child process activity should be treated as security-sensitive evidence, not routine endpoint noise.

Parent-child relationships matter Attackers often abuse trusted applications to launch scripting engines, command shells or payload loaders.

Command lines need context A command may look harmless by itself. The parent process can change the entire meaning of the event.

The missing skill The investigation is not just what process ran. It is what launched it, when it launched, and what it did next.

Related investigations

The PowerShell Command Was Base64 Encoded Encoded PowerShell can hide the real intent of a command line during endpoint execution. Read more →

The Device Was Talking To Something It Shouldn't Device network activity can reveal the next stage after suspicious process execution. Read more →

The Connection Happened At 1:22AM Timing, network activity and device signals can show when suspicious activity really started. Read more →

The Logs Already Knew The evidence often exists before anyone knows there is an incident. Read more →

KQL Threat Hunting Guide Build practical Microsoft Defender XDR and Sentinel investigations across endpoint, identity and cloud signals. Read more →

Final thought

A process is not just a filename. It is part of a story.

At GEMXIT We help organisations investigate endpoint activity, Microsoft Defender XDR alerts and process-level evidence across Windows environments. If you want to understand how this applies to your environment, see our Cyber Security services.

Agent Foskett mindset Do not just ask whether PowerShell ran. Ask what launched it, what command line it used, what happened next and whether that process should have existed.

A successful login does not always mean a safe login. If you're investigating risky Microsoft 365 sign-ins, review MFA session hijacking, trusted device abuse, Conditional Access report-only gaps, impossible travel sign-ins, and strengthen visibility through our Identity and Access controls and KQL Threat Hunting Guide.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD