On 7 September 2026, SOCRadar published an analysis of PEEP, a Chromium post-exploitation toolkit that presents itself as a browser extension called Smart Bookmarks, extension ID ejkndncpkdcjcikfhiamcdehdoegilbj. It is built on RedExt, an open-source red teaming framework.

Start with the precondition

PEEP requires prior administrative or code execution access on the machine. It cannot compromise anything on its own.

That single sentence changes what the story is. This is not a flaw in Chrome or Edge, there is nothing to patch, and no amount of careful browsing exposes you to it. It is a decision about where to live once you are already in — and, like the implant compiled into HAProxy last week, the attacker picked the process that already has everything worth having.

The browser holds your sessions, your saved credentials, your internal applications and your OAuth tokens, and it makes outbound requests all day without anyone thinking about it. As post-compromise real estate, it is close to ideal.

Forging the check that would catch it

Chromium stores extension state in a Secure Preferences file, and signs it so that tampering can be detected. That mechanism exists precisely to stop someone writing an extension into a profile from outside the browser.

PEEP forges those integrity values. The browser inspects its own preferences, finds the signatures valid, and reports that nothing has been altered.

This is the same shape as an implant erasing its own entries from the proxy log: the attacker has not evaded the verification, they have taken it over. Anything downstream that trusts "Chromium says the profile is intact" is now reading a document the attacker signs.

Escaping the sandbox through the front door

The toolkit ships a native-messaging binary, nm_host.exe. Native messaging is a documented Chromium feature that lets an extension talk to a program on the host, and it exists so that extensions can do things the sandbox forbids.

PEEP uses it exactly as designed, which is why there is nothing to fix. Through that channel it runs shell commands, manages files and enumerates processes and services. Inside the browser it takes screenshots, manipulates the clipboard, injects JavaScript, steals cookies and hijacks sessions, and exfiltrates browsing history, active-tab metadata, session cookies and credentials.

Persistence that looks like your IT department

The persistence list is worth reading in full, because one entry is different from the others:

  • Sideloading with Developer Mode enabled
  • Enterprise ExtensionInstallForcelist policy
  • Secure Preferences file manipulation
  • ScriptCache fallback
  • Re-registration through the External Extensions JSON manifest

ExtensionInstallForcelist is the Group Policy setting administrators use to push required extensions to a fleet. An extension installed that way cannot be removed by the user, reinstalls if deleted, and appears in the browser as installed by your organisation — which is the most effective disguise available, because it is the one explanation an employee will accept without asking.

We have written before about extensions that became malicious after the fact. This is the same destination reached by policy instead of by purchase.

The operational security is poor, and that helps you

PEEP beacons every 30 seconds over plaintext HTTP.

Not HTTPS. Not jittered. Every thirty seconds, in the clear, to endpoints named /api/commands, /api/register, /api/agents/[id]/heartbeat, /api/extension_update/, /api/exfil and /health.

For a toolkit this careful about the browser's integrity mechanisms, that is a strange gap, and it is the single easiest thing to detect in this entire report. Any egress monitoring at all sees a machine calling an unknown host twice a minute in plaintext.

C2 infrastructure: 206.237.30[.]232 and xfjcc[.]fun.

On attribution, and on the numbers

SOCRadar observed Chinese-language artifacts in the source code and presumes a Chinese-speaking threat actor. It also says the activity remains unattributed.

Both of those are worth repeating exactly as stated. Language artifacts tell you something about who wrote the code. They do not tell you who is running it, who is paying for it, or where. A tool built by one person is frequently operated by someone else entirely, and RedExt — the framework underneath it — is public.

The observed infrastructure showed 34 agent entries, 10 active sessions and 507 data records, and SOCRadar notes these may include the developer's own test deployments. Treat them as an upper bound on a small number rather than a victim count.

One further note, offered as an observation rather than a finding: SOCRadar remarks on an "Authorized CTF" framing in the material, which it reads as possible misuse of AI safety guardrails during development. Nothing about that is established, and it is not evidence of anything on its own — but it is the second time in a week that a report has raised the question of what was used to build the tool as well as what the tool does.

What to do

  • Enumerate extensions across your fleet, and reconcile every one against what you deliberately deployed. Start with the ID above.
  • Audit your ExtensionInstallForcelist policy. An attacker with admin can add to it, and users cannot remove what it installs.
  • Alert on plaintext HTTP beaconing at fixed intervals. Thirty seconds, no jitter, unknown host. This is the cheapest detection available.
  • Look for nm_host.exe and unexpected native-messaging host registrations, which live in the registry and in on-disk manifests.
  • Do not treat this as a browser patching problem. If PEEP is present, something else got admin first, and that is the incident.

What is not established

  • The initial access vector. Unknown in the observed cases.
  • Who the victims are, or how many are real rather than test deployments.
  • Who is operating it. SOCRadar says the activity is unattributed and only the language of the source is observed.
  • When it was deployed. No timeline has been published.
  • Whether Google or Microsoft have responded. Neither is quoted.