Volexity's latest reporting documents something that should concern every security team, not just those protecting NGOs and civil society: two distinct China-linked threat actors ran the same Chrome/Windows zero-day exploit chain in the wild before Chrome's patch shipped. The campaign began on September 1, 2026, when Volexity detected a spear-phishing operation attributed to a group it tracks as UTA0560 targeting several non-governmental organizations. A second China-linked actor was subsequently observed using the identical exploit chain — but deploying a different payload at the end of it.
This pattern matters for two reasons. First, when two separate espionage groups share an exploit chain, it strongly suggests a common upstream supplier, a shared exploit broker, or intra-state tooling distribution — meaning the barrier to entry for additional actors using this chain has already collapsed. Second, the fact that each group deployed a different implant means your detection strategy cannot rely on payload-specific indicators alone. If you're hunting for one group's malware and the other group's intrusion lands in your environment, signature-based detection will see nothing.
The exploit window is the critical fact: exploitation began before Chrome shipped its fix. Any organization running unpatched Chrome between September 1 and patch deployment — which, given enterprise browser update cadence, is realistically a large population — was exposed. NGOs were the observed victims, but exploit chains of this quality do not stay scoped to one victim class.
Technical Analysis
Affected Platforms
Based on Volexity's reporting, the attack chain spans:
- Google Chrome (and by extension, Chromium-based browsers that had not yet incorporated the upstream fix) on Windows
- The chain required a browser-level compromise followed by a Windows-level component — the classic two-stage structure needed to escape Chrome's sandbox and achieve code execution with user privileges
At the time of this writing, the specific CVE assignment for this chain had not been publicly confirmed in the source reporting. I will not speculate on an identifier. What matters operationally is the architecture of the attack, because that architecture is what you can detect regardless of which bug number eventually gets assigned.
Attack Chain Structure (Defender's View)
Reconstructing from the reported tradecraft, the chain follows the standard modern browser exploit kill chain:
- Delivery — spear-phishing. UTA0560 used targeted social engineering against NGO staff. This almost certainly means a lure URL delivered via email or messaging, pointing to attacker-controlled infrastructure hosting the exploit.
- Initial renderer compromise. The victim visits the lure page in Chrome. The browser-level exploit executes within the renderer process — a deliberately constrained, sandboxed environment.
- Sandbox escape via Windows component. The second stage of the chain targets a Windows OS component to break out of the Chrome sandbox. This is the expensive part of any modern browser exploit, and its presence here confirms a full-chain, high-sophistication capability.
- Payload deployment — divergent implants. Here the two campaigns split. Each group dropped its own unauthorized access mechanism, consistent with separate operators, separate tasking, and separate C2 infrastructure.
Exploitation Status
- Confirmed active in-the-wild exploitation since September 1, 2026
- Exploited before patch availability (true zero-day at time of use)
- Attribution: Two China-nexus espionage actors, one tracked as UTA0560 by Volexity
- Victimology: NGOs / civil society organizations
- Payloads: Two distinct post-exploitation implants (separate per actor)
Given confirmed pre-patch exploitation by nation-state actors, defenders should treat this as a KEV-caliber threat and check CISA's Known Exploited Vulnerabilities catalog for the associated CVE once published, along with Google's Chrome security advisory and Microsoft's corresponding guidance for the Windows component.
Detection & Response
Because the payloads differ between actors, the highest-fidelity detection surface is the exploit chain itself: the anomalous process and memory behaviors that occur when a Chrome renderer escapes the sandbox and spawns attacker tooling. The detections below are built around those behaviors, which generalize across both campaigns — and frankly, across most browser full-chain exploits.
Sigma Rules
These rules focus on the two most reliable behavioral signals: Chrome spawning child processes it should never spawn (the post-exploitation stage), and Windows scripting/system binaries executing from browser-writable locations.
---
title: Chrome Spawning Suspicious Child Processes - Potential Browser Exploit Post-Exploitation
id: 9f2c4a71-3b6e-4d58-a1c7-8e5f2b9d0a34
status: experimental
description: Detects chrome.exe spawning command interpreters, scripting engines, or LOLBins, consistent with post-exploitation behavior following a browser exploit and sandbox escape, as seen in the Chrome/Windows zero-day campaigns reported by Volexity (September 2026).
references:
- https://securityaffairs.com/199104/apt/one-exploit-chain-two-espionage-campaigns-chrome-and-windows-under-fire.html
- https://attack.mitre.org/techniques/T1203/
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.execution
- attack.t1203
- attack.t1059
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\brave.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\wmic.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\schtasks.exe'
- '\regsvcs.exe'
- '\msbuild.exe'
filter_extension_helper:
CommandLine|contains:
- '--type='
condition: selection_parent and selection_child and not filter_extension_helper
falsepositives:
- Rare browser-based enterprise tooling; validate against software inventory
- Some browser download handlers invoking scripts (uncommon in hardened environments)
level: high
---
title: Scripting Engine or LOLBin Execution From Browser Cache or User Temp Directories
id: 4d8e1b06-7a3f-4c29-b5d1-2f6a9c0e8b47
status: experimental
description: Detects Windows scripting engines and LOLBins executing payloads from browser cache, temp, or user-writable download locations, consistent with staged payload delivery following browser exploitation in targeted espionage campaigns.
references:
- https://securityaffairs.com/199104/apt/one-exploit-chain-two-espionage-campaigns-chrome-and-windows-under-fire.html
- https://attack.mitre.org/techniques/T1059/
- https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.execution
- attack.t1059
- attack.t1105
logsource:
category: process_creation
product: windows
detection:
selection_path:
CommandLine|contains:
- '\AppData\Local\Temp\'
- '\AppData\Local\Google\Chrome\User Data\'
- '\AppData\Local\Microsoft\Edge\User Data\'
- '\Downloads\'
selection_engine:
Image|endswith:
- '\powershell.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
filter_user_downloads_legit:
CommandLine|contains:
- '\Downloads\'
Image|endswith:
- '\certutil.exe'
condition: selection_path and selection_engine and not filter_user_downloads_legit
falsepositives:
- IT deployment scripts run from temp paths; scope to known deployment tooling
- User-initiated script execution from Downloads (rare in standard user populations)
level: medium
---
title: Chrome Renderer Process Anomaly - Renderer Writing Executables or Scripts to Disk
id: 6b1f9d42-8e5c-4a71-93bd-5c2a7f0e1d98
status: experimental
description: Detects file creation events where chrome.exe (potentially a compromised renderer) writes executable or script content to disk outside of normal download flows, a potential indicator of in-browser exploitation staging payloads.
references:
- https://securityaffairs.com/199104/apt/one-exploit-chain-two-espionage-campaigns-chrome-and-windows-under-fire.html
- https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.execution
- attack.t1203
logsource:
category: file_event
product: windows
detection:
selection_source:
Image|endswith: '\chrome.exe'
selection_extension:
TargetFilename|endswith:
- '.exe'
- '.dll'
- '.ps1'
- '.bat'
- '.js'
- '.jse'
- '.vbs'
- '.hta'
- '.scr'
filter_downloads:
TargetFilename|contains: '\Downloads\'
condition: selection_source and selection_extension and not filter_downloads
falsepositives:
- Browser updates and component updates writing binaries (scope to Chrome update paths if needed)
- Web-based enterprise applications saving export files
level: medium
Analyst note on tuning: Rule one is your highest-value detection and should be deployed broadly — legitimate cases of Chrome spawning cmd.exe or powershell.exe are vanishingly rare in mature environments. If you see volume, check for browser management tooling first before concluding the rule is noisy. Rule three will require environment-specific tuning around Chrome's update paths (C:\Program Files\Google\Chrome\Application\ versioned directories) — exclude those if you see update-related noise.
KQL — Microsoft Sentinel / Defender for Endpoint
This hunt looks across a 14-day window for browser processes spawning post-exploitation tooling, joined with outbound network connections from those children — the combined signature of an exploit chain reaching execution and then C2. It works even if you're ingesting non-Windows telemetry via CommonSecurityLog or Syslog, since the first clause uses DeviceProcessEvents from Defender for Endpoint, which is where this threat will be most visible.
// Hunt: Browser exploit chain - Chrome/Edge spawning post-exploitation tooling with network activity
// Relevant to Volexity-reported Chrome/Windows zero-day campaigns (Sept 2026, UTA0560 + second actor)
let Lookback = 14d;
let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "certutil.exe", "bitsadmin.exe", "schtasks.exe"]);
let BrowserSpawn =
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "brave.exe")
| where FileName in~ (SuspiciousChildren)
| where ProcessCommandLine !has "--type="
| project DeviceId, DeviceName, SpawnTime=TimeGenerated, ChildProcess=FileName, ChildCommandLine=ProcessCommandLine, ChildProcessId=ProcessId, AccountName, InitiatingProcessCommandLine;
BrowserSpawn
| join kind=leftouter (
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| project DeviceId, NetTime=TimeGenerated, NetProcess=InitiatingProcessFileName, NetProcessId=InitiatingProcessId, RemoteUrl, RemoteIP, RemotePort
) on $left.DeviceId == $right.DeviceId and $left.ChildProcessId == $right.NetProcessId
| extend HasC2LikeConnection = isnotempty(RemoteIP)
| project DeviceName, AccountName, SpawnTime, ChildProcess, ChildCommandLine, RemoteIP, RemoteUrl, RemotePort, HasC2LikeConnection
| order by SpawnTime desc;
// Secondary hunt: Lure URL click-through via browser process network events to recently seen rare domains
// Tune RareDomainThreshold to your environment; low-prevalence destinations from browsers on NGO-user devices warrant review
let RareDomainThreshold = 5;
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe")
| where isnotempty(RemoteUrl)
| summarize DeviceCount=dcount(DeviceId), Devices=make_set(DeviceName, 10), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by RemoteUrl
| where DeviceCount <= RareDomainThreshold
| order by FirstSeen desc;
The second query is a deliberate prevalence-based hunt: targeted spear-phishing lures are served from infrastructure with near-zero prevalence in your environment. A domain contacted by exactly one device, first seen in the last two weeks, is exactly the kind of signal that surfaces exploit delivery sites. Review these alongside proxy and DNS data if available.
Velociraptor VQL
For DFIR teams validating a suspected compromise, this artifact pulls process lineage for browser-spawned children and cross-references active network connections — useful for live-triage of hosts that may have been exposed during the unpatched window.
-- Hunt: Browser-spawned post-exploitation processes and their network connections
-- Use case: Triage hosts potentially exposed to Chrome/Windows zero-day chain (Volexity, Sept 2026)
LET suspicious_children = '(?i)cmd\.exe|powershell\.exe|pwsh\.exe|wscript\.exe|cscript\.exe|mshta\.exe|rundll32\.exe|regsvr32\.exe|wmic\.exe|certutil\.exe|schtasks\.exe'
LET browser_spawns = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ suspicious_children
AND Ppid IN (
SELECT Pid FROM pslist()
WHERE Name =~ '(?i)chrome\.exe|msedge\.exe|brave\.exe'
)
SELECT Pid,
Name AS SuspiciousProcess,
CommandLine,
Username,
CreateTime,
Exe AS BinaryPath
FROM browser_spawns
-- Companion check: established outbound connections from non-browser processes
-- Run separately to identify implant C2 on suspect hosts
SELECT Pid,
Name,
Status,
Laddr,
Raddr,
CommandLine
FROM netstat()
WHERE Status =~ 'ESTAB'
AND Name !~ '(?i)chrome|msedge|firefox|svchost|teams|outlook|onedrive'
AND Raddr.IP !~ '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.|127\.)'
The second netstat() block is the implant hunt: established outbound connections from non-browser, non-baseline processes to external IPs. On a host where the browser was the entry vector, the implant — whichever group's variant — has to talk home. Baseline your standard application process names into the exclusion regex before running at scale.
Remediation & Verification Script
This PowerShell script verifies Chrome is updated past the vulnerable version, checks for force-installed policy settings that could delay updates, and confirms the browser is actually running the patched build (not just that a newer MSI exists). Adjust $MinimumSafeVersion to the fixed version stated in Google's advisory for this chain once confirmed.
# Verify and enforce Chrome patch state against exploited zero-day chain
# Run as Administrator. Reference: Google Chrome security advisory for Sept 2026 exploited chain.
# IMPORTANT: Set $MinimumSafeVersion to the fixed version from Google's official advisory.
$MinimumSafeVersion = [version]"0.0.0.0" # REPLACE with the fixed build from Google's advisory
# --- Step 1: Detect installed Chrome version ---
$chromePaths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe"
)
$installed = $null
foreach ($p in $chromePaths) {
if (Test-Path $p) {
$installed = (Get-Item $p).VersionInfo.ProductVersion
break
}
}
if (-not $installed) {
Write-Host "[!] Chrome not found in standard paths. Check per-user installs at %LOCALAPPDATA%\Google\Chrome." -ForegroundColor Yellow
} else {
Write-Host "[*] Installed Chrome version: $installed"
if ([version]$installed -lt $MinimumSafeVersion) {
Write-Host "[VULNERABLE] Chrome $installed is below the patched baseline $MinimumSafeVersion." -ForegroundColor Red
} else {
Write-Host "[OK] Chrome meets or exceeds patched baseline." -ForegroundColor Green
}
}
# --- Step 2: Detect per-user Chrome installs (frequently missed by enterprise patching) ---
Get-ChildItem "C:\Users" -Directory -ErrorAction SilentlyContinue | ForEach-Object {
$userChrome = Join-Path $_.FullName "AppData\Local\Google\Chrome\Application\chrome.exe"
if (Test-Path $userChrome) {
$uv = (Get-Item $userChrome).VersionInfo.ProductVersion
Write-Host "[!] Per-user Chrome found for $($_.Name): version $uv" -ForegroundColor Yellow
}
}
# --- Step 3: Check for update-blocking policy settings ---
$policyPath = "HKLM:\SOFTWARE\Policies\Google\Update"
if (Test-Path $policyPath) {
$updateDefault = (Get-ItemProperty $policyPath -Name "UpdateDefault" -ErrorAction SilentlyContinue).UpdateDefault
if ($updateDefault -eq 0) {
Write-Host "[RISK] Google Update is DISABLED by policy (UpdateDefault=0). Chrome cannot self-update." -ForegroundColor Red
}
$autoUpdate = (Get-ItemProperty $policyPath -Name "AutoUpdateCheckPeriodMinutes" -ErrorAction SilentlyContinue).AutoUpdateCheckPeriodMinutes
if ($autoUpdate -eq 0) {
Write-Host "[RISK] Auto-update check period set to 0 (disabled)." -ForegroundColor Red
}
} else {
Write-Host "[*] No update-blocking policies found at $policyPath"
}
# --- Step 4: Check running chrome.exe processes match the patched binary ---
$running = Get-Process chrome -ErrorAction SilentlyContinue | Select-Object -First 1
if ($running) {
$runningVer = $running.MainModule.FileVersionInfo.ProductVersion
Write-Host "[*] Running chrome.exe version: $runningVer (browser must be fully restarted to load patched binaries)"
if ($installed -and ([version]$runningVer -lt $MinimumSafeVersion)) {
Write-Host "[ACTION REQUIRED] Patched binary installed but old version still RUNNING. Force browser restart." -ForegroundColor Yellow
}
}
# --- Step 5: Check for Chrome variations/field-trial kill switch and report relaunch state ---
$relaunch = Get-ItemProperty "HKCU:\Software\Google\Chrome" -Name "RelaunchNotification" -ErrorAction SilentlyContinue
Write-Host "[*] Audit complete. Correlate any VULNERABLE/RISK findings with the process-tree hunts in this post."
Remediation
Immediate (0–72 hours)
- Patch Chrome everywhere — including per-user installs. Push the fixed Chrome build via your software management platform. Do not rely on Chrome's auto-update alone in the first 72 hours: many enterprises have auto-update throttled or users who never restart the browser. The script above detects the dangerous state where the patched binary is installed but an old process is still running.
- Patch Chromium derivatives. Microsoft Edge, Brave, Opera, and any Electron-based applications that embed Chromium inherit the browser-side risk. Verify each vendor has shipped the upstream fix and track them as separate patch items — they ship on different schedules.
- Apply the corresponding Windows patch. Because the chain included a Windows component for sandbox escape, Microsoft's update addressing that component is equally critical. A patched browser with an unpatched OS still leaves the escape viable for other browser bugs. Monitor Microsoft's security update guide and CISA KEV for the relevant entry.
- Hunt retroactively. If your Chrome fleet was unpatched on or after September 1, 2026, run the KQL hunt above across your full retention window. Process creation telemetry for
chrome.exespawning script interpreters is the single highest-fidelity retro hunt available.
Short Term (1–2 weeks)
- Enforce browser update policy. Set Chrome's
RelaunchNotificationPeriodandRelaunchWindowpolicies to force restart within 24–48 hours of an update landing. Zero-day windows are measured in days; a browser that's patched-but-not-restarted is not patched. - Deploy the Sigma rules above to your SIEM and validate them against your environment. Rule one (browser spawning script interpreters) should be a high-priority, low-volume alert — if it's noisy, investigate why your environment legitimately exhibits that behavior.
- Restrict script interpreter access for standard users where operationally feasible (WDAC/AppLocker). This raises the cost of the post-exploitation stage regardless of which implant is dropped.
Strategic
- Recognize the shared-exploit signal. When two state actors share a chain, assume it will proliferate further. NGOs were targeted here, but exploit tooling of this class historically diffuses to broader espionage and eventually criminal use. Treat browser patch latency as a first-class risk metric in your vulnerability management program — measure and report time-to-patch for browsers separately from OS patching.
- For NGO and civil-society clients specifically: China-nexus espionage against this sector is persistent and well-resourced. Prioritize hardware-key MFA, hardened browser configurations, and managed detection coverage. If your organization fits the victim profile in Volexity's reporting, assume targeting and hunt accordingly.
- Track the advisories: Monitor Google Chrome Releases, Microsoft's Security Update Guide, CISA KEV, and Volexity's full report for the CVE assignments and actor IOCs as they are published. Merge Volexity's indicators into your blocking and detection stacks once released.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.