Bespoke Zero-Day Chains Are Dead. The Rental Model Won.

For years, a working browser-to-kernel exploit chain was a boutique product. One well-funded group built it, guarded it carefully, and burned it on a handful of high-value targets. If you weren’t the target, you were mostly safe by irrelevance.

That era is closing. SecurityWeek reports that an exploit kit called BlueMoon is chaining recent Chrome and Windows zero-days, and that multiple espionage-motivated actors have picked it up in what the report describes as “opportunistic, rushed deployments.” When a chain becomes a product several crews can rent, the math flips. The gap between “patch is out” and “someone is firing this at you” stops being measured in months.

Here’s the mechanism in plain terms, because it matters for how you defend. A chain like this needs two doors. The first is a bug in the browser’s renderer — the part that reads untrusted web content — that lets code run inside the sandbox. Think of it as picking the lobby lock. On its own, that lobby is deliberately built to contain you: the sandbox is a room with no exits. So the chain needs a second bug, a local privilege escalation, that punches through the sandbox or the Windows kernel underneath it. That’s the master key. Lobby lock plus master key equals SYSTEM. One bug is a nuisance. Two, chained, is full compromise on that host.

On the specifics: I’m not going to hand you CVE numbers I can’t stand behind. The reporting frames this as a browser sandbox escape paired with a local privilege escalation on Windows. If your vendor advisories name the exact CVEs, trust those over any secondhand list — including mine. What you can act on right now is the shape of the thing, and the shape tells you exactly what to check.

So check it, in this order.

1. Confirm your browsers actually updated — don’t assume they did

Chrome and Edge auto-update, which lulls everyone into believing the fleet is current. It isn’t. Machines that sleep for days, kiosk builds with update services disabled, and users who never fully close the browser can sit on a stale version for weeks. A renderer bug is the entry door for the whole chain, so an up-to-date browser is your cheapest, highest-leverage fix. Verify the installed version against the current Stable release from Google and the current Edge Stable from Microsoft — the real numbers, pulled today.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Report-only: inventory installed Chrome/Edge versions on this host
$targets = @(
  "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
  "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
  "$env:ProgramFiles\Microsoft\Edge\Application\msedge.exe",
  "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe"
)
foreach ($p in $targets) {
  if (Test-Path $p) {
    [pscustomobject]@{
      Browser = Split-Path $p -Leaf
      Version = (Get-Item $p).VersionInfo.ProductVersion
      Path    = $p
    }
  }
}
# Compare Version against the current Stable channel release for each browser.
# Anything trailing the current Stable build is a candidate exposure.

For scale, pull this from your management plane instead of walking machines one at a time — Intune’s browser inventory, or the version field in Defender’s device software inventory. The point is the same: measure, don’t hope.

2. Confirm September’s Patch Tuesday actually landed on endpoints

The browser update closes the front door. The Windows privilege-escalation half of the chain is closed — if and when Microsoft ships the fix — by the OS patch. Check whether this month’s cumulative update addresses a privilege-escalation CVE that matches the reporting, and then verify deployment. “Approved in the console” and “installed on the endpoint” are different sentences, and the difference is where breaches live.

1
2
3
4
5

# Report-only: what's the latest cumulative update actually installed here?
Get-HotFix |
  Where-Object { $_.Description -eq 'Update' -or $_.Description -eq 'Security Update' } |
  Sort-Object InstalledOn -Descending |
  Select-Object -First 5 HotFixID, Description, InstalledOn

Cross-reference the KB against the current MSRC advisory for your build. If the fix for the LPE isn’t installed, you still have a master key sitting in the building.

3. Hunt for the escape, not just the entry

Assume the door might already be open. The loudest signal from a chain like this is a browser process spawning something it has no business spawning — a script host, a shell, a signed-binary proxy. A renderer doesn’t launch powershell.exe in the course of showing you a webpage. If yours did, that’s your lead. Run this in Defender for Endpoint’s Advanced Hunting — no kernel driver, no third-party agent, just data you already collect.

1
2
3
4
5
6
7
8
9

// Browser processes spawning execution primitives — classic post-escape behavior
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("chrome.exe","msedge.exe")
| where FileName in~ ("powershell.exe","cmd.exe","rundll32.exe","mshta.exe",
                      "wscript.exe","cscript.exe","regsvr32.exe","bitsadmin.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName,
          FileName, ProcessCommandLine, InitiatingProcessCommandLine, AccountName
| order by Timestamp desc

4. Read the crashes as evidence, not noise

Exploit development is messy, and “rushed deployments” means messier still. Reliability suffers, so failed attempts leave a trail: a spike in renderer crashes on specific hosts, often right before a successful run on the same machine. Most shops delete this telemetry as junk. Don’t. A cluster of WerFault.exe events tied to a browser is worth ten minutes of your morning.

1
2
3
4
5
6
7
8

// Browser crash reporting — potential failed exploitation attempts
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "WerFault.exe"
| where ProcessCommandLine has_any ("chrome.exe","msedge.exe")
| summarize Crashes = count() by DeviceName, bin(Timestamp, 1h)
| where Crashes >= 3
| order by Crashes desc

5. Shrink what the master key opens

Until both halves of the chain are patched everywhere, make the escape less useful. Turn on Microsoft’s attack surface reduction rules that block browsers and Office apps from spawning child processes — several of them target exactly the behavior in step 3. Enforce them in block mode where you can; run them in audit first if you’re nervous, but don’t leave them in audit forever. And revisit least privilege: a chain that lands SYSTEM on a laptop where the user is already a local admin barely had to work for it.

6. Watch the people who’d use this, not just the tooling

“Opportunistic, rushed” is the tell here. This isn’t the careful, single-shot targeting of classic espionage. It reads more like several groups grabbing a shared capability and throwing it at whoever’s reachable before the patch window closes. That broadens your exposure model: you don’t have to be a named target to catch a stray. Treat delivery — a malicious ad, a compromised site, a lure link — as the thing you’re most likely to see, and prioritize your most-exposed populations: internet-facing roles, execs, anyone browsing untrusted content by job description.

If you do one thing today

Verify — with data, not faith — that your browser fleet is on current Stable and that this month’s Windows cumulative update is installed on endpoints, not merely approved. Both doors have to be shut. Patching one and forgetting the other leaves you with a locked lobby and a working master key, which is the exact situation BlueMoon was built to sell.

The uncomfortable part isn’t this kit. It’s the model. Once a chain becomes a rentable product, “we’ll get to it next cycle” is a decision to be exploited on a schedule someone else controls.