Ten Days, Two Toolkits, One Forged Checksum: Chrome's Extension Trust Model Just Broke

SOCRadar published its PEEP writeup on 7 September. Buried in it is a detail I keep coming back to: the operator's control panel exposed a /health route that answered without a login. Anyone who found the box could read it. At the time of analysis it reported 34 registered agents, 10 active sessions, and 507 collected data records.

Small numbers. That is the point. This is not a mass campaign, it is a toolkit in early circulation, and the interesting part is not how many people it has hit. It is how it gets in.

PEEP installs itself into your Chrome or Edge profile by forging the cryptographic checksum that Chromium uses to decide whether a preference entry is legitimate. Ten days before SOCRadar's post, Proofpoint watched a Chinese espionage group do the same thing with different code. Two unrelated crews, one commodity and one state-aligned, landed on the same trust-model bypass inside a two-week window. When that happens, you are not looking at an incident. You are looking at a technique class that has gone mainstream.

What a forged super_mac actually buys you

Chromium stores extension state in a file called Secure Preferences, and it protects the sensitive entries with HMACs. Each protected value gets a MAC computed over three inputs: a seed baked into the browser binary, the user's Windows SID, and the JSON value itself. A master checksum, super_mac, covers the whole set of MACs so you cannot swap one entry cleanly. If the numbers do not line up, Chrome reverts the change or flags the extension as installed from outside the Web Store.

Rubrik Zero Labs walked through the bypass in detail in their GhostChrome-X analysis, and the honest summary is that it is not an exploit. There is no memory corruption and no CVE. The seed ships in the binary. The SID belongs to the user you already compromised. The JSON is whatever you want it to be. If you have code execution as that user, you have every input the browser has, so you compute a valid MAC for your own entry and recompute super_mac over the new set. Chrome opens, validates its own preferences, finds everything consistent, and enables your extension.

That is the whole trick. An integrity check is only worth something when the attacker cannot reach the inputs. Here they can reach all three.

PEEP: a red-team framework that grew a native messaging bridge

PEEP ships as "Smart Bookmarks," extension ID ejkndncpkdcjcikfhiamcdehdoegilbj. It is built on RedExt, an open-source browser red-teaming framework, which tells you something about how cheap this capability has become. Someone took a published research tool and bolted on the parts that turn research into tradecraft: an installer, a heartbeat, an update channel, and a native host.

The installer is three PowerShell scripts. install_silent.ps1 enables Developer Mode so arbitrary extensions can be sideloaded. patch_secure_prefs.ps1 does the HMAC forging described above. force_enable.ps1 is the fallback for when you would rather not touch Secure Preferences at all: it strips the extension from the external_uninstalls list, drops the CRX under %LOCALAPPDATA%\PEEP\crx, re-registers through the HKCU extensions key and an External Extensions JSON manifest, then restarts the browser. There is a Python port of the Secure Preferences patcher for Linux.

Inside the browser, the extension runs as a service worker and collects the obvious things: session cookies, history, open tabs, DOM content, local and session storage, clipboard, screenshots, form fields. It beacons to /api/commands every 30 seconds over plaintext HTTP, against 206.237.30[.]232 and xfjcc[.]fun, with the panel on port 5001.

The piece that matters is nm_host.exe, registered as a native messaging host under com.peep.lab. Native messaging is a legitimate Chromium feature: it lets an extension talk to a local binary. PEEP uses it to run shell commands, move files, and enumerate processes and services. Browser-only work stays in the extension. Anything needing the OS goes over the bridge. So the browser stops being a data source and becomes the implant, with a signed, trusted, autostarting process as its host.

I have built roughly this on engagements, and the reason you build it is simple. Endpoint tooling spends its budget on new and unsigned binaries. Your logic lives in chrome.exe, which is neither.

Ten days earlier, a nation-state did the same thing

Proofpoint's BlueMoon report, published 9 September, covers an exploit kit chaining CVE-2026-85046 (V8 type confusion) and CVE-2026-87491 (a V8 sandbox escape) with CVE-2026-85880, a heap overflow in Windows ALPC. Both V8 bugs were patch-gap zero days: fixed in public Chromium source, not yet shipped to stable Chrome, so attackers reversed the public fix and used it. Google shipped the sandbox escape fix on 8 September. Microsoft covered the ALPC bug in the September Patch Tuesday. CISA added both V8 bugs to the KEV catalog on 4 and 9 September with federal deadlines of 18 and 23 September.

Four distinct clusters used BlueMoon inside about a week. APT31 went first on 28 August, phishing US NGOs, mining companies and commodity traders. UNK_LateNight hit US aerospace from 2 September. UNK_DoubleCheck and UNK_QuietRacket followed. Proofpoint says plainly that it does not know how four groups obtained the same kit, and notes that a fully weaponized Chrome chain has historically been rare and expensive. Their read: the barrier to entry for this class of capability has dropped.

