Between September 3 and 4, 2026, defenders observed a Chinese threat actor tracked as UTA0565 conducting live zero-day exploitation against a previously unpatched Chrome–Windows vulnerability chain. The campaign chains two Google Chrome vulnerabilities — CVE-2026-85046 and CVE-2026-87491 — with a Windows Advanced Local Procedure Call (ALPC) flaw, CVE-2026-85880, to escape the browser sandbox, achieve privilege escalation on the host, and deploy a malware family identified as CLEANGLUP. Initial access is driven through fake websites engineered to lure targets into rendering attacker-controlled content in Chrome.
This is the attack pattern that keeps experienced IR teams up at night: a drive-by browser exploit with no user interaction required beyond visiting a page, a sandbox escape, a local privilege escalation, and a persistent implant — all before the vendor patch cycle has caught up. If your organization runs Chrome on Windows endpoints (and statistically, it does), treat this as an active, unpatched exposure until Google and Microsoft ship fixes and those fixes are deployed. This post breaks down the chain from a defender's perspective and provides detection content, hunt queries, and hardening guidance you can operationalize today.
Technical Analysis
Affected Products and Platforms
- Google Chrome on Windows — vulnerable builds prior to the emergency patch addressing CVE-2026-85046 and CVE-2026-87491. Because exploitation was observed before disclosure and patching, assume all Chrome versions in circulation on September 3–4, 2026 were exploitable. Verify your deployed build against Google's stable channel update advisory.
- Microsoft Windows — the Advanced Local Procedure Call (ALPC) facility, a core inter-process communication mechanism in the Windows kernel, is affected by CVE-2026-85880. ALPC flaws historically permit local privilege escalation from a low-integrity or sandboxed context to SYSTEM — exactly what a sandbox-escape chain needs.
The Attack Chain
From a defender's vantage point, the chain unfolds in three observable stages:
- Initial access via fake websites (social engineering + drive-by). Victims are lured to convincing lookalike sites. Merely loading the malicious page in Chrome triggers the exploit — no download consent, no macro, no attachment.
- Renderer compromise and sandbox escape (CVE-2026-85046, CVE-2026-87491). The two Chrome vulnerabilities are chained: the first compromises the renderer process, and the second breaks out of the Chrome sandbox. This is the critical pivot — sandbox escapes are rare and expensive, which is why nation-state actors reserve them for high-value targeting. The observable artifact on the endpoint is chrome.exe spawning unexpected child processes, which should never happen in normal operation outside of the browser's own utility/renderer process model.
- Privilege escalation and implant deployment (CVE-2026-85880 → CLEANGLUP). Once outside the sandbox, the attacker exploits the Windows ALPC vulnerability to elevate privileges, then drops and executes the CLEANGLUP payload. Expect the payload staging to involve living-off-the-land binaries (LOLBins) such as rundll32.exe or regsvr32.exe, writes to user-writable or program data directories, and establishment of persistence.
Exploitation Status
- Confirmed active in-the-wild exploitation as zero-days — detected September 3–4, 2026, before patches were available.
- Attributed to UTA0565, a Chinese state-aligned threat actor.
- At the time of initial reporting, the vulnerabilities were unpatched; defenders should monitor CISA's Known Exploited Vulnerabilities (KEV) catalog for these CVEs, as confirmed zero-day exploitation almost invariably results in KEV inclusion with aggressive federal remediation deadlines (typically 14–21 days for browser bugs).
The takeaway: this is not theoretical. Every day an endpoint remains unpatched and unhardened, it is one malicious ad, one watering hole, or one convincing phishing lure away from full host compromise with SYSTEM-level access.
Detection & Response
The most reliable detection opportunity in this chain is the sandbox escape pivot: chrome.exe — particularly a renderer process — spawning child processes is a high-fidelity anomaly. Secondary opportunities include suspicious child processes of Chrome executing LOLBins, and payload staging in anomalous directories. The detections below are tuned for fidelity over volume.
Sigma Rules
---
title: Chrome Process Spawning Unexpected Child Process - Potential Sandbox Escape
id: 3f8a1c42-9b7e-4d21-a6f5-2c1e8d9b4a07
status: experimental
description: Detects chrome.exe spawning command interpreters, script hosts, or LOLBins, consistent with post-exploitation activity following a Chrome sandbox escape such as the UTA0565 CVE-2026-85046/CVE-2026-87491 chain.
references:
- https://thehackernews.com/2026/09/chinese-hackers-exploit-chrome-windows.html
- https://attack.mitre.org/techniques/T1203/
- https://attack.mitre.org/techniques/T1211/
author: Security Arsenal
date: 2026/09/10
tags:
- attack.exploitation_for_client_execution
- attack.t1203
- attack.t1211
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\chrome.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\msiexec.exe'
- '\wmic.exe'
- '\schtasks.exe'
- '\whoami.exe'
- '\net.exe'
- '\nltest.exe'
filter_renderer_flag:
CommandLine|contains:
- '--type=renderer'
- '--type=utility'
- '--type=gpu-process'
condition: selection_parent and selection_child and not filter_renderer_flag
falsepositives:
- Rare - legitimate Chrome-integrated enterprise extensions or debugging workflows
level: high
---
title: Executable Dropped by Chrome Process Outside Download Directory
id: 8c2d5f91-4a3b-4e67-b9d1-7f0a3c6e5b28
status: experimental
description: Detects chrome.exe writing executable or script files to non-standard locations such as ProgramData or AppData subdirectories, consistent with CLEANGLUP payload staging after sandbox escape.
references:
- https://thehackernews.com/2026/09/chinese-hackers-exploit-chrome-windows.html
- https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/09/10
tags:
- attack.command_and_control
- attack.t1105
logsource:
category: file_event
product: windows
detection:
selection_image:
Image|endswith: '\chrome.exe'
selection_extension:
TargetFilename|endswith:
- '.exe'
- '.dll'
- '.bat'
- '.ps1'
- '.js'
- '.vbs'
selection_path:
TargetFilename|contains:
- '\ProgramData\'
- '\AppData\Local\Temp\'
- '\AppData\Roaming\'
- '\Users\Public\'
filter_downloads:
TargetFilename|contains: '\Downloads\'
condition: selection_image and selection_extension and selection_path and not filter_downloads
falsepositives:
- Chrome component updates writing to user profile directories (tune by path hash allowlist after baseline)
level: medium
KQL (Microsoft Sentinel / Defender)
// Hunt: Chrome spawning suspicious child processes (UTA0565 sandbox escape behavior)
// Tables: DeviceProcessEvents (Defender XDR) — also works via Sentinel ingestion
let suspiciousChildren = dynamic([
"cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe",
"mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe",
"msiexec.exe", "wmic.exe", "schtasks.exe", "whoami.exe", "net.exe", "nltest.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "chrome.exe"
| where FileName in~ (suspiciousChildren)
// Exclude Chrome's own internal process types from the child command line
| where ProcessCommandLine !has_any ("--type=renderer", "--type=utility", "--type=gpu-process")
| project TimeGenerated, DeviceName, AccountName,
InitiatingProcessCommandLine, FileName, ProcessCommandLine,
SHA256, ReportId
| sort by TimeGenerated desc;
// Hunt: Network connections originating from non-browser child processes of chrome.exe
// Useful for catching CLEANGLUP C2 beaconing post-exploitation
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "chrome.exe" == false
| join kind=inner (
DeviceProcessEvents
| where InitiatingProcessFileName =~ "chrome.exe"
| where FileName !in~ ("chrome.exe")
| project DeviceName, FileName, ProcessId, ProcessCreationTime=TimeGenerated
) on DeviceName, FileName
| project TimeGenerated, DeviceName, FileName, RemoteIP, RemoteUrl, RemotePort, InitiatingProcessCommandLine
| sort by TimeGenerated desc;
Velociraptor VQL
-- Hunt for suspicious child processes of chrome.exe indicative of sandbox escape
-- Deploy as a hunt across Windows endpoints; pairs well with process ancestry enrichment
SELECT Pid,
Ppid,
Name,
Exe,
CommandLine,
Username,
CreateTime,
get(field='Exe') AS ExecutablePath
FROM pslist()
WHERE CommandLine =~ '(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|certutil|bitsadmin|schtasks|whoami)'
AND Ppid IN (
SELECT Pid FROM pslist()
WHERE Name =~ 'chrome'
)
-- Complementary hunt: recently created executables in staging directories used by CLEANGLUP-style implants
SELECT FullPath,
Size,
Mtime,
Ctime
FROM glob(globs=['C:/ProgramData/**/*.exe',
'C:/Users/*/AppData/Local/Temp/*.exe',
'C:/Users/*/AppData/Roaming/*/*.exe',
'C:/Users/Public/*.exe'])
WHERE Ctime > now() - 1209600 -- created within last 14 days
Remediation & Verification Script
# UTA0565 Chrome-Windows Zero-Day Chain: Verification and Hardening Script
# Run elevated on Windows endpoints. Validates Chrome version, pending Windows updates,
# and applies interim hardening while patches roll out.
# --- 1. Check installed Chrome version ---
$chromePaths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)
$chromeFound = $false
foreach ($path in $chromePaths) {
if (Test-Path $path) {
$chromeFound = $true
$version = (Get-Item $path).VersionInfo.ProductVersion
Write-Host "[+] Chrome found at $path - Version: $version"
Write-Host "[!] ACTION: Compare against Google's stable channel advisory for CVE-2026-85046 / CVE-2026-87491 and update via Chrome Enterprise or forced relaunch if below the fixed build."
}
}
if (-not $chromeFound) { Write-Host "[-] Chrome not detected in standard install paths." }
# --- 2. Check for pending Windows cumulative updates (covers CVE-2026-85880 ALPC fix) ---
Write-Host "`n[+] Checking Windows Update status..."
try {
$updateSession = New-Object -ComObject Microsoft.Update.Session
$searcher = $updateSession.CreateUpdateSearcher()
$pending = $searcher.Search("IsInstalled=0 and Type='Software'").Updates
if ($pending.Count -gt 0) {
Write-Host "[!] $($pending.Count) updates pending installation. Apply the latest cumulative update containing the ALPC fix (CVE-2026-85880)."
$pending | ForEach-Object { Write-Host " - $($_.Title)" }
} else {
Write-Host "[+] No pending updates detected. Verify against the September 2026 Patch Tuesday bulletin."
}
} catch {
Write-Host "[-] COM-based update query failed (offline?). Check via: Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5"
}
# --- 3. Interim hardening: enable Chrome Site Isolation strictness and block renderer file access ---
# These enterprise policies reduce exploit surface while awaiting patch deployment
$chromePolicyPath = "HKLM:\SOFTWARE\Policies\Google\Chrome"
if (-not (Test-Path $chromePolicyPath)) { New-Item -Path $chromePolicyPath -Force | Out-Null }
# Force site isolation (mitigates renderer-to-renderer and cross-site exploitation)
Set-ItemProperty -Path $chromePolicyPath -Name "SitePerProcess" -Value 1 -Type DWord
# Disable legacy renderer code integrity bypasses
Set-ItemProperty -Path $chromePolicyPath -Name "RendererCodeIntegrityEnabled" -Value 1 -Type DWord
Write-Host "[+] Applied Chrome enterprise hardening policies (SitePerProcess, RendererCodeIntegrity)."
# --- 4. Audit: recent suspicious child processes of chrome.exe (requires Sysmon Event ID 1) ---
Write-Host "`n[+] Querying Sysmon log for chrome.exe child processes (last 14 days)..."
$startDate = (Get-Date).AddDays(-14)
try {
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1; StartTime=$startDate} -ErrorAction Stop |
Where-Object { $_.Message -match 'ParentImage.*chrome\.exe' -and
$_.Message -match 'Image.*(cmd|powershell|pwsh|mshta|rundll32|regsvr32|certutil|wscript|cscript|schtasks)\.exe' } |
Select-Object TimeCreated, Message |
Format-List
Write-Host "[+] Sysmon audit complete. Review any hits above immediately and isolate affected hosts."
} catch {
Write-Host "[-] Sysmon log unavailable or no matching events. Ensure Sysmon with process creation logging is deployed."
}
Write-Host "`n=== SCRIPT COMPLETE === Review all [!] ACTION items and escalate any audit hits to IR."
Remediation
1. Patch Chrome immediately — this is the kill chain's entry point.
- Deploy the Chrome stable channel emergency update addressing CVE-2026-85046 and CVE-2026-87491 across all Windows endpoints. For managed fleets, use Chrome Browser Cloud Management or your software distribution platform to force the update and require browser relaunch — a downloaded update that isn't relaunched leaves users exposed.
- Monitor the Google Chrome Releases blog for the exact fixed build number and any follow-up out-of-band updates.
2. Apply the Windows cumulative update for CVE-2026-85880.
- Prioritize endpoints where Chrome is deployed. The ALPC vulnerability is the privilege escalation stage; patching it breaks the chain even if browser exploitation succeeds, containing the attacker inside a low-integrity context.
- Reference the Microsoft Security Update Guide entry for CVE-2026-85880 and the September 2026 Patch Tuesday release for the applicable KB per OS build.
3. Check CISA KEV and enforce the deadline.
- Confirmed zero-day exploitation of this profile is a near-certain KEV candidate. If listed, federal agencies face a Binding Operational Directive deadline (commonly 14–21 days for actively exploited browser bugs) — private organizations should adopt the same SLA.
4. Interim mitigations if patching is delayed:
- Enforce Chrome enterprise policies: strict site isolation, renderer code integrity, and consider temporarily restricting Chrome to allowlisted sites for high-risk user populations (executives, finance, IT admins) via
URLAllowlist/URLBlocklist. - Where risk tolerance permits, redirect high-risk browsing to a patched alternative browser or a remote browser isolation (RBI) solution until Chrome is updated.
5. Threat hunt retroactively.
- Run the Sigma, KQL, and VQL content above against telemetry from September 3, 2026 onward. Zero-day exploitation means endpoints could have been compromised before any patch existed. If you find chrome.exe spawning LOLBins or unexplained child processes, treat it as an incident: isolate the host, capture memory, and hunt for CLEANGLUP persistence and lateral movement.
6. Strengthen the human layer against fake-website lures.
- This campaign's entry vector is convincing lookalike sites. Reinforce phishing-resistant controls: DNS filtering with newly-registered-domain blocking, URL rewriting in email, and user reporting workflows. Browser exploit chains are expensive — forcing the actor to burn them against hardened, monitored targets raises their cost dramatically.
7. Validate your EDR's coverage of browser exploitation.
- Confirm your EDR logs process ancestry for chrome.exe, captures command lines, and alerts on browser-spawned child processes. Many default configurations under-instrument browsers precisely because of their noisy process model — that gap is exactly what UTA0565 is counting on.
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.