Meet PEEP — the browser extension that forgot it was supposed to be helpful. It pretends to be a harmless bookmarks add-on, but when operators have already slipped onto a machine, this thing quietly converts Chrome and Edge into a backdoor that can peek at tabs, steal cookies, and even run commands on the host.

What PEEP does (in plain, slightly panicked language)

Once dropped by someone who already has access to your computer, PEEP behaves like a tiny agent living inside the browser. It repeatedly checks in with its command-and-control server, grabs browsing data (history, active tabs, session cookies), and waits for new orders. If the job requires poking the operating system, it calls a helper program to do the heavy lifting.

It’s not just a credential scraper — thanks to a native bridge to the OS, it can run shell commands, move files around, and list processes and services. It also supports an update channel, telemetry heartbeats, and tasking for screenshots, clipboard access, and on-page script injections. In short: it’s capable, persistent, and annoying.

How it sneaks in, how it survives, and how it talks to its boss

PEEP doesn’t break in by itself. It requires the attacker to already have some form of admin or code execution on the target. From there, the installer places the extension directly into the browser profile and fiddles with Chromium’s integrity and policy files so the extension starts enabled and stays there — no store approval or user consent required. This is classic silent sideloading, and it’s nastier than it sounds.

When the extension needs OS-level access, it launches a companion executable (a native-messaging host) that runs commands and handles file management. Browser-only tasks (like grabbing the active URL, taking screenshots, or running content scripts) are handled inside the extension itself. The extension keeps a tight polling loop, asking its controller for new instructions every few dozen seconds and exfiltrating collected artifacts back to the server.

Typical server endpoints used by this kind of kit include:

  • /api/register — registers the infected browser instance
  • /api/agents/<id>/heartbeat — reports user-agent, OS and timezone info
  • /api/extension_update/ and /api/extension_crx/ — deliver updates to the extension
  • /api/agents/<id>/task_result — post results of executed commands
  • /api/exfil — receives harvested data like cookies, history, tabs, active URL and IP
  • /health — simple status endpoint that can be queried without auth
  • /login — web interface for the C2 management panel

For installation and persistence, the toolkit drops and runs a handful of helper scripts. Common examples include PowerShell scripts to enable developer mode, patch the browser’s Secure Preferences so the extension auto-enables, and re-register the extension so it survives restarts. There’s even a Python script variant for patching preferences on Linux, which suggests the operators are trying to hit multiple platforms.

  • install_silent.ps1 — enables developer/sideloading mode
  • patch_secure_prefs.ps1 — edits the browser’s Secure Preferences file
  • force_enable.ps1 — re-registers the extension, places the CRX locally, and restarts the browser
  • patch_secure_prefs_linux.py — Linux-side preference patching

All told, this toolkit transforms a signed browser process into a persistent pivot point that can bypass some detections simply by running inside the browser. Because the malicious logic lives inside a legitimate process, spotting it can be trickier than spotting a rogue EXE.

If you’re the defensive type, a few quick takeaways: lock down extension policies via enterprise controls, monitor unusual browser preference changes and external extension registrations, treat native messaging hosts as high-risk artifacts, and keep a sharp eye on unexpected scripts that modify browser files. And if in doubt, assume your bookmarks extension is not actually interested in your reading habits.