Agent Foskett Academy • KQL Academy • Module 12 • Lesson 143 • Endpoint Investigation

Lesson 143 — The Process Tree Didn't Match Normal User Activity

Lesson 142 made the encoded PowerShell command readable. Now the investigation moves outward again.

A single process rarely tells the whole story. The parent that launched it, the children it created and the order in which those processes appeared can reveal whether an execution chain fits normal user behaviour — or whether something else is controlling the endpoint.

Don't investigate the process in isolation. Investigate its family.

Begin the Investigation Back to KQL Academy

Agent Foskett KQL Academy suspicious process tree investigation

Your case file

On WS-FIN-042, the PowerShell execution from the previous investigation is surrounded by a process chain that does not resemble ordinary interactive user activity.

✓ Reconstruct parent-child relationships

✓ Follow a suspicious process by PID

✓ Compare the chain with surrounding activity

✓ Build an evidence-based process timeline

Case briefing

CASE FILE Device: WS-FIN-042 User: j.smith browser.exe ↓ powershell.exe ↓ cmd.exe ↓ rundll32.exe THE QUESTION Is this a legitimate sequence of user activity, or does the process tree show an abnormal execution chain?

Investigation objective

Use DeviceProcessEvents to reconstruct the execution chain around a suspicious process, follow parent-child relationships and determine whether the process tree fits the user's expected activity.

Investigator's rule

A process name is context, not a conclusion. Legitimate Windows tools can appear in malicious chains. What matters is who launched them, with what command line, under which account and what happened next.

Stage 1 — reconstruct the local process timeline

Begin with the known device and time from the previous lesson. Keep both the process and initiating-process fields visible so the relationships are not lost.

123456789

let TargetDevice = "WS-FIN-042";
let TargetTime = datetime(2026-08-18 01:22:11);
DeviceProcessEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (TargetTime - 10m .. TargetTime + 10m)
| project Timestamp, AccountName, FileName, ProcessCommandLine,
          ProcessId, InitiatingProcessFileName,
          InitiatingProcessCommandLine, InitiatingProcessId
| order by Timestamp asc

Read the relationship

FileName identifies the process that was created. InitiatingProcessFileName identifies the process responsible for creating it. The PID fields help you follow those relationships more precisely.

Sequence matters

A browser followed by PowerShell, then a command shell and another system utility tells a different story from four unrelated processes spread across the day. Time and ancestry turn events into a chain.

Stage 2 — follow the suspicious PowerShell process

We already know the PowerShell PID from Lesson 142. Use it as a pivot to find the process itself and any processes directly initiated by it.

12345678

let TargetDevice = "WS-FIN-042";
let SuspiciousPID = 7316;
DeviceProcessEvents
| where DeviceName =~ TargetDevice
| where ProcessId == SuspiciousPID or InitiatingProcessId == SuspiciousPID
| project Timestamp, FileName, ProcessCommandLine, ProcessId,
          InitiatingProcessFileName, InitiatingProcessId, AccountName
| order by Timestamp asc

Why use the PID?

Process names are reused constantly. A PID lets you narrow the investigation to a specific process instance on the device rather than every occurrence of powershell.exe.

Keep time in mind

PIDs can be reused. Always interpret a PID together with the device and timestamp context rather than treating the number alone as permanently unique.

Stage 3 — ask what is normal around this event

Before labelling a parent-child pair suspicious, look at the process relationships observed around the investigation window. This gives you local context for the device.

1234567

let TargetDevice = "WS-FIN-042";
let TargetTime = datetime(2026-08-18 01:22:11);
DeviceProcessEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (TargetTime - 15m .. TargetTime + 15m)
| summarize Executions=count() by InitiatingProcessFileName, FileName
| order by Executions desc

Rare does not equal malicious

A relationship seen once can be important, but rarity alone is not proof. Software updates, administrative tools and unusual but legitimate workflows can all create uncommon process chains.

Common does not equal safe

Attackers often use legitimate system binaries precisely because they are common. Frequency helps with context; it does not replace investigation.

Stage 4 — focus on interpreters and system utilities

Narrow the timeline to processes frequently useful during endpoint investigations. The goal is not to declare these binaries malicious, but to expose relationships that deserve closer inspection.

12345678910

