ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Microsoft Defender XDR • DeviceProcessEvents • Endpoint Investigation

The Browser Spawned PowerShell

The browser wasn't supposed to launch PowerShell.

Users browse websites. Browsers render pages. PowerShell automates administrative tasks.

The two rarely belong together.

Yet buried inside Microsoft Defender XDR telemetry was a process chain that connected them.

Discuss your environment Back to briefings
Agent Foskett investigation into a browser spawning PowerShell in Microsoft Defender XDR
Briefing summary

A browser process launched PowerShell on a workstation that otherwise looked healthy. Agent Foskett followed the parent-child process relationship, reviewed the command line and used Defender XDR telemetry to determine why trusted applications were suddenly connected.

Browser parent process
PowerShell child process
Command-line investigation

What happened

The endpoint looked normal until the process relationship was reviewed.
The browser was trusted Chrome, Edge or another browser can appear completely normal in isolation. Users browse the web every day, so the parent process did not immediately look suspicious.
PowerShell was trusted PowerShell is a legitimate Windows administration tool. Its presence alone does not prove malicious activity.
The combination was wrong The investigation changed when the browser appeared as the initiating process for PowerShell. That relationship deserved attention.

The query that found the relationship

The investigation started by looking for PowerShell processes launched by browsers.
browser-spawned-powershell.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe")
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          ProcessCommandLine
| order by Timestamp desc
The parent mattered The browser was not just open. It was the initiating process that caused PowerShell to run.
The command line mattered The ProcessCommandLine showed whether PowerShell was running a normal script, bypassing policy or executing encoded content.
The timing mattered The event needed to be compared with downloads, web activity, network connections and user activity around the same time.

Why a browser launching PowerShell matters

A browser-to-PowerShell chain can point to several different investigation paths.
A malicious site may be involved The user may have visited a page that attempted to trigger script execution, exploit behaviour or social engineering.
A download may have executed A file downloaded from the browser may have launched PowerShell after the user opened it or after another process executed it.
A fake verification prompt may be involved Fake CAPTCHA and verification pages often pressure users into copying and running commands that launch PowerShell manually.
The browser was not the whole story The browser may simply be the starting point. The real evidence appears when the process chain, command line and network activity are connected.
PowerShell was not automatically malicious PowerShell is common in administration. The question is why it ran, who launched it and what command was passed.
The chain changed the context A browser process and a PowerShell process are normal separately. Together, they can become investigation evidence.

Agent Foskett moment

The process names were trusted. The relationship was not.
The browser looked normal A browser process does not usually create concern by itself. It belongs on almost every workstation.
PowerShell looked normal PowerShell exists on Windows and is used by administrators, deployment tools and legitimate scripts.
The process chain did not When a browser spawned PowerShell, the investigation moved from individual process names to behavioural evidence.

What most environments miss

Many teams search for malware names. This kind of signal lives in parent-child process relationships.
Parent processes are evidence The initiating process can explain whether PowerShell was launched by an admin tool, a document, a browser or something unexpected.
Command lines reveal intent The command line may show ExecutionPolicy bypasses, encoded commands, downloaded scripts or suspicious parameters.
Network activity confirms direction DeviceNetworkEvents can show whether PowerShell or its child process reached out to external infrastructure after execution.

How defenders can investigate it

The goal is not to panic because PowerShell ran. The goal is to prove whether the chain belongs.
Review browser-spawned children Search for PowerShell, cmd, wscript, cscript, mshta and rundll32 launched by common browsers.
Inspect ProcessCommandLine Look for encoded commands, bypass flags, web requests, download cradles, temporary paths and strange script content.
Rebuild the timeline Correlate process execution with downloads, URL clicks, network connections, file writes and user activity.

Related investigations

The Child Process Shouldn't Have Existed A trusted parent application launched a child process that changed the investigation. Read more →
The Process Tree Told The Real Story Parent-child relationships inside DeviceProcessEvents revealed the behaviour that alerts did not explain. Read more →
The PowerShell Command Was Base64 Encoded A long encoded command looked meaningless until the PowerShell activity was decoded and placed in context. Read more →
The EncodedCommand Was Buried In Noise A suspicious EncodedCommand was present the whole time, hidden inside routine endpoint activity. Read more →
The Device Was Talking To Something It Shouldn't Network telemetry revealed suspicious outbound communication that process names alone could not explain. Read more →
Investigating DeviceProcessEvents In Microsoft Defender XDR Learn how DeviceProcessEvents can reveal process execution, command lines and parent-child process relationships. Read more →
The browser looked trusted.
PowerShell looked trusted. The process chain did not.
Contact GEMXIT

Final thought

A trusted process name is not the same as trusted behaviour.
At GEMXIT We help organisations investigate Microsoft Defender XDR telemetry, endpoint execution chains, PowerShell activity, suspicious process relationships and Microsoft security signals across real environments. If you want to understand how this applies to your environment, see our Cyber Security services.
Agent Foskett mindset Do not only ask whether PowerShell ran. Ask who launched it, what command was passed, what happened next and whether that process relationship belongs.

The browser looked trusted. PowerShell looked trusted. But when the browser spawned PowerShell, the relationship became the evidence. Explore related investigations including The Child Process Shouldn't Have Existed, The Process Tree Told The Real Story, and The EncodedCommand Was Buried In Noise.

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Browser Spawned PowerShell Investigation

This Agent Foskett briefing explains how browser-spawned PowerShell activity can reveal suspicious endpoint behaviour inside Microsoft Defender XDR.

DeviceProcessEvents Parent Child Process Analysis

Microsoft Defender XDR DeviceProcessEvents can help defenders investigate parent-child process relationships, browser-initiated PowerShell execution, command lines and suspicious endpoint timelines.

PowerShell Execution From Browsers

Browsers launching PowerShell may indicate malicious downloads, fake CAPTCHA social engineering, exploit behaviour or suspicious command execution that requires deeper investigation.