737 Malicious Chrome VPN Extensions Caught Proxying User Traffic — Detection, Hunting, and Removal Guide

A newly disclosed campaign has put a hard number on a problem many of us in IR have been quietly tracking for years: 737 free VPN and proxy extensions, published across at least 40 Chrome Web Store developer accounts, were caught intercepting user browser traffic and routing it through attacker-controlled proxy infrastructure. Collectively, these extensions racked up 75,486 installs, and at least 274 of them impersonated 66 legitimate, well-known VPN brands to build false trust with victims.

The targeting is deliberate and telling: the campaign primarily goes after Russian-speaking users trying to reach services blocked in their region — people who are actively searching for free VPN tools and are willing to grant broad browser permissions to get them. That is exactly the user population least likely to scrutinize an extension's permission prompt and most likely to install something outside a managed enterprise policy.

For defenders, this is not a "consumer problem." Corporate users install browser extensions on managed endpoints every day. A malicious VPN extension with proxy, webRequest, or tabs permissions is a man-in-the-middle sitting inside your user's browser — it can read session cookies, capture credentials entered into SaaS portals, inject content into encrypted sessions after TLS termination, and exfiltrate everything through infrastructure that looks like ordinary HTTPS egress. If your web filtering and DLP controls assume the browser is a trusted endpoint, this campaign breaks that assumption.

This post breaks down how the campaign works, what is actually observable on the endpoint and network, and gives you production-ready hunting content to find and evict these extensions.

Technical Analysis

What the Campaign Does

Based on the published reporting, the operation has several defining characteristics:

• Scale and distribution: 737 distinct extensions spread across at least 40 developer accounts on the Chrome Web Store. Fragmenting across dozens of publisher identities is a classic resilience tactic — a takedown of one developer account does not kill the campaign.
• Brand impersonation: 274 of the extensions impersonate 66 legitimate VPN providers, cloning names, logos, and descriptions to ride on the reputation of trusted tools.
• Victim targeting: The lures are aimed at Russian-speaking users seeking access to geo-blocked or state-blocked services. Lure pages and store listings are localized accordingly.
• Core malicious behavior: Once installed, the extensions intercept browser traffic and route it through a proxy infrastructure controlled by the operators. From a capability standpoint, this means the actors can observe, log, and potentially modify every request and response passing through the browser — including authenticated sessions.

Why Malicious "VPN" Extensions Are So Dangerous

A desktop VPN client routes traffic at the OS network layer, where EDR, firewalls, and network monitoring can at least see the tunnel endpoint. A browser extension VPN operates entirely inside the browser process using Chrome's extension APIs:

1. Permission grant at install time. The extension requests permissions such as proxy, webRequest / webRequestBlocking, tabs, storage, and host permissions like <all_urls> or *://*/*. Most users click through.
2. Traffic redirection via the chrome.proxy API. The extension registers a PAC script or fixed proxy configuration that forces some or all browser traffic through the operator's proxy servers.
3. Post-decryption visibility. Because the interception happens inside the browser, the extension sees plaintext after TLS is handled. HTTPS provides zero protection against this.
4. Exfiltration and monetization. Captured traffic, session tokens, and credentials can be harvested, resold, or used to resell proxy bandwidth — victim machines effectively become exit nodes in someone's proxy network.

Exploitation Status

This is confirmed active abuse in the wild, not a theoretical risk: the extensions were live on the official Chrome Web Store, accumulated over 75,000 installs, and were actively proxying real user traffic. No CVE is associated with this campaign — it abuses Chrome's legitimate extension APIs by design, which is precisely what makes it hard to kill with a patch. The fix is detection, policy, and removal, not a version update.

Enterprise Exposure Model

The realistic enterprise exposure scenarios:

• BYOD and unmanaged profiles: Users signed into personal Chrome profiles on corporate machines, syncing malicious extensions into the work environment.
• Shadow IT circumvention: Employees installing "free VPN" extensions to bypass geo-restrictions or corporate web filtering.
• Credential theft against SaaS: Session cookies for M365, Google Workspace, and internal portals pass through the proxy — enabling session replay without ever touching the endpoint's credential stores.

