Researchers have uncovered a coordinated campaign of more than 737 browser extensions published to the Chrome Web Store that impersonated well-known VPN and proxy services — while silently routing victims' web traffic through SOCKS5 proxy infrastructure operated by a single provider. Every one of these extensions presented itself as a privacy tool. In reality, each one converted the victim's browser into an exit node on someone else's proxy network, or worse, gave the operator a man-in-the-middle position over everything the user did online.
This is not a theoretical supply-chain risk. These extensions were live in Google's official store, passing whatever review exists, and accumulating installs under the branding of trusted VPN vendors. For enterprises, the implications are severe: any employee who installed one of these extensions has potentially routed corporate SaaS sessions, credentials, internal portal traffic, and sensitive documents through infrastructure controlled by an unknown third party. Session tokens, authentication cookies, and plaintext content of unencrypted sessions are all exposed to the proxy operator.
If your organization allows users to self-install browser extensions — and most do — you need to hunt for these now, audit your extension estate, and move to an allowlist model. This post gives you the detection content and remediation steps to do exactly that.
Technical Analysis
What the campaign does
The campaign follows a pattern we've seen mature significantly over the past two years: mass-published Chrome extensions that clone the branding, names, and store descriptions of legitimate VPN and proxy services. The extensions request the permissions required to function as a proxy — which, critically, are the same permissions a legitimate VPN extension needs. That's what makes this campaign effective: the malicious behavior is indistinguishable from the advertised functionality at the permission level.
The relevant Chrome extension permissions involved in this class of abuse include:
proxy— allows the extension to modify Chrome's proxy configuration programmatically via thechrome.proxyAPI, including setting a fixed SOCKS5 endpoint or pushing a PAC (Proxy Auto-Config) scriptwebRequest/declarativeNetRequest— traffic observation and modification<all_urls>or broad host permissions — applies the proxy behavior to every site the user visitstabs,cookies,storage— supporting permissions commonly bundled in
Attack chain
- Publication: Extensions are uploaded to the Chrome Web Store using names, icons, and descriptions impersonating recognizable VPN/proxy brands. With 737+ extensions from a single operation, this is an industrialized process — throwaway developer accounts, templated manifests, recycled store listings.
- Installation: Users searching for a free VPN install the extension. Chrome grants the requested permissions because they appear consistent with VPN functionality.
- Proxy configuration: The extension uses the
chrome.proxyAPI to point Chrome at a SOCKS5 proxy operated by the campaign's provider — either viafixed_serversmode with a hardcoded proxy host, orpac_scriptmode fetching a remote PAC URL. The configuration is written into Chrome's secure preferences. - Traffic interception: All browser traffic flows through the operator's SOCKS5 infrastructure. The operator can observe destination hosts and metadata for TLS traffic, and full plaintext content for anything not encrypted end-to-end. Session cookies captured in transit enable account takeover without ever touching the endpoint's credential stores.
- Persistence and rotation: Because the campaign spans hundreds of functionally identical extensions, Google removing a subset doesn't kill the operation — users are migrated or simply install a clone. The shared backend proxy provider is the actual payload; the extensions are disposable delivery vehicles.
Why this defeats traditional controls
- No malware on disk in the classical sense. Extensions are JavaScript and a manifest — most EDR content scanning treats them as benign browser data.
- The proxy traffic looks like normal Chrome browsing.
chrome.exemaking outbound connections is the single most common network behavior in any enterprise. Without port/destination baselining, it's invisible. - Store-hosted delivery inherits trust. Users (and many admins) treat "it's in the Chrome Web Store" as a vetting signal. It is not.
- Permissions are plausible. You cannot detect these extensions by permission request alone — legitimate VPN extensions request the same set. Detection must key on which extensions have proxy control and where traffic is actually going.
Exploitation status
This is confirmed, active, in-the-wild abuse at scale — 737+ extensions live in the official store is the definition of a mass-exploitation campaign, not a proof of concept. There is no CVE because there is no software vulnerability: this is abuse of legitimate Chrome extension APIs and weaknesses in the Web Store review process. No CISA KEV entry applies. The mitigation is entirely a policy, audit, and hunting problem.
Detection & Response
The detection strategy has three layers: (1) find extensions holding proxy-control permissions, (2) find Chrome's proxy configuration pointing at non-corporate endpoints, and (3) find chrome.exe establishing SOCKS5-style connections to non-standard destinations. No single layer is sufficient; together they're high-fidelity.
Sigma Rules
---
title: Chrome Extension With Proxy Control Permission Installed
id: 3f8a2c41-9b1e-4d57-a6c2-7e4f8b9d0a11
status: experimental
description: Detects installation of a Chrome extension whose manifest requests the proxy permission, indicating the extension can redirect all browser traffic. Fake VPN extensions impersonating legitimate services have used this to route users through attacker SOCKS5 proxies.
references:
- https://www.bleepingcomputer.com/news/security/hundreds-of-fake-chrome-vpn-extensions-route-traffic-through-a-proxy/
- https://attack.mitre.org/techniques/T1176/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1176
logsource:
category: file_event
product: windows
detection:
selection_path:
TargetFilename|contains:
- '\AppData\Local\Google\Chrome\User Data\'
- '\AppData\Local\Microsoft\Edge\User Data\'
- '\AppData\Local\BraveSoftware\Brave-Browser\User Data\'
selection_manifest:
TargetFilename|endswith: '\manifest.json'
condition: selection_path and selection_manifest
falsepositives:
- Legitimate extension installs and updates (high volume in unmanaged environments) - pair with extension ID allowlisting or file-content inspection of the manifest for proxy permissions
level: low
---
title: Chrome Proxy Configuration Modified Outside Enterprise Policy
id: 8c4d1e62-2a7f-4b38-9d15-6f3a5c8e2b47
status: experimental
description: Detects registry modification of Chrome/Edge proxy settings by a process other than the browser itself or known management tooling, consistent with an extension or script forcing a SOCKS5 proxy endpoint.
references:
- https://www.bleepingcomputer.com/news/security/hundreds-of-fake-chrome-vpn-extensions-route-traffic-through-a-proxy/
- https://attack.mitre.org/techniques/T1090/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.command_and_control
- attack.t1090.001
logsource:
category: registry_set
product: windows
detection:
selection:
TargetObject|contains:
- '\Software\Google\Chrome\PreferenceMACs'
- '\Policies\Google\Chrome\Proxy'
- '\Policies\Microsoft\Edge\Proxy'
- '\Internet Settings\ProxyServer'
- '\Internet Settings\AutoConfigURL'
filter_browser:
Image|endswith:
- '\chrome.exe'
- '\msedge.exe'
condition: selection and not filter_browser
falsepositives:
- GPO/MDM policy application
- Enterprise proxy management agents
level: medium
---
title: Chrome Browser Outbound Connection on Common SOCKS5 Proxy Port
id: 5b2e7a19-4d83-4c6f-b8e1-9a0d3f6c7e52
status: experimental
description: Detects chrome.exe, msedge.exe, or brave.exe initiating outbound connections to ports commonly used by SOCKS5 proxy services (1080, 1081, 8080) where the destination is external. Fake VPN extensions route traffic through operator-controlled SOCKS5 endpoints on such ports.
references:
- https://www.bleepingcomputer.com/news/security/hundreds-of-fake-chrome-vpn-extensions-route-traffic-through-a-proxy/
- https://attack.mitre.org/techniques/T1090.002/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.command_and_control
- attack.t1090.002
logsource:
category: network_connection
product: windows
detection:
selection_image:
Image|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\brave.exe'
selection_port:
DestinationPort:
- 1080
- 1081
selection_scope:
DestinationIsIpv6: 'false'
condition: all of selection_*
falsepositives:
- Legitimate corporate SOCKS proxies on 1080 - allowlist known internal proxy IPs
- Some dev/test tooling
level: medium
Note on the first rule: manifest file creation alone is noisy. In a mature environment, enrich it by forwarding extension directory names (the 32-character extension ID) to a lookup against your approved extension list, or disable it and rely on the KQL/VQL content below, which inspects manifest content — that's where the real fidelity is.
KQL — Microsoft Sentinel / Defender
This hunt enumerates installed Chromium extensions across the fleet via the Secure Preferences and extension manifest.json files, flags any extension requesting the proxy permission, and surfaces VPN/proxy-branded extensions not on an allowlist. It then pivots to network behavior.
// Hunt 1: Extensions with proxy-control capability installed via the Web Store
// Flags manifests requesting 'proxy' permission or VPN/proxy-themed extension dirs
DeviceFileEvents
| where TimeGenerated > ago(30d)
| where FolderPath has_any ("\\Google\\Chrome\\User Data\\", "\\Microsoft\\Edge\\User Data\\", "\\BraveSoftware\\")
| where FileName =~ "manifest.json"
| where FolderPath matches regex @"(?i)\\extensions\\[a-p]{32}\\"
| summarize arg_max(TimeGenerated, *) by DeviceId, FolderPath
| extend ExtensionId = extract(@"(?i)\\extensions\\([a-p]{32})\\", 1, FolderPath)
// Pull manifest content when available via file profile; otherwise use extension ID for store lookup
| join kind=leftouter (
DeviceFileEvents
| where FileName =~ "Secure Preferences"
| where FolderPath has "User Data"
| project DeviceId, PrefsFolder = FolderPath, PrefsTime = TimeGenerated
) on DeviceId
| project DeviceName, DeviceId, ExtensionId, FolderPath, TimeGenerated
| take 500
;
// Hunt 2: chrome.exe outbound on SOCKS5-typical ports to external IPs
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "brave.exe")
| where RemotePort in (1080, 1081)
| where not (ipv4_is_private(RemoteIP))
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
Ports = make_set(RemotePort)
by DeviceName, RemoteIP, InitiatingProcessFileName
| order by Connections desc
;
// Hunt 3: Browser processes connecting to a single remote IP across many devices
// (shared proxy provider = one destination appearing fleet-wide)
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "brave.exe")
| where RemotePort in (1080, 1081, 8080, 8443)
| where not (ipv4_is_private(RemoteIP))
| summarize DistinctDevices = dcount(DeviceId), Devices = make_set(DeviceName, 20)
by RemoteIP, RemotePort
| where DistinctDevices > 1
| order by DistinctDevices desc
Hunt 3 is your highest-fidelity query: the defining characteristic of this campaign is a single proxy provider behind hundreds of extension skins. One external IP (or a small set of IPs from the same ASN) terminating browser traffic from multiple endpoints, on non-standard ports, is exactly what the shared backend looks like.
Velociraptor VQL
Use this artifact to enumerate every Chromium extension manifest on an endpoint, parse the requested permissions, and flag anything with proxy control or suspicious VPN branding — plus a netstat pivot for live SOCKS5 connections:
-- Enumerate Chromium extension manifests requesting proxy/webRequest permissions
-- and flag VPN/proxy-themed extension directories
LET manifests = SELECT
FullPath AS ManifestPath,
read_file(filename=FullPath, length=200000) AS RawManifest
FROM glob(
globs=[
'C:/Users/*/AppData/Local/Google/Chrome/User Data/*/Extensions/*/*/manifest.json',
'C:/Users/*/AppData/Local/Microsoft/Edge/User Data/*/Extensions/*/*/manifest.json',
'C:/Users/*/AppData/Local/BraveSoftware/Brave-Browser/User Data/*/Extensions/*/*/manifest.json'
]
)
SELECT
ManifestPath,
parse_string_with_regex(
string=ManifestPath,
regex='Extensions\\(?P<ExtID>[a-p]{32})\\').ExtID AS ExtensionId,
parse_string_with_regex(
string=RawManifest,
regex='"name"\\s*:\\s*"(?P<Name>[^"]+)"').Name AS ExtensionName,
RawManifest =~ '"proxy"' AS HasProxyPermission,
RawManifest =~ 'webRequest' AS HasWebRequest,
RawManifest =~ '<all_urls>' AS HasAllUrls,
RawManifest =~ '(?i)vpn|proxy|socks|unblock' AS VpnThemed
FROM manifests
WHERE HasProxyPermission
OR (VpnThemed AND (HasWebRequest OR HasAllUrls))
-- Live connections: browser processes holding sockets to SOCKS5-typical ports
SELECT
Pid,
Name,
Status,
Laddr,
Raddr
FROM netstat()
WHERE Name =~ '(?i)chrome|msedge|brave'
AND Raddr.IP =~ '^[0-9]'
AND Raddr.Port IN (1080, 1081, 8080, 8443)
AND NOT Raddr.IP =~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.)'
Remediation Script
This PowerShell script audits all user profiles on a Windows endpoint for Chromium extensions that (a) request the proxy permission or (b) match VPN/proxy-themed naming, reports them with their extension IDs for Chrome Web Store lookup, and optionally removes flagged extensions. Run it fleet-wide via your RMM or as a scheduled task, then feed the CSV output into your case management.
# Audit-ProxyExtensions.ps1
# Scans all user profiles for Chromium extensions with proxy-control permissions
# or VPN/proxy-themed branding. Reports and optionally removes.
param(
[switch]$Remove, # Actually delete flagged extension dirs
[string]$ReportPath = "C:\ProgramData\ProxyExtensionAudit_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv",
[string[]]$AllowedExtensionIds = @() # Approved extension IDs (e.g. your corporate VPN)
)
$browsers = @(
"$env:SystemDrive\Users\*\AppData\Local\Google\Chrome\User Data",
"$env:SystemDrive\Users\*\AppData\Local\Microsoft\Edge\User Data",
"$env:SystemDrive\Users\*\AppData\Local\BraveSoftware\Brave-Browser\User Data"
)
$results = @()
foreach ($browserPath in $browsers) {
$manifests = Get-ChildItem -Path $browserPath -Recurse -Filter "manifest.json" -ErrorAction SilentlyContinue |
Where-Object { $_.FullName -match '\\Extensions\\[a-p]{32}\\' }
foreach ($m in $manifests) {
try { $raw = Get-Content $m.FullName -Raw -ErrorAction Stop } catch { continue }
$extId = [regex]::Match($m.FullName, 'Extensions\\([a-p]{32})\\').Groups[1].Value
$hasProxy = $raw -match '"proxy"'
$hasWebReq = $raw -match 'webRequest'
$hasAllUrls = $raw -match '<all_urls>'
$vpnThemed = $raw -match '(?i)vpn|proxy|socks|unblock|anonym'
$isAllowed = $AllowedExtensionIds -contains $extId
if (($hasProxy -or ($vpnThemed -and ($hasWebReq -or $hasAllUrls))) -and -not $isAllowed) {
$risk = if ($hasProxy) { 'HIGH' } else { 'MEDIUM' }
$results += [PSCustomObject]@{
Hostname = $env:COMPUTERNAME
UserProfile = ($m.FullName -split '\\Users\\')[1].Split('\\')[0]
ExtensionId = $extId
Risk = $risk
ProxyPermission = $hasProxy
WebRequest = $hasWebReq
AllUrls = $hasAllUrls
VpnThemed = $vpnThemed
ManifestPath = $m.FullName
StoreUrl = "https://chromewebstore.google.com/detail/$extId"
}
if ($Remove) {
$extDir = Split-Path (Split-Path $m.FullName -Parent) -Parent
try {
Rename-Item -Path $extDir -NewName "$extId.QUARANTINED" -Force -ErrorAction Stop
Write-Host "[QUARANTINED] $extId on $env:COMPUTERNAME" -ForegroundColor Yellow
} catch {
Write-Warning "Failed to quarantine $extId : $_"
}
}
}
}
}
if ($results.Count -gt 0) {
$results | Export-Csv -Path $ReportPath -NoTypeInformation
Write-Host "[!] $($results.Count) suspicious extension(s) found. Report: $ReportPath" -ForegroundColor Red
} else {
Write-Host "[OK] No proxy-capable or VPN-themed unapproved extensions found." -ForegroundColor Green
}
# Also check current Chrome proxy configuration for non-policy overrides
$proxyServer = (Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -ErrorAction SilentlyContinue).ProxyServer
if ($proxyServer -and $proxyServer -match 'socks') {
Write-Warning "System-level SOCKS proxy configured: $proxyServer -- investigate immediately"
}
The script renames flagged extension directories to .QUARANTINED rather than deleting them, preserving evidence for IR. Extension IDs flagged as HIGH risk (proxy permission) should be treated as incidents: assume any session active while the extension was installed may be compromised.
Remediation
Immediate (24-48 hours):
- Hunt and remove. Run the KQL/VQL/PowerShell content above across your fleet. Any extension with
proxypermission that is not your sanctioned corporate VPN client is removed and treated as an incident. - Assume session compromise for affected users. Any user with a confirmed fake VPN extension installed must have all active sessions revoked and credentials rotated — starting with SSO, email, and any SaaS accessed through the browser during the exposure window. The proxy operator had a network position to harvest session cookies; cookie theft bypasses MFA at the session layer.
- Block SOCKS5 egress. Deny outbound TCP 1080/1081 (and audit 8080/8443) at the perimeter except from explicitly authorized proxy infrastructure. Chromium browsers have no legitimate reason to speak raw SOCKS5 outbound in most enterprises.
Short term (1-2 weeks):
- Enforce extension allowlisting via enterprise policy. This is the durable fix. For Chrome, use the
ExtensionInstallAllowlist/ExtensionInstallBlocklistpolicies (block*, allow approved IDs). For Edge, the equivalentExtensionInstallAllowList. Deploy via GPO or MDM:- Registry:
HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallBlocklist=*(value "1"), with approved IDs underExtensionInstallAllowlist - Google Workspace admins can enforce this at the browser level via Chrome Enterprise Core cloud management
- Registry:
- Force-install and pin your real VPN/security extensions via
ExtensionInstallForcelistso users aren't searching the store for them — that's how they find the fakes. - Audit the Chrome Web Store developer side. If your brand was impersonated, report clones to Google via the Web Store abuse report channel and monitor for new lookalikes.
Structural (ongoing):
- Treat browser extensions as software. Include them in your asset inventory, change control, and vulnerability management scope. An extension with
proxy+<all_urls>is functionally remote access software. - Monitor for proxy config drift. Alert on any change to
Secure Preferencesproxy mode or system proxy settings outside of policy deployment windows. - Educate users on the specific lure. "Free VPN" in the Chrome Web Store is now a canonical red flag. If users need a VPN, give them one — sanctioned, force-installed, and documented.
There is no patch for this — the abuse is of legitimate extension APIs and store review gaps, not a code flaw. Defense is therefore entirely policy enforcement, egress control, extension auditing, and session hygiene after exposure. Organizations that already enforce extension allowlisting were effectively immune to this campaign; everyone else should treat this as the forcing function to get there.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.