APT31's loader finishes the chain by installing a rogue extension posing as Google Gemini, tracked as GemStone, using the integrity bypass Proofpoint credits to published Synacktiv research. Same target, same mechanism, different payload.

So on one side you have a state actor burning two browser zero days to arrive at a forged super_mac. On the other you have a commodity kit that skips the zero days entirely, because it assumes you already have admin. Both end in the same place. That convergence is the story, not either tool on its own.

The part that should bother you

Both toolkits carry CTF references in their source. SOCRadar found repeated "Authorized CTF" strings in PEEP. Proofpoint found repeated references to v8CTF, Google's own V8 bug-hunting competition, in BlueMoon, alongside verbose comments, heavy diagnostic logging, and a markdown handover document. Proofpoint is careful here: it says it cannot tell whether the exploits were genuinely written for v8CTF, or whether that framing was used to talk a model past its guardrails.

I do not think that ambiguity resolves in defenders' favour. Two separate development efforts, on opposite ends of the sophistication scale, both wrapped in competition language and both showing the tells of machine-assisted authoring. We wrote about automated harvesting reaching end-to-end scale in the Zerofot scanner teardown, where the whole pipeline from scan to validated key ran without a human in the loop. This is the same curve applied to the build side rather than the run side.

Your extension allowlist is enforced in the wrong place

Here is where most enterprise browser policy falls over, and it is worth being precise because the vendor guidance glosses it.

Extension allowlisting and blocklisting via ExtensionSettings and ExtensionInstallForcelist were designed to govern the install path. They answer the question "may this user obtain this extension from the Web Store." They are administered as policy and they work well against a user who clicks something they should not.

PEEP does not use the install path. It writes the profile directly, as the user, with the profile's own integrity keys. GhostChrome-X goes further and abuses the force-install policy itself as a delivery mechanism, which is a nice inversion: the control designed to pin approved extensions becomes the thing that pins the attacker's. If you are relying on a policy set in GPO or MDM without also watching what the profile on disk actually says, you are auditing the door while someone rewrites the guest list.

The forensic discriminator worth knowing is from_webstore. A profile-injected extension shows up in extensions.settings.<id> as enabled with from_webstore set to false. Pull that across your fleet and you will find things. You will also find plenty of legitimate internal extensions, so tune before you alert.

The rest of the hunt for PEEP specifically: registry keys under NativeMessagingHosts\com.peep.lab, nm_host.exe on disk, staging under %LOCALAPPDATA%\PEEP, and 30-second plaintext HTTP beacons to port 5001. For BlueMoon, Proofpoint published a process tree of chrome.exe to cmd.exe to curl.exe to msgbox.exe, plus scheduled tasks with names like EdgeCore_AutoUpdate and a staging folder at C:\Users\Public\stomp_ext.

Use all of it. Then accept that every string in that paragraph has a shelf life measured in weeks, and that PEEP's own ScriptCache fallback means removing the visible extension can leave Chrome reloading a previously compiled malicious service worker. Partial remediation is worse than none, because it tells you you are clean.

What deception does that hunting cannot

The interesting weakness in both of these tools is that they do not triage. PEEP hoovers cookies, history, tabs, storage and form fields and ships the lot to /api/exfil. An extension with cookies and scripting permissions has no way to tell a real saved credential from one you planted, because at the profile level there is no difference. It is the same SQLite row.

So plant one. A saved login in the browser profile for an internal-looking host that no employee will ever navigate to, with a decoy session cookie to match. A legitimate user never triggers it, because nobody types that hostname. Any authentication attempt against it means something read the profile. That is the zero-false-positive property that makes a honeytoken alert worth waking someone for, and it is why deception behaves differently from the detection stack we picked apart in the 27-second breakout time analysis.

Two things I have learned doing this that nobody puts in the datasheet.

First, the decoy hostname has to resolve. Credential-parsing tooling on the attacker side scores plausibility before an operator ever looks, and a record that returns NXDOMAIN gets binned as junk. Point it at a sink that answers. While you are there, turn off autofill-on-page-load for that entry so a mistyped URL from a real user does not generate the alert you have trained your SOC to treat as certain.

Second, expect a delay. A honeytoken fires when the credential is used, not when it is stolen. For a crew that sells access rather than using it, that gap can run weeks. Treat that as the feature it is: the alert identifies the buyer, which is the actor who was going to encrypt something. It is the same lag we traced in the stolen AI session analysis, where the cookie kept working long after the login that created it was forgotten.

Patch Chrome, enforce your allowlist, restrict native messaging hosts to approved binaries, disable Developer Mode fleet-wide. Do all of it. Then assume it works right up until a toolkit that already has your SID computes a checksum the browser believes, and put something in the profile that only an attacker would ever touch. Book a walkthrough and we will show you what that looks like on a real endpoint.