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

Lesson 31 — The Browser Spawned PowerShell

The alert did not say malware.

It showed a browser process launching PowerShell.

PowerShell is a legitimate administration tool, so its presence alone proves very little. The process relationship was the clue: why did a web browser need to start a command shell?

Agent Foskett followed the parent process, command line and subsequent endpoint activity before deciding what the event meant.

A suspicious process name is useful. A suspicious parent-child relationship can tell you how execution actually began.

Follow the Process Chain Back to SOC Analyst Academy

Agent Foskett investigating a browser spawning PowerShell in Microsoft Defender XDR

The parent process changed the story

PowerShell may be completely legitimate. The investigation begins when its execution context does not match normal user or administrative activity.

✓ Identify parent and child processes

✓ Inspect the PowerShell command line

✓ Reconstruct nearby process activity

✓ Follow file and network evidence

Case briefing

10:14:22 — USER BROWSING msedge.exe ↓ 10:14:27 powershell.exe DEVICE WS-FIN-044 USER alex.wilson COMMAND LINE powershell.exe -NoProfile -WindowStyle Hidden ... THE EASY VIEW "PowerShell is legitimate." THE SOC VIEW "Why did the browser launch it?"

Investigation objective

Determine why the browser spawned PowerShell, what command executed, whether the activity had a legitimate explanation and what the PowerShell process did next.

Investigator's rule

Never judge a process only by its filename. Parent process, command line, user, device, timing and follow-on behaviour determine the meaning of execution.

Stage 1 — why the relationship matters

Observation	What it tells the analyst
powershell.exe exists	Very little — it is a normal Windows component.
powershell.exe executed	Requires context.
msedge.exe spawned powershell.exe	Unusual execution relationship worth investigating.
PowerShell used hidden execution	Adds another suspicious characteristic.
PowerShell created files or contacted an external host	Provides evidence for the next stage of the attack chain.

Process ancestry explains execution

A PowerShell session launched from Windows Terminal tells a different story from PowerShell launched directly by a browser. Parent-child relationships help explain how execution started.

Unusual does not mean malicious

A browser-to-PowerShell relationship is a reason to investigate, not a verdict. Validate the user action, application behaviour and surrounding endpoint telemetry.

Stage 2 — find browser-to-PowerShell execution

1234 5678910 1112131415161718

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
    "msedge.exe",
    "chrome.exe",
    "firefox.exe"
)
| project Timestamp,
          DeviceName,
          AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          FileName,
          ProcessCommandLine,
          SHA1
| order by Timestamp desc

Keep the command line

The filename tells you what ran. ProcessCommandLine can reveal what PowerShell was instructed to do and often provides the next investigative pivot.

Keep the parent command line too

InitiatingProcessCommandLine can provide additional context about the browser instance and the activity immediately before PowerShell launched.

Stage 3 — read the command as evidence

powershell.exe ↓ -NoProfile ↓ -WindowStyle Hidden ↓ SCRIPT / COMMAND CONTENT ↓ URL / PATH / ENCODED DATA? ↓ WHAT WAS POWERSHELL ASKED TO DO?

Flags are context, not proof

Hidden execution and profile suppression can be used legitimately. Their importance increases when they appear in an already unusual process chain.

Extract pivots

Record URLs, filenames, folder paths, hashes, script names and other processes referenced by the command. Each can become a justified next step.

Stage 4 — reconstruct the device 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:20:00);
DeviceProcessEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (StartTime .. EndTime)
| project Timestamp,
          AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          FileName,
          ProcessCommandLine,
          ProcessId,
          InitiatingProcessId,
          SHA1
| order by Timestamp asc

Look before the alert

The event that triggered detection may not be the beginning. Review the minutes before PowerShell started to understand what the browser and user were doing.

Look after the alert

If PowerShell launches another process, that child becomes the next pivot. The investigation follows the evidence forward through the execution chain.

Stage 5 — correlate file activity

12345 6789101112 13141516

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

A new file may explain the next stage

A script, executable or archive created by PowerShell can provide a path and hash for wider hunting and may explain what executes next.

No file does not mean no attack

Not every execution chain writes a payload to disk. Follow the telemetry you have rather than assuming a missing file event clears the activity.

