Malicious free VPN extensions show how browser trust gets abused

At a glance

What this is: This analysis shows how malicious browser extensions marketed as free VPN tools can use broad extension permissions to intercept traffic, profile users, and persist through repeated takedowns.

Why it matters: It matters because browser extensions sit inside the trust boundary for human identities and can also expose secrets, sessions, and downstream enterprise access paths if they are not continuously governed.

By the numbers:

• Two of the extensions were available in the Chrome Web Store for nearly six years before removal in May 2025.

👉 Read LayerX Security's analysis of the malicious free VPN extension campaign

Context

Browser extensions are a privileged execution layer in the user workspace, which makes them an identity and access issue as much as a client-side security issue. When an extension can read navigation events, alter proxy settings, and fetch remote configuration, it can sit between the person and every service they access.

This campaign matters because it shows how “free” software can become a long-lived control point for traffic interception, profiling, and redirect abuse. For IAM and security teams, the concern is not only the endpoint itself but the browser session, the credentials used in that session, and the trust assumptions behind everyday access.

The broader lesson is that extension governance has to be continuous. A one-time store review does not stop a malicious publisher from resurfacing with a near-identical package, a new identifier, and the same remote-control pattern.

Key questions

Q: How should security teams control risky browser extensions in the enterprise?

A: Treat browser extensions as governed access software, not lightweight add-ons. Approve only what the business needs, restrict privileged permissions such as proxy and page interception, and watch for outbound configuration fetches and preference tampering. If an extension can see or steer authenticated traffic, it belongs in the same control conversation as session protection and third-party access.

Q: Why do browser extensions with proxy access increase identity risk?

A: Because they operate inside the authenticated browser session and can observe or alter traffic after login. That lets a malicious extension capture session data, redirect users to phishing pages, or expose downstream services that assume the browser is trusted. The risk is not just malware on the endpoint, but abuse of the access path itself.

Q: What breaks when extension behaviour can change after store review?

A: Static approval breaks down because the reviewed code is no longer the whole control surface. If the extension downloads new configuration, updates rules remotely, or activates behaviour later, the effective privilege model changes after install. Security teams then lose the assumption that initial review equals ongoing safety.

Q: Who is accountable when a browser extension intercepts corporate traffic?

A: Accountability sits with the organisation that allowed the extension into the managed environment and with the teams that own browser policy, endpoint governance, and identity controls. NIST Cybersecurity Framework 2.0 helps frame that responsibility through identify, protect, detect, respond, and recover, but operational ownership must be explicit.

Technical breakdown

How malicious browser extensions turn proxy permissions into control

Extensions with proxy-related permissions can route browser traffic through attacker-controlled endpoints by installing a remote PAC script or by changing proxy settings at runtime. When combined with webRequest or declarativeNetRequest, the extension can observe and modify navigation, rewrite destinations, and change behaviour after installation. That makes the browser itself an enforcement point for redirection, logging, and content substitution. The core risk is not just data leakage, but delegated control over where the user’s traffic goes and what content they receive.

Practical implication: treat proxy-capable extensions as high-risk software and approve them only with explicit business need and continuous monitoring.

Why remote configuration and dynamic rules defeat static review

A malicious extension can fetch configuration from external servers, download new PAC logic, and update filtering rules dynamically, which means the code a reviewer inspects is not necessarily the code that will run tomorrow. This is a classic persistence pattern in extension abuse: the initial package is only a loader. The real behaviour is server-driven, so static scanning, store metadata review, and even short sandbox runs miss the operational payload once the extension starts receiving live instructions.

Practical implication: validate extension behaviour over time, not only at install, and block unsanctioned outbound configuration fetches.

How extension persistence and evasion keep a malicious add-on alive

The campaign uses keepalive techniques, history tampering, delayed activation, and even self-uninstall logic when scrutiny increases. Those behaviours are designed to survive browser lifecycle changes, hide redirect traces, and reduce forensic evidence. In practical terms, the extension behaves like a covert control plane inside the browser, with enough autonomy to modify its own operating conditions and avoid easy removal. This is why the threat survives takedown and reappears under new names and icons.

Practical implication: monitor for extension install, proxy, and browser preference changes as operational indicators, not just malware detections.

Threat narrative

Attacker objective: The attacker wants durable browser-level control that enables traffic interception, user profiling, credential exposure, and selective redirection at scale.

1. Entry occurs when users install a free VPN or ad-blocking extension that appears legitimate in the browser store and asks for broad browsing permissions.
2. Escalation happens when the extension fetches remote configuration, installs a PAC script, intercepts main-frame navigation, and updates rules dynamically to control traffic.
3. Impact follows when the operator redirects pages, profiles visited URLs, disables competing extensions, and exposes browsing activity and credentials to attacker-controlled infrastructure.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser extensions have become an access governance problem, not a simple endpoint hygiene problem. When an extension can see every navigation event, alter proxy behaviour, and change its own rules remotely, it is operating inside the trust boundary that IAM teams care about. That means session protection, extension allowlisting, and browser telemetry now sit alongside traditional identity controls. Practitioners should treat extension permissions as access grants with blast radius, not as convenience settings.