Detection & Response

The observable artifacts for this threat cluster in four places: extension files on disk, Chrome policy registry keys, Chrome command-line arguments, and network egress from the browser process to proxy infrastructure. The rules below target those surfaces.

SIGMA Rules

---
title: Chrome Launched With Explicit Proxy Server Argument
id: 8c2e5f41-3a97-4d62-b1c8-7e9a0f2d4b56
status: experimental
description: Detects chrome.exe launched with command-line arguments forcing traffic through a proxy server or PAC script. Malicious VPN/proxy extensions and their installers sometimes enforce proxying via launch flags in addition to extension APIs.
references:
  - https://thehackernews.com/2026/08/737-chrome-vpn-extensions-caught.html
  - https://attack.mitre.org/techniques/T1090/
author: Security Arsenal
date: 2026/08/10
tags:
  - attack.command_and_control
  - attack.t1090
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\chrome.exe'
  selection_cli:
    CommandLine|contains:
      - '--proxy-server='
      - '--proxy-pac-url='
      - '--proxy-bypass-list'
  condition: selection_img and selection_cli
falsepositives:
  - Enterprise environments that deliberately launch Chrome with proxy flags for testing or legacy app compatibility
level: high
---
title: Chrome Extension Force-Install or Settings Policy Modified
id: 2f7a9c15-6d38-4b91-a5e3-0c4d8f6a1b92
status: experimental
description: Detects registry modifications to Chrome ExtensionInstallForcelist or ExtensionSettings policies, which can be abused to silently install or pin malicious extensions such as rogue VPN/proxy tools.
references:
  - https://thehackernews.com/2026/08/737-chrome-vpn-extensions-caught.html
  - https://attack.mitre.org/techniques/T1176/
author: Security Arsenal
date: 2026/08/10
tags:
  - attack.persistence
  - attack.t1176
logsource:
  category: registry_set
  product: windows
detection:
  selection:
    TargetObject|contains:
      - '\Policies\Google\Chrome\ExtensionInstallForcelist'
      - '\Policies\Google\Chrome\ExtensionSettings'
  filter_chrome_updater:
    Image|endswith:
      - '\GoogleUpdate.exe'
      - '\msiexec.exe'
  condition: selection and not filter_chrome_updater
falsepositives:
  - Legitimate GPO-driven extension deployment in managed environments
  - Chrome enterprise management tooling
level: medium
---
title: Browser Process Connecting to Common Proxy Service Ports
id: 5d1b8e73-9f24-4a06-c7d2-3e6b0a9f5c18
status: experimental
description: Detects chrome.exe establishing outbound connections to ports commonly used by proxy and SOCKS services. Free VPN/proxy extensions frequently route intercepted traffic through infrastructure listening on these ports.
references:
  - https://thehackernews.com/2026/08/737-chrome-vpn-extensions-caught.html
  - https://attack.mitre.org/techniques/T1090.002/
author: Security Arsenal
date: 2026/08/10
tags:
  - attack.command_and_control
  - attack.t1090.002
logsource:
  category: network_connection
  product: windows
detection:
  selection_img:
    Image|endswith: '\chrome.exe'
  selection_port:
    DestinationPort:
      - 1080
      - 3128
      - 8080
      - 8888
      - 9090
  condition: selection_img and selection_port
falsepositives:
  - Corporate environments using explicit forward proxies on 8080/3128 (scope these destinations out)
  - Local development proxies such as Burp Suite on 8080
level: medium

KQL — Microsoft Sentinel / Defender

The following query hunts for two complementary signals: Chrome processes making outbound connections to proxy-service ports to non-corporate destinations, and Chrome processes launched with explicit proxy flags. Run it against Defender endpoint telemetry; extend the port and flag lists to match infrastructure indicators as they are published.

