PEEP Malware Turns Chrome and Edge Into Post-Compromise Backdoors

A malicious browser extension does not always need to begin with a deceptive Web Store installation. PEEP malware demonstrates what attackers could do after they already control an endpoint.

SOCRadar’s Threat Research Unit identified PEEP as a Chromium-based post-exploitation toolkit disguised as a “Smart Bookmarks” extension. The recovered toolkit requires prior administrative or code-execution access. Therefore, PEEP is not an initial-access exploit or browser vulnerability.

Instead, its distinctive technique starts after endpoint compromise. PEEP manipulates Chromium’s Secure Preferences integrity values to help install and retain a sideloaded extension. It then connects the extension to a native messaging host for operating-system access. The recovered host-side binary, nm_host.exe, targets Windows.

PEEP Malware at a Glance

SOCRadar also describes PEEP as derived from the open-source RedExt framework rather than an entirely independent codebase.

How PEEP Malware Manipulates Chromium Secure Preferences

PEEP’s defining behavior is how it turns an existing endpoint compromise into persistent browser-level access.

Its installation routines can inject the extension into Chrome and Edge profiles. One installer, install_silent.ps1, works with patch_secure_prefs.ps1 to manipulate Chromium’s Secure Preferences data. The toolkit recalculates integrity values associated with the modified preferences so the browser accepts the changes.

PEEP uses layered persistence through validated Secure Preferences state, enterprise force-install policies, a registered native-messaging host and a Ghost Anchor ScriptCache fallback.

That enterprise-policy abuse matters because force installation itself is legitimate Chromium functionality. Google’s documentation states that ExtensionInstallForcelist can silently install specified extensions and prevent users from disabling or removing them. PEEP demonstrates how legitimate browser administration mechanisms can become useful after an attacker already controls the endpoint.

How nm_host.exe Takes PEEP Beyond the Browser

PEEP does not stop at browser surveillance.

The extension communicates with a native messaging host named com.peep.lab. Its recovered Windows implementation uses nm_host.exe to bridge browser activity with operating-system functionality.

Native messaging is another legitimate browser capability. Chrome permits extensions to exchange messages with registered native applications. On Windows, defenders should also inspect the registry locations used to register PEEP’s native messaging host. These include HKLM\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.peep.lab and HKCU\Software\Google\Chrome\NativeMessagingHosts\com.peep.lab, along with corresponding Edge and WOW6432Node locations. These artifacts can help SOC teams identify the browser-to-host bridge during endpoint investigations.

PEEP abuses that browser-to-host bridge for capabilities including:

• executing commands through supported shells;
• enumerating processes and services;
• reading, writing, renaming and deleting files;
• searching directories;
• retrieving system information; and
• managing other host-side operations.

This distinction is important. The browser extension acts as PEEP’s primary agent, while nm_host.exe provides host-level command and file operations in the user context.

What PEEP Malware Can Collect from Chrome and Edge

Once active, PEEP’s agent contacts its command-and-control infrastructure over plaintext HTTP. The recovered configuration uses a nominal 30-second cycle for command polling and automated collection.

The toolkit supports collection of:

• session cookies;
• recent browsing history;
• open tabs and active URLs;
• bookmarks and downloads;
• page DOM and web storage;
• screenshots;
• clipboard content on demand;
• browser and extension metadata; and
• password-like fields submitted through web forms.

However, one distinction matters for credential-theft claims. SOCRadar found that PEEP can capture password-like fields from web pages, but it does not directly read Chrome’s saved-password database.

Collected telemetry can be sent through /api/exfil, while command results can return through /api/agents/<id>/task_result. PEEP’s use of plaintext HTTP also creates a network-level detection opportunity. Because the traffic is unencrypted, network security controls with HTTP payload-inspection capabilities can inspect its traffic without first decrypting TLS. Security teams can therefore monitor outbound HTTP for PEEP-related endpoints and suspicious data transfers associated with its command-and-control infrastructure.

Why Session Cookies Make PEEP an Identity Risk

PEEP’s browser access creates an identity-security concern because authenticated browser state can be valuable after endpoint compromise.

Session cookies may represent existing authenticated sessions to SaaS applications and other web services. Therefore, stealing usable session material can create a path to session abuse without requiring the attacker to obtain the user’s password again.