let TargetDevice = "WS-FIN-042";
let TargetTime = datetime(2026-08-18 01:22:11);
DeviceProcessEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (TargetTime - 10m .. TargetTime + 10m)
| where FileName in~ ("powershell.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
    or InitiatingProcessFileName in~ ("powershell.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
| project Timestamp, InitiatingProcessFileName, FileName,
          ProcessCommandLine, ProcessId, InitiatingProcessId, AccountName
| order by Timestamp asc

What should stand out?

Look for unexpected parent-child combinations, unusual command lines, rapid hand-offs between interpreters, execution under the wrong user context or a chain beginning from an application that would not normally launch those tools.

Don't build a blacklist

cmd.exe, rundll32.exe, mshta.exe and scripting hosts have legitimate uses. Investigate their relationships and behaviour rather than judging the filename alone.

Stage 5 — turn rows into a process tree

The table is evidence, but the investigator still needs to reconstruct the relationship using timestamps, process IDs, initiating process IDs and command lines together.

01:22:07 browser.exe PID 6024 │ └── 01:22:11 powershell.exe PID 7316 -EncodedCommand ... │ └── 01:22:16 cmd.exe PID 7440 │ └── 01:22:19 rundll32.exe PID 7508 INVESTIGATION QUESTION What user action would reasonably explain this exact sequence?

Ask the human question

Technical correlation is only part of the investigation. Ask whether the process sequence makes sense for what the user was doing. A technically possible chain may still be behaviourally abnormal.

Preserve uncertainty

If you cannot establish why a process was launched, say that. A defensible finding distinguishes confirmed relationships, suspicious context and assumptions that still require evidence.

Agent Foskett's process timeline

BROWSER normal user-facing application ↓ POWERSHELL encoded command observed ↓ CMD child process created ↓ RUNDLL32 system utility launched ↓ ASSESSMENT The individual binaries can all be legitimate. The combined ancestry, timing and command-line context make the chain worthy of escalation.

The clue wasn't that Windows ran a process. It was who launched whom.

Your evidence board

Evidence	What it supports	Weight
Browser initiates PowerShell	Establishes an unusual parent-child relationship requiring explanation.	Context
PowerShell PID is followed directly	Ties subsequent child processes to the specific execution instance.	Strong
PowerShell launches `cmd.exe`	Extends the execution chain beyond the original command.	Strong
`cmd.exe` launches another system utility	Shows additional process hand-off and execution depth.	Strong
Events occur within seconds	Supports one connected sequence rather than unrelated activity.	Strong
Process filename alone	Does not establish malicious behaviour.	Insufficient alone

Write the finding like an investigator

Example: Microsoft Defender XDR process telemetry on WS-FIN-042 showed a browser initiating the PowerShell process previously identified with an encoded command. PID and initiating-process relationships were used to follow the execution chain, which subsequently included command-shell and system-utility activity within the same narrow time window. None of the individual process names establishes maliciousness by itself; however, the combined parent-child relationships, timing and command-line context did not align with an obvious normal user workflow and warranted further investigation.

Lesson 143 key takeaways

Investigate process ancestry, not just process names.
InitiatingProcessFileName helps identify the parent that created a process.
Process IDs can help follow a specific execution instance when combined with device and time context.
PIDs can be reused, so interpret them with timestamps and device context.
Rapid parent-child execution can reveal one connected attack chain.
Rare process relationships deserve context, but rarity alone does not prove maliciousness.
Common Windows binaries can still participate in suspicious execution chains.
Command-line evidence can explain why a parent-child relationship matters.
Ask whether the reconstructed tree fits a plausible user or administrative workflow.
Document confirmed relationships separately from interpretation and unresolved questions.

Module 12 — the attack chain continues

Lesson 142 decoded the PowerShell command. Lesson 143 reconstructed the process family around it and showed why ancestry can be more revealing than a filename. Next we examine the file evidence and ask whether a newly created file appeared immediately before execution.

Next: Lesson 144 — The File Appeared Seconds Before It Executed.

Continue your KQL investigation training

Module 12 follows endpoint evidence from suspicious execution through process relationships, files, network activity, persistence and spread.

KQL Academy Lesson 142 — The PowerShell Command Was Encoded Defender for Endpoint Academy Agent Foskett Academy

Related Agent Foskett Investigations

Continue applying the investigation mindset to endpoint evidence where process relationships, timing and command-line activity must be interpreted together.

The Timeline Told the Story The Logs Already Knew KQL Threat Hunting Browse Agent Foskett Investigations

🔎 KQL Academy — Module 12: Advanced Endpoint Investigation

Following the attack chain from the first suspicious process to a defensible endpoint compromise assessment.

⬅ Previous lesson

Lesson 142 — The PowerShell Command Was EncodedDecode the clue safely, then test the command's behaviour against endpoint telemetry.

✅ Current lesson

Lesson 143 — The Process Tree Didn't Match Normal User ActivityReconstruct abnormal parent-child execution relationships and determine whether the process tree fits normal user behaviour.

Next lesson

Lesson 144 — The File Appeared Seconds Before It ExecutedCorrelate file creation with process execution and determine where the file came from.

Investigate suspicious process trees with KQL

Lesson 143 of the Agent Foskett KQL Academy uses Microsoft Defender XDR DeviceProcessEvents to reconstruct process ancestry, correlate process IDs and initiating-process relationships, and identify execution chains that do not fit normal user activity.

Reconstruct endpoint process relationships in Microsoft Defender XDR

Learn how to turn process-event rows into an investigation timeline, follow suspicious parent-child execution and distinguish contextual clues from evidence that supports escalation.