let ProxyPorts = dynamic([1080, 3128, 8080, 8888, 9090]);
let BrowserNames = dynamic(["chrome.exe", "msedge.exe", "brave.exe"]);
let NetworkHits =
    DeviceNetworkEvents
    | where TimeGenerated > ago(7d)
    | where InitiatingProcessFileName in~ (BrowserNames)
    | where RemotePort in (ProxyPorts)
    | where not(RemoteIP startswith "10." or RemoteIP startswith "192.168." or RemoteIP startswith "172.16.")
    | summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
                ConnectionCount=count(), RemoteIPs=make_set(RemoteIP, 20),
                Ports=make_set(RemotePort)
        by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
    | extend Signal = "Browser-to-Proxy-Port Egress";
let FlagHits =
    DeviceProcessEvents
    | where TimeGenerated > ago(7d)
    | where FileName in~ (BrowserNames)
    | where ProcessCommandLine has_any ("--proxy-server=", "--proxy-pac-url=")
    | summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), LaunchCount=count(),
                CommandLines=make_set(ProcessCommandLine, 10)
        by DeviceName, FileName, AccountName
    | extend Signal = "Browser Launched With Proxy Flag";
union NetworkHits, FlagHits
| order by LastSeen desc

Velociraptor VQL — Extension Permission Audit

The highest-fidelity forensic check is enumerating every installed Chrome extension across all user profiles and flagging manifests that request the permission set associated with traffic interception. This artifact parses manifest.json files and returns extensions holding proxy, webRequest, or wildcard host permissions — the exact capability set these malicious VPN extensions need to function.

-- Hunt Chrome extensions requesting traffic-interception permissions
LET manifests = SELECT FullPath
FROM glob(globs='C:/Users/*/AppData/Local/Google/Chrome/User Data/*/Extensions/*/*/manifest.json')

SELECT FullPath,
       parse_json(filename=FullPath).name AS ExtensionName,
       parse_json(filename=FullPath).version AS Version,
       parse_json(filename=FullPath).permissions AS Permissions,
       parse_json(filename=FullPath).host_permissions AS HostPermissions
FROM manifests
WHERE Permissions =~ '(?i)proxy|webRequest|webRequestBlocking|declarativeNetRequest'
   OR HostPermissions =~ '(?i)<all_urls>|\*://\*/\*'

Also hunt active connections from the browser to non-standard proxy infrastructure:

-- Chrome processes with established connections to common proxy ports
SELECT Pid, Name, CommandLine, "Laddr" AS LocalAddress, "Raddr" AS RemoteAddress, Status
FROM netstat()
WHERE Name =~ 'chrome'
  AND Status =~ 'ESTAB'
  AND RemoteAddress =~ ':(1080|3128|8080|8888|9090)$'

Remediation Script — Extension Audit and Flagging

This PowerShell script enumerates every Chrome extension across all profiles on a machine, scores each by risky permission set (the capabilities required to proxy and inspect traffic), and produces a report. Run it fleet-wide via your RMM or as a Velociraptor/Intune remediation. Extensions scoring High that are not on your approved list should be treated as malicious until proven otherwise.

# Chrome Extension Permission Audit — flags extensions capable of traffic interception
$ReportPath = "$env:ProgramData\ExtensionAudit_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv"
$RiskyPerms = @('proxy','webRequest','webRequestBlocking','declarativeNetRequest','declarativeNetRequestWithHostAccess','tabs','cookies')
$RiskyHosts = @('<all_urls>','*://*/*','http://*/*','https://*/*')
$Results = @()

