Agent Foskett Academy • SOC Analyst Academy • Module 4 • Lesson 33 • Endpoint Incidents: Following the Attack Chain

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

Every process in the alert had a familiar name.

The problem was the order in which they appeared.

A browser launched PowerShell. PowerShell launched another Windows utility. That utility then started a process the user had never knowingly opened.

Agent Foskett stopped looking at the filenames individually.

The process tree was the evidence.

Legitimate processes can form an illegitimate execution chain. Investigate the relationships, not just the names.

Reconstruct the Process Tree Back to SOC Analyst Academy

Agent Foskett investigating an abnormal process tree in Microsoft Defender XDR

The names looked normal

The ancestry did not. Process relationships can expose suspicious execution even when every individual binary is legitimate.

✓ Identify parent-child relationships

✓ Reconstruct process ancestry

✓ Compare with expected user behaviour

✓ Follow suspicious descendants

Case briefing

DEVICE: WS-FIN-044 msedge.exe ↓ powershell.exe ↓ rundll32.exe ↓ regsvr32.exe ALL FOUR PROCESS NAMES ARE LEGITIMATE. THE QUESTION Why did this user activity produce this particular execution chain?

Investigation objective

Reconstruct the process ancestry, determine whether the parent-child relationships are expected, identify the initiating user context and follow suspicious descendants through the endpoint timeline.

Investigator's rule

A legitimate binary does not make a legitimate process tree. Attackers frequently use trusted operating-system tools inside abnormal execution chains.

Stage 1 — stop reading processes as isolated events

Isolated observation	Process-tree observation
msedge.exe ran	msedge.exe initiated PowerShell.
powershell.exe ran	PowerShell was a child of the browser.
rundll32.exe ran	rundll32.exe was launched by the suspicious PowerShell process.
regsvr32.exe ran	regsvr32.exe appeared deeper in the same execution chain.

Process ancestry provides causality clues

Parent-child relationships help explain how one execution led to another. They do not prove intent, but they give the analyst a defensible sequence to investigate.

Expected relationships matter too

Normal user activity creates repeatable patterns. Comparing a suspicious chain with known-good behaviour can reveal where the execution path diverged.

Stage 2 — retrieve the device process timeline

12345 6789101112 1314151617

let TargetDevice = "WS-FIN-044";
let StartTime = datetime(2026-08-24 10:10:00);
let EndTime   = datetime(2026-08-24 10:25:00);
DeviceProcessEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (StartTime .. EndTime)
| project Timestamp,
          AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessId,
          FileName,
          ProcessCommandLine,
          ProcessId,
          SHA1
| order by Timestamp asc

Why keep process IDs?

ProcessId and InitiatingProcessId help the analyst distinguish multiple instances of the same executable and understand which process launched which child.

Time ordering is essential

Sort the activity chronologically. A process tree becomes much easier to reason about when you can see the execution sequence unfold.

Stage 3 — map the suspicious chain

10:14:22 msedge.exe PID 4480 │ └── 10:14:27 powershell.exe PID 6224 │ └── 10:14:31 rundll32.exe PID 6908 │ └── 10:14:34 regsvr32.exe PID 7112 QUESTION AT EACH STEP What caused this child process to exist?

Do not infer missing relationships

If telemetry does not establish a parent-child relationship, record that uncertainty. A defensible process tree contains observed relationships, not convenient assumptions.

Preserve command lines

The command line may explain why a legitimate utility was invoked. Arguments, paths, URLs and script content can turn a vague process relationship into a useful investigative lead.

Stage 4 — focus on suspicious descendants

12345 6789101112 13141516

DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ "WS-FIN-044"
| where InitiatingProcessFileName in~ (
    "powershell.exe",
    "rundll32.exe",
    "regsvr32.exe"
)
| project Timestamp,
          AccountName,
          InitiatingProcessFileName,
          FileName,
          ProcessCommandLine,
          SHA1
| order by Timestamp asc

Follow justified pivots

Each suspicious descendant can expose the next stage of execution. Follow the process when its relationship, command line or timing gives you a reason to do so.

Avoid process-name tunnel vision

Do not create a fixed list of “bad” Windows binaries and assume everything else is safe. The same executable can be benign in one process tree and highly suspicious in another.

Stage 5 — compare with normal user activity

12345678

DeviceProcessEvents
| where Timestamp > ago(14d)
| where AccountName =~ "alex.wilson"
| summarize Executions=count()
    by InitiatingProcessFileName,
       FileName