Extension permissions create a browser-level identity blast radius. A single add-on with proxy, webRequest, and download or storage access can observe, redirect, and profile activity across every authenticated service the user opens. The problem is not just one malicious package, but the aggregation of privileges into a control surface that outlives one install event. Security teams need to evaluate extension privilege combinations the same way they evaluate privileged service accounts: by what they can reach, modify, and hide.

Remote-controlled browser behaviour collapses the assumption that review at install time is enough. The review model was designed for packages whose behaviour is largely fixed at submission time. That assumption fails when the extension fetches new configuration and updates its rules after publication because the effective privilege set changes after approval. The implication is that browser governance has to account for post-install mutability, not just initial permission scope.

Free does not mean low risk when the product is the user’s traffic and data. The campaign shows how consumer-grade branding can conceal a surveillance function that is structurally compatible with enterprise compromise paths. In practice, the browser becomes an identity-adjacent telemetry source that can expose sessions, cookies, and downstream access. Practitioners should assume that consumer extension risk can become enterprise access risk without any perimeter event.

Runtime extension control: this pattern is defined by server-driven behaviour that changes after review, which makes static approval insufficient and forces continuous operational oversight. The key lesson for the field is that browser extension governance now belongs in the same conversation as secrets exposure, session theft, and third-party access control. Teams should move from install-time trust to lifecycle control.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting only partial visibility.
• To see how identity programmes can close that gap, review Ultimate Guide to NHIs , Key Research and Survey Results for the governance baseline that continuous monitoring should support.

What this signals

Browser extension governance is now part of identity protection because the browser is where humans authenticate, approve, and continue access. When an add-on can intercept navigation and change proxy behaviour, the security programme needs controls that reach into the session, not just the endpoint. The practical move is to fold extension inventory, session risk, and browser policy into the same operating model.

Identity blast radius: the useful way to think about this campaign is not as one bad extension, but as one permission set that can touch many services at once. That matters because the same user can expose email, SaaS, and internal apps through a single compromised browser profile. Teams should map which extensions can expand blast radius across the services they protect.

For identity teams, the immediate watchpoint is post-install mutability. A package that looked harmless at approval can turn into a remote control channel later, which means store review is only the first gate. Continuous monitoring of browser preferences, proxy settings, and session anomalies is the operational control that matches the threat.

For practitioners

• Inventory and classify browser extensions Build an enterprise inventory of installed extensions by user, device, and browser, then classify each extension by permission set, outbound connectivity, and business justification. Prioritise anything with proxy, webRequest, or declarativeNetRequest access.
• Block high-risk extension patterns at the policy layer Restrict installation of proxy-capable, ad-blocking, and VPN extensions unless they are explicitly approved. Use browser policy, endpoint management, and network controls together so a removed store listing does not leave a live install in place.
• Monitor for proxy and preference tampering Alert on PAC file changes, browser preference edits, extension disable events, and new outbound configuration fetches from extension domains. Those signals are often the earliest signs that an extension is moving from convenience software to a covert control plane.
• Revoke exposed sessions and rotate credentials after exposure If a suspicious extension was present on an endpoint used for sign-in, revoke active sessions for critical services and rotate credentials that may have been captured through browser activity. Clear cookies and stored tokens where the browser session could have been intercepted.

Key takeaways

• Malicious browser extensions can turn user trust into a high-privilege access path for traffic interception and data theft.
• The scale matters because past variants reached more than 9 million installs and the campaign reappears after takedowns.
• Continuous extension monitoring, permission restriction, and session revocation are the controls that matter when browser behaviour changes after installation.

Key terms

• Browser Extension Privilege: The set of browser permissions and runtime capabilities granted to an extension. In practice, this can include reading page content, intercepting requests, changing proxy settings, and storing state. The higher the privilege set, the larger the potential blast radius if the extension is abused or compromised.
• Proxy-capable Extension: An extension that can route browser traffic through configured endpoints or modify proxy behaviour. These extensions can become a control point for redirection, logging, and policy evasion if they can fetch configuration remotely or update rules after installation.
• Session Exposure: The risk that authenticated browser activity reveals cookies, tokens, page content, or navigation history to an untrusted component. For browser-based access, session exposure can create downstream compromise even when the original login was legitimate and multi-factor protected.
• Browser Identity Blast Radius: The range of services and accounts that can be affected when a browser component can observe or modify access flows. In identity programmes, it describes how one extension, profile, or session can spread risk across multiple authenticated applications.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by LayerX Security: RolyPoly VPN, the malicious free VPN extension campaign. Read the original.