ACSC Logo
© GEMXIT
GEMXIT Logo
Friday Cyber Briefing • Microsoft Defender XDR • Browser Child Processes • PowerShell

The User Closed The Browser... The Process Didn't

The user finished browsing.

They closed Chrome. They went back to work. The browser disappeared from the screen.

But one child process did not disappear.

PowerShell kept running.

The visible application was gone, but the attack chain was still alive inside Microsoft Defender XDR telemetry.

Discuss Microsoft security Back to briefings
Agent Foskett Microsoft Defender XDR browser PowerShell child process investigation
Browser Child Process Investigation

The browser closed. The user relaxed. But PowerShell continued running, connected outbound and started a chain of endpoint activity that needed investigation.

Follow the process tree
Review browser-spawned PowerShell
Correlate process, network and persistence

The browser was gone. The process was not.

The investigation did not begin with ransomware, a named malware family or a critical incident. It began with a process that survived longer than the user expected.
09:18 — Website opened The user visited a website. Nothing obvious happened on screen, and the browser appeared to behave normally.
09:19 — PowerShell launched Microsoft Defender XDR showed the browser spawning PowerShell. That parent-child relationship changed the investigation.
09:20 — Browser closed The user closed the browser window, but the child process continued running in the background.

Why this matters

Attackers do not always need the original application to remain open. Once the process chain moves into PowerShell, script hosts, LOLBins or persistence mechanisms, the browser may only be the launch pad.
The visible app is not the full story Users judge what they can see. Investigators judge what the process tree shows.
Child processes can outlive parents A browser closing on screen does not prove that everything it launched has stopped.
Trusted tools can carry the attack PowerShell, CMD, mshta.exe, regsvr32.exe and schtasks.exe may all appear in normal environments, but context matters.

Find browsers spawning PowerShell

Start with browser parent processes launching PowerShell. This relationship deserves context even when both executables are trusted Windows or browser components.
find-browser-spawned-powershell.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe", "iexplore.exe")
| where FileName in~ ("powershell.exe", "pwsh.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

Follow what PowerShell launched next

Once PowerShell appears, look for child processes. The next process may explain whether the activity was a script, a download, a LOLBin handoff or persistence setup.
follow-powershell-children.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessCommandLine, FileName, ProcessCommandLine
| order by Timestamp asc

Check whether PowerShell connected anywhere

Network telemetry can show whether the surviving PowerShell process reached out to a remote URL or IP after the browser was closed.
powershell-network-connections.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| project Timestamp, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessCommandLine
| order by Timestamp desc

Look for persistence after the browser chain

If the child process survived the browser, check whether persistence followed. Scheduled Tasks, registry commands and LOLBins may appear later in the same timeline.
persistence-after-browser-chain.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("schtasks.exe", "reg.exe", "regsvr32.exe", "mshta.exe", "rundll32.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

What the investigation revealed

The important clue was not only that the browser spawned PowerShell. It was what happened after the browser closed.
The process chain continued PowerShell remained active after the browser was gone, which meant the user interface no longer reflected the real endpoint activity.
The network activity followed The device connected externally after the suspicious child process appeared, making the command line and remote destination critical evidence.
Persistence appeared later The timeline eventually showed activity consistent with persistence. The browser was not the end of the attack. It was the beginning.

Investigation lessons

This is why analysts should investigate relationships, not just filenames.
Do not stop at the browser A browser process may only be the entry point. Investigate what it launched and whether that activity continued.
Do not trust the screen What the user sees is not the same as what the endpoint is doing. Defender telemetry gives the deeper view.
Build the timeline Sequence matters: website visit, browser child process, PowerShell, network activity, file writes and persistence.

Related Agent Foskett investigations

This briefing extends the browser-to-PowerShell story into surviving child processes, endpoint timelines and post-browser attacker activity.
The Browser Spawned PowerShellThe parent-child relationship that started the investigation.
The Child Process Shouldn't Have ExistedUnexpected child processes can change the entire incident story.
Nothing Flagged The PowerShell DownloadWhy no alert does not mean no activity.
The Scheduled Task Was Created At 2:41AMPersistence hidden inside legitimate Windows automation.
Mshta.exe Wasn't The Real ProblemA LOLBin investigation where the process tree mattered.
The Process Tree Told The Real StoryUse endpoint process relationships to reconstruct what really happened.
The browser closing was not the end.
Follow the child process, review the command line and build the timeline across process and network telemetry.
Visit the Academy

Final thought

The browser was trusted. The user was trusted. PowerShell was trusted. The relationship between them was not.
The Logs Already Knew. The evidence was not missing. It was sitting in the process tree, waiting for someone to ask why PowerShell was still running.
The process outlived the window Closing an application does not always close the investigation. Child processes may continue quietly in the background.
The timeline changed everything The website visit, browser process, PowerShell command, network connection and persistence activity only made sense together.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The User Closed The Browser... The Process Didn't

This Agent Foskett Friday Cyber Briefing explains how browser-spawned child processes can continue after a user closes the browser and how analysts can investigate the activity in Microsoft Defender XDR.

Microsoft Defender XDR Browser PowerShell Investigation

Security analysts can use KQL across DeviceProcessEvents and DeviceNetworkEvents to investigate browsers spawning PowerShell, child processes that outlive the parent, suspicious command lines, remote connections and endpoint timelines.

GEMXIT KQL Threat Hunting And Process Tree Investigation

GEMXIT helps organisations understand Microsoft Defender XDR, Microsoft Sentinel, Entra ID, endpoint telemetry, KQL threat hunting, process tree investigation, browser-spawned PowerShell and practical cyber security investigations.