| order by Executions desc

Baseline the relationship

The useful question is not merely whether a process is common. Ask whether this parent-child combination is normal for this user, device or peer group.

Rare does not equal malicious

A relationship that has never appeared before deserves attention, but rarity is still only context. Continue validating the command and subsequent behaviour.

Stage 6 — correlate the tree with file activity

12345 67891011 12131415

DeviceFileEvents
| where Timestamp > ago(24h)
| where DeviceName =~ "WS-FIN-044"
| where InitiatingProcessFileName in~ (
    "powershell.exe",
    "rundll32.exe",
    "regsvr32.exe"
)
| project Timestamp,
          ActionType,
          FileName,
          FolderPath,
          SHA1,
          InitiatingProcessFileName
| order by Timestamp asc

The tree may explain a new file

If one of the suspicious processes creates or modifies a file, that event can connect execution ancestry to the next stage of the incident.

Record exact timestamps

Seconds matter during endpoint reconstruction. A file created immediately before execution can be much more meaningful than the same file appearing hours earlier.

Stage 7 — test the story

PROCESS TREE LOOKS UNUSUAL ↓ ARE THE RELATIONSHIPS OBSERVED? ↓ DO COMMAND LINES EXPLAIN THEM? ↓ IS THE CHAIN NORMAL FOR THIS USER? ↓ IS IT NORMAL FOR THIS DEVICE? ↓ DID DESCENDANTS CREATE FILES? ↓ DID THEY CREATE NETWORK ACTIVITY? ↓ IS THERE A LEGITIMATE BUSINESS EXPLANATION? ↓ MAKE THE SOC DECISION

Ask what would disprove your theory

If you believe the tree represents malicious execution, actively look for evidence of legitimate software, automation or user activity that could explain it.

Keep facts separate from interpretation

“PowerShell launched rundll32.exe” is an observation. “The attacker used rundll32.exe” is an interpretation that requires supporting evidence.

Stage 8 — write the process-tree finding

ENDPOINT INVESTIGATION FINDING DeviceProcessEvents showed the following execution sequence on WS-FIN-044: msedge.exe → powershell.exe → rundll32.exe → regsvr32.exe The parent-child relationships were not observed in the user's 14-day process baseline. Command-line and follow-on file activity did not provide a validated business explanation. DECISION Continue the endpoint investigation and escalate the execution chain as suspicious. REASON The individual binaries are legitimate, but their observed ancestry and surrounding activity do not match expected user behaviour.

Lesson 33 key takeaways

Legitimate process names can appear inside suspicious execution chains.
Parent-child relationships are often more informative than filenames alone.
Use process IDs and timestamps to help reconstruct execution accurately.
Preserve command lines for both parent and child processes.
Follow suspicious descendants when the evidence justifies the pivot.
Compare parent-child combinations with normal user and device activity.
Rarity is investigative context, not proof of maliciousness.
Correlate process ancestry with file and network telemetry.
Do not invent relationships that the available evidence does not establish.
Separate observed facts from conclusions in the investigation record.

Module 4 — Endpoint Incidents: Following the Attack Chain

Lesson 33 extends the attack chain from suspicious PowerShell execution into process ancestry. The next lesson follows a file that appears only seconds before it executes.

Next: Lesson 34 — The File Appeared Seconds Before It Executed

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 4: Endpoint Incidents: Following the Attack Chain

Follow endpoint evidence from suspicious execution through process ancestry, files, network activity, persistence, credential access and movement.

← Previous lesson

Lesson 32 — The PowerShell Command Was Encoded Investigate obfuscated or encoded command execution.

✅ Current lesson

Lesson 33 — The Process Tree Didn't Match Normal User Activity Use process ancestry to distinguish normal from suspicious execution.

Next lesson

Lesson 34 — The File Appeared Seconds Before It Executed Correlate file creation with execution.

How to investigate suspicious process trees in Microsoft Defender XDR

Lesson 33 of the Agent Foskett SOC Analyst Academy teaches analysts how to use DeviceProcessEvents, process IDs, parent-child relationships and command-line evidence to reconstruct abnormal endpoint execution.

KQL process ancestry investigation for SOC analysts

Learn how to compare process relationships with normal user activity, follow suspicious descendants and correlate process ancestry with file activity during Microsoft Defender XDR investigations.