This does not mean PEEP has been shown bypassing MFA or compromising specific SaaS services. The available research establishes its cookie-collection capability, not those downstream outcomes.

The distinction changes the defensive priority. Responders investigating suspected PEEP activity should consider both the compromised Windows endpoint and authenticated sessions exposed through its browsers.

How Hexnode Controls Map to PEEP’s Browser-to-Host Chain

PEEP crosses endpoint, browser and identity boundaries. That makes Hexnode UEM, XDR and IdP relevant at different stages of the defensive workflow.

Restrict Unapproved Chrome Extensions with Hexnode UEM

PEEP specifically relies on installing an unauthorized Chromium extension. Hexnode UEM documents Browser Settings for managed Windows devices that can configure, automatically install, allow or restrict Google Chrome extensions.

Administrators can also disable external extensions that are not listed in the Chrome Web Store. An allowlist can restrict Chrome to approved extension IDs.

This directly addresses part of PEEP’s browser attack surface. However, these controls should not be presented as proof that UEM alone blocks PEEP after an attacker already has administrative or code-execution access.

PEEP also modifies Windows-side artifacts. Hexnode UEM supports custom PowerShell and Batch script execution on managed Windows endpoints. Administrators can therefore use validated scripts for organization-specific inspection or remediation workflows where appropriate.

Investigate Post-Compromise Activity with Hexnode XDR

PEEP’s native host introduces endpoint behaviors beyond the extension itself. These include process discovery, shell execution and file-system operations.

Hexnode XDR provides threat hunting, endpoint investigation and response capabilities across supported Windows and macOS environments. Its documented response actions include device isolation, process termination and file quarantine.

For this incident, the relevant scope is the recovered Windows implementation of PEEP. Security teams can use endpoint telemetry and threat-hunting workflows to investigate suspicious activity associated with a suspected compromise.

Hexnode XDR should not be described as specifically detecting PEEP unless a documented PEEP detection exists.

Featured resource

Why XDR Is Stronger With UEM

See how combining endpoint management with XDR can strengthen threat investigation, response and endpoint resilience.

Download the whitepaper

Restrict Sensitive Access from Non-Compliant Devices

PEEP also shows why authenticated identity alone does not establish endpoint trust.

Hexnode IdP supports Conditional Access based on user identity, device compliance and security context, allowing access rules to account for both identity and device posture.

This control addresses potential downstream exposure from compromised endpoints. It does not invalidate stolen cookies automatically or establish that PEEP can bypass authentication controls.

What Security Teams Should Check for PEEP Malware

Organizations investigating possible PEEP exposure should prioritize the artifacts documented by SOCRadar:

1. Look for the primary “Smart Bookmarks” extension ID ejkndncpkdcjcikfhiamcdehdoegilbj.
2. Check Chrome and Edge NativeMessagingHosts registry locations for com.peep.lab, including applicable HKCU, HKLM and WOW6432Node paths.
3. Investigate unexpected nm_host.exe execution.
4. Review %LOCALAPPDATA%\PEEP for associated artifacts.
5. Investigate unauthorized changes to Chrome or Edge Secure Preferences.
6. Review Chrome and Edge enterprise extension policies for unauthorized entries. For Edge, inspect SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallAllowlist and other configured extension-control policies.
7. Look for connections to documented PEEP infrastructure.
8. Revoke potentially exposed authenticated sessions where compromise is suspected.
9. Restrict browser extensions to approved business requirements.

These steps address the distinctive PEEP chain rather than treating the incident as generic extension malware.

PEEP Shows Why the Browser Is Part of Endpoint Security

PEEP malware starts from an important assumption: the attacker already has endpoint access.

From there, it converts Chrome or Edge into a persistent collection and control layer. Secure Preferences manipulation helps retain the extension, while native messaging bridges browser access to Windows host functionality.

That makes browser-extension governance, endpoint investigation and session security interconnected defensive problems. Enterprises should treat extensions as privileged software, investigate unexpected browser-to-native-host relationships, and review authenticated sessions whenever a browser endpoint is suspected of compromise.

PEEP does not introduce a new Chrome or Edge zero-day. Instead, it demonstrates how deeply an attacker can exploit legitimate browser functionality after the endpoint security boundary has already failed.