Stage 6 — correlate network activity

12345 67891011 1213141516

DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ "WS-FIN-044"
| where InitiatingProcessFileName in~ (
    "powershell.exe",
    "pwsh.exe"
)
| project Timestamp,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          Protocol,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Execution plus outbound traffic changes the picture

A PowerShell process contacting an external destination immediately after browser-launched execution creates a stronger sequence than either event considered alone.

Reputation is supporting context

Investigate destination ownership, prevalence and purpose. An unfamiliar or rare destination is not automatically malicious.

Stage 7 — test competing explanations

BROWSER → POWERSHELL ↓ EXPECTED USER / ADMIN ACTION? │ ├── YES → VALIDATE PURPOSE │ └── NO / UNCLEAR ↓ EXPECTED APPLICATION BEHAVIOUR? │ ├── YES → VALIDATE BASELINE │ └── NO / UNCLEAR ↓ SUSPICIOUS COMMAND LINE? ↓ FILE / NETWORK / CHILD PROCESS ACTIVITY? ↓ SUSPECTED ENDPOINT COMPROMISE?

User context helps

Ask whether the user clicked a link, opened a download or knowingly ran a script. Treat the answer as another piece of evidence and validate it against telemetry.

Baseline the relationship

Search for similar browser-to-PowerShell activity on the same device and across comparable endpoints. Prevalence can help distinguish established business behaviour from a new anomaly.

Stage 8 — make the SOC decision

BROWSER SPAWNED POWERSHELL ↓ INSPECT COMMAND LINE ↓ RECONSTRUCT PROCESS ANCESTRY ↓ FOLLOW CHILD PROCESSES ↓ CHECK FILE ACTIVITY ↓ CHECK NETWORK ACTIVITY ↓ VALIDATE USER + BUSINESS CONTEXT ↓ COMPARE WITH BASELINE ↓ CLOSE / CONTINUE / ESCALATE / CONTAIN

The clue was not simply PowerShell. The clue was the relationship between the browser, the command and everything that happened next.

Write the investigation finding

ENDPOINT TRIAGE FINDING On WS-FIN-044, msedge.exe spawned powershell.exe at 10:14:27. The PowerShell command used hidden execution and did not match the user's normal activity. Endpoint telemetry showed follow-on file and network activity associated with the same execution chain. No validated business explanation was found. DECISION Continue investigation and escalate as a suspected endpoint compromise. REASON The unusual browser-to-PowerShell relationship, command-line behaviour and correlated endpoint activity form a suspicious execution chain.

Lesson 31 key takeaways

PowerShell is legitimate; execution context determines investigative significance.
Parent-child relationships can reveal how suspicious execution began.
Browser-to-shell execution deserves investigation but is not proof of compromise.
Preserve both process and initiating-process command lines.
Reconstruct activity before and after the detection.
Follow child processes when the evidence supports the pivot.
Correlate process activity with file and network telemetry.
Validate user and business context against endpoint evidence.
Compare unusual behaviour with historical prevalence and baseline activity.
Make the decision from the complete execution chain rather than one event.

Module 4 — Endpoint Incidents: Following the Attack Chain

Lesson 31 begins the endpoint investigation path by showing how one unusual process relationship can become the first clue in a larger attack chain.

Next: Lesson 32 — The PowerShell Command Was Encoded

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 files, network activity, persistence, credential access and movement.

← Previous lesson

Lesson 30 — From Suspicious Sign-In to Identity Compromise Bring the complete Module 3 identity investigation workflow together.

✅ Current lesson

Lesson 31 — The Browser Spawned PowerShell Follow an unusual browser-to-PowerShell process chain.

Next lesson

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

How to investigate a browser spawning PowerShell in Microsoft Defender XDR

Lesson 31 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate suspicious browser-to-PowerShell execution using DeviceProcessEvents, process ancestry, command-line evidence and endpoint context.

KQL investigation using DeviceProcessEvents, DeviceFileEvents and DeviceNetworkEvents

Learn how SOC analysts use Microsoft Defender XDR advanced hunting to correlate suspicious PowerShell execution with process, file and network activity and follow an endpoint attack chain.