$UserDirs = Get-ChildItem 'C:\Users' -Directory -ErrorAction SilentlyContinue
foreach ($User in $UserDirs) {
    $ProfileRoot = Join-Path $User.FullName 'AppData\Local\Google\Chrome\User Data'
    if (-not (Test-Path $ProfileRoot)) { continue }
    Get-ChildItem $ProfileRoot -Directory -ErrorAction SilentlyContinue |
        Where-Object { $_.Name -eq 'Default' -or $_.Name -like 'Profile *' } |
        ForEach-Object {
            $ExtRoot = Join-Path $_.FullName 'Extensions'
            if (-not (Test-Path $ExtRoot)) { return }
            foreach ($ExtId in (Get-ChildItem $ExtRoot -Directory -ErrorAction SilentlyContinue)) {
                $Manifest = Get-ChildItem $ExtId.FullName -Recurse -Filter 'manifest.json' -ErrorAction SilentlyContinue |
                            Select-Object -First 1
                if (-not $Manifest) { continue }
                try { $M = Get-Content $Manifest.FullName -Raw | ConvertFrom-Json } catch { continue }
                $Perms = @($M.permissions) + @($M.host_permissions)
                $MatchedPerms = $Perms | Where-Object { $RiskyPerms -contains $_ }
                $MatchedHosts = $Perms | Where-Object { $RiskyHosts -contains $_ }
                $Score = 0
                if ($MatchedPerms -contains 'proxy') { $Score += 3 }
                if ($MatchedPerms -match 'webRequest') { $Score += 2 }
                if ($MatchedHosts) { $Score += 2 }
                $Rating = if ($Score -ge 5) { 'High' } elseif ($Score -ge 3) { 'Medium' } else { 'Low' }
                $Results += [PSCustomObject]@{
                    User        = $User.Name
                    Profile     = $_.Name
                    ExtensionId = $ExtId.Name
                    Name        = ($M.name -replace '__MSG_\w+__','(localized)')
                    Version     = $M.version
                    Permissions = ($Perms -join ';')
                    RiskScore   = $Score
                    Rating      = $Rating
                    Path        = $ExtId.FullName
                }
            }
        }
}

$Results | Sort-Object RiskScore -Descending | Export-Csv $ReportPath -NoTypeInformation
Write-Host "[+] Audit complete. $($Results.Count) extensions enumerated. Report: $ReportPath"
$Results | Where-Object Rating -eq 'High' | Format-Table User, Name, ExtensionId, RiskScore -AutoSize

# To remove a confirmed malicious extension (per profile), delete its directory and Preferences entry:
# Remove-Item -Recurse -Force 'C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\Extensions\<extension_id>'

Remediation

There is no patch for this threat — it abuses Chrome's legitimate extension architecture. Remediation is a policy, hygiene, and takedown problem:

1. Inventory and remove immediately. Run the audit script (or the VQL artifact) across your fleet. Cross-reference discovered extension IDs against community-published IOC lists for this campaign. Remove anything flagged High that isn't on your approved software list, and force a sign-out of active SaaS sessions for affected users — assume session cookies transited the proxy.
2. Enforce an extension allowlist. Chrome Enterprise supports the ExtensionSettings policy with installation_mode: allowed for unapproved extensions, and ExtensionInstallAllowlist / ExtensionInstallBlocklist for coarser control. Move from blocklist (default-allow) to allowlist (default-deny). This single policy change kills this entire attack class going forward.
3. Block proxy-port egress. If your environment uses an explicit forward proxy, browsers have no legitimate reason to connect outbound to 1080/3128/8080/8888 on arbitrary internet hosts. Block at the perimeter and alert on attempts — the Sigma rule above becomes near-zero-noise.
4. Rotate credentials for confirmed victims. Any user with a confirmed malicious VPN extension installed should have passwords rotated and all active sessions revoked for corporate SaaS (M365, Google Workspace, VPN/SSO portals). Token theft via proxied sessions bypasses password controls entirely.
5. Disable profile sync on managed devices or scope Chrome sign-in to corporate identities, preventing personal-profile extensions from bleeding into the work environment.
6. Report residual store listings. Google removes reported extensions, but this campaign's 40-account structure means attrition is slow. Report malicious listings via the Chrome Web Store abuse flow and share extension IDs with your ISAC.

Analyst Takeaways

• Treat any extension holding proxy + broad host permissions as a potential MITM by default. That permission combination has almost no legitimate use outside a small set of vetted enterprise tools.
• Extension-based interception defeats TLS visibility assumptions — your network stack sees clean HTTPS to the proxy, while the extension sees plaintext. Endpoint-level extension auditing is the only reliable control.
• This campaign's victim targeting (users seeking blocked services) means your highest-risk population is employees trying to circumvent controls. Pair technical enforcement with an acceptable-use conversation, or they will find the next 737 extensions.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub