737 Fake VPN Extensions Are Spying on Chrome Users Right Now

737 Fake Chrome VPN Extensions Exposed: How SOCKS5 Proxy Hijacking Put 75,000+ Users' Browser Traffic at Risk

Picture this: you're a security-conscious user in a region where half the internet is blocked. You search "free VPN Chrome extension," find one with a slick popup, a familiar-looking logo, and glowing reviews. You click Connect. The icon turns green. You feel safe.

You just handed your entire browsing session — every destination, every unencrypted password, every TLS handshake — to a stranger's server.

That's exactly what happened to more than 75,000 Chrome users caught up in one of 2026's largest browser extension impersonation campaigns. Researchers at Socket's Threat Research Team uncovered 737 fake VPN and proxy extensions, spread across at least 40 Chrome Web Store developer accounts, quietly rerouting victims' entire browsing sessions through attacker-controlled SOCKS5 infrastructure — while pretending to be trusted names like Proton VPN, NordVPN, Surfshark, ExpressVPN, and even Cloudflare's 1.1.1.1.

This isn't a theoretical risk. It's a live, ongoing campaign, and as of this writing, hundreds of these extensions are still listed on the Chrome Web Store. Let's break down exactly how it works, what the indicators of compromise look like, and how SOC teams and everyday users can detect and shut this down.

Table of Contents

• What Happened: The Core Discovery
• How the SOCKS5 Hijack Actually Works
• Brand Impersonation and the Fake Premium Trick
• Who's Behind It: The Myxa VPN Connection
• Indicators of Compromise (IOCs)
• Detection: How to Check If You're Affected
• Prevention & Hardening Recommendations
• Expert Tips from the SOC Trenches
• Related Articles
• FAQ
• Conclusion

What Happened: The Core Discovery

Socket's researchers pulled and analyzed 525 of the 737 flagged extensions in bulk. Of the 522 packages they could fully inspect, 520 configured Chrome's proxy settings to route all traffic through a fixed SOCKS5 server on port 1082 — controlled entirely by the campaign operators.

The numbers alone tell the scale of this:

• 737 total extensions identified
• 40+ distinct Chrome Web Store developer accounts used to publish them
• 75,486 combined installs at time of discovery
• 516 extensions still live when the dataset was collected; 221 already removed by Google
• 274 extensions directly impersonated 66 real, established VPN and privacy brands

The primary targets were Russian-speaking users trying to reach blocked platforms — Instagram, YouTube, and ChatGPT among them — searching for a way around regional restrictions and instead walking straight into a mass surveillance funnel.

How the SOCKS5 Hijack Actually Works

Here's the technical core, and it's deceptively simple. Legitimate VPN extensions do use Chrome's chrome.proxy.settings API to route traffic — that's normal, expected behavior for a browser-based VPN. The malicious twist here is what these extensions did with that access.

Each extension set a hardcoded, fixed SOCKS5 proxy configuration pointing to attacker-controlled infrastructure. The bypass list — the set of addresses that should not go through the proxy — contained only loopback addresses like 127.0.0.1 and localhost.

That means the moment a victim clicked "Connect," every single browser tab and request — not just the site they wanted to unblock — got funneled through the operator's relay. No split tunneling. No exceptions. Total traffic capture.

This puts the proxy operator in a textbook adversary-in-the-middle (AitM) position, able to observe:

• Every destination domain the victim visited
• TLS SNI (Server Name Indication) values, revealing which sites were accessed even over HTTPS
• The victim's real source IP address
• The complete, unencrypted contents of any plain HTTP request — including credentials typed into non-HTTPS login forms

To make matters harder to track and block, 104 of the extensions resolved their proxy hostnames using encrypted DNS-over-HTTPS (DoH) — via Cloudflare or Google's resolvers — before handing Chrome a raw IP address. This sidesteps traditional DNS-based blocking and monitoring, since there's no plaintext DNS query for defenders to catch.

Socket was careful to note an important nuance: their analysis covered client-side code only. They confirmed the extensions gave the operator the technical capability to intercept and read traffic — they did not claim to have proof of what was actually logged, stored, or exfiltrated server-side. For a SOC analyst, that distinction matters: capability-for-abuse is still a critical finding, even without confirmed data theft.

Sample Detection Command: Auditing Chrome Proxy Extensions

If you're triaging a fleet of endpoints and want to check which extensions have proxy-modifying permissions, you can pull the installed extension manifest data on Windows with PowerShell:

Get-ChildItem -Path "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Extensions" -Recurse -Filter "manifest.json" | Select-String -Pattern '"proxy"'

What it does: Recursively scans installed Chrome extension manifests for any that declare the proxy permission.
When to use it: During endpoint triage or a fleet-wide extension audit, especially after a suspicious network behavior alert.
Expected output: A list of manifest.json file paths that contain the proxy permission string — cross-reference these extension IDs against the IOC list below.

Brand Impersonation and the Fake Premium Trick

Copying a trusted brand's name is an old trick, but this campaign layered on additional social engineering that's worth breaking down for anyone doing user awareness training.

Investigators found 200 advertised "premium" server locations across 40 domains that simply didn't resolve — meaning users could pay for a subscription tier promising servers in Japan, Singapore, Canada, Australia, or Turkey that never actually existed. One extension even displayed a polished, convincing connection animation while being coded to fail every single connection attempt behind the scenes.

On top of that, several listings included Chrome Web Store review-justification documents explicitly claiming "no data is sent to external servers" — a direct contradiction of the proxy-routing code sitting right inside the extension package. Socket found identical copies of this misleading document (matching SHA-256 hash) reused across multiple extension submissions, suggesting a templated, assembly-line approach to getting past Google's review process.

This is classic trust exploitation: familiar branding + a functioning-looking UI + a written promise of privacy = a victim who has no reason to suspect anything is wrong.

Who's Behind It: The Myxa VPN Connection

Socket tied the campaign together using a mix of evidence: shared analytics identifiers, synchronized domain registrations, common hosting infrastructure, identical code-generation markers, and — critically — leaked build artifacts.

Several extension packages contained an embedded Windows build path revealing the developer's working directory structure, referencing a folder named myxa-work. Combined with domain naming patterns (myxavpn[.]pro, getmyxa[.]com, vpn-myxa[.]ru) and a 12-digit taxpayer identification number found in billing infrastructure, researchers assess this points to a Russian VPN subscription business operating under the brand Myxa VPN (Муха VPN).

Subscription pricing started as low as 99 roubles per month — cheap enough to look like a legitimate budget VPN service, while the underlying business model appears to be funneling victims into a paid proxy relay they never actually agreed to trust with their traffic.

It's worth noting: this evidence supports common operational control across the extension network. It does not establish state sponsorship or definitively identify a specific individual — attribution in cases like this rarely reaches that level of certainty from OSINT and code analysis alone.

Indicators of Compromise (IOCs)

Below is a condensed IOC set for SOC teams to load into SIEM, firewall, and DNS blocklists. Full extension ID lists run into the hundreds — use these as seed indicators and pivot from there.

Type	Indicator	Notes
Chrome Extension ID	aaeiefggdeljohngedhpmgidkjcdoebb	Myxa VPN — flagged by Socket's AI scanner
Chrome Extension ID	aabaifmlfkdolhdbbhjblkeekaijfdfh	Part of campaign cluster
Chrome Extension ID	abjgfdfbmmijjdfbohbhgdnjeipjbplj	Part of campaign cluster
Chrome Extension ID	ilpcglpcfdeoehcmjhkfhhgpldgfgjhj	Marketed as "Burёnka VPN"
Domain	myxavpn[.]pro, app[.]myxavpn[.]pro	Billing dashboard infrastructure
Domain	getmyxa[.]com, myxavpn[.]com, vpn-myxa[.]ru	Core campaign infrastructure
Domain (pattern)	*.space TLD cluster (atlasvpn, cloudmask, ironproxy, skyproxy, etc.)	Proxy/landing infrastructure tier — high volume of lookalike domains
Nameserver	ns1[.]reg[.]ru, ns2[.]reg[.]ru	Shared across campaign domain estate
IP Address	212[.]192[.]14[.]75	Hosts a large set of campaign domains
IP Address	147[.]45[.]60[.]241, 178[.]130[.]47[.]43-129 range	SOCKS5 relay infrastructure
IP Address	185[.]252[.]215[.]97-98, 194[.]150[.]220[.]163	SOCKS5 relay infrastructure
File Name	vpn-bez-limita.zip	Archived prior build embedded in a live package
Hardcoded Credential	myxavpn2024secret	Weak premium-token verification secret
Proxy Port	1082/TCP	Consistent SOCKS5 port across 520 of 522 analyzed extensions

Note: Domains and IPs above are defanged with [.] notation. Only re-fang them inside a controlled threat intel platform (MISP, VirusTotal, your SIEM) — never in a browser.

Detection: How to Check If You're Affected

1. Open Chrome's extension manager (chrome://extensions) and review every installed VPN, proxy, or "unblock websites" extension — especially ones offering free or unusually cheap premium tiers.
2. Check active proxy configuration at chrome://net-internals/#proxy or Chrome Settings → System → Open your computer's proxy settings, and look for unfamiliar SOCKS5 entries, particularly on port 1082.
3. Cross-reference installed extension IDs against the IOC table above and Socket's full published list.
4. For enterprise environments: query your endpoint management or browser management console (Chrome Enterprise, Intune, etc.) for any extension with the proxy permission declared in its manifest, then compare against your approved extension allowlist.
5. Watch DNS logs for DoH usage patterns from browser processes reaching out to Cloudflare (1.1.1.1) or Google (8.8.8.8) DoH endpoints immediately before a new outbound SOCKS5 connection appears — this is the DoH-evasion pattern used by 104 of the extensions.

Prevention & Hardening Recommendations

For Individual Users

• Remove any suspected extension immediately, then restart the browser.
• Manually verify Chrome's proxy settings are reset to "Direct" or your legitimate configuration.
• Change any passwords you entered on non-HTTPS sites while the extension was active — assume those credentials were exposed.
• Only install VPN extensions directly from the vendor's official website link, never from a Chrome Web Store search result alone — impersonation listings routinely outrank or sit beside the real ones.
• Prefer paid, audited VPN providers with published no-logs audits over "free unlimited VPN" extensions in general — the economics of a truly free VPN rarely work out in the user's favor.

For SOC Teams & Enterprises

• Inventory all browser extensions across managed endpoints with proxy, webRequest, or declarativeNetRequest permissions.
• Push extension allowlisting via Chrome Enterprise policies (ExtensionInstallAllowlist/ExtensionInstallBlocklist) rather than relying on users' judgment.
• Block the domains and IPs in the IOC list at both DNS and network egress layers — remember that DoH resolution bypasses DNS-only controls, so egress filtering at the firewall level is essential.
• Alert on unexpected chrome.proxy.settings API calls in browser telemetry if you have EDR/XDR tooling with browser visibility.
• Include this campaign's TTPs in your next phishing/security awareness training cycle — browser extension abuse is an underrated initial access vector compared to email phishing.

Expert Tips from the SOC Trenches

• Don't trust the "Verified" badge blindly. Extensions can pass Google's automated review and stay live for weeks — Proton has publicly stated it's reported fake extensions impersonating its brand to Google three separate times this year alone.
• Remote configuration is a red flag. 66 extensions in this campaign pulled remote settings post-install, meaning an approved, "safe-looking" extension can change its behavior later without a store update — treat any extension with remote-config capability as a standing risk, not a one-time approval decision.
• A green "Connected" indicator proves nothing. UI state and actual network behavior are two separate things — always verify proxy settings independently rather than trusting the extension's own status display.
• Cross-reference install counts against reviews. Extensions with thousands of installs but suspiciously generic or templated five-star reviews are a common pattern across these campaigns.

Related Cybersecurity Topics You Should Explore

• GhostDesk Spyware Alert: Fake CCleaner Steals Passwords & Crypto
  
• Zoomsday Flaw: Hackers Hijack Zoom Users With Zero Clicks
  
• SonicWall SMA1000 Flaws Now Fuel Ransomware Attacks – CISA Warns
  
• HP ThinPro's 'Encrypted' Drives Aren't Actually Safe — Here's Why
  
• GRR Rapid Response: The Free Google Tool That Hacks 100K PCs Remotely
  
• One Failed Login, Full Server Takeover: WordPress XSS2Shell
  
• I Traced a Webshell Using Just 6 Linux Commands — Here's How
  
• How a Fake Movie File Can Empty Your Bank Account in Seconds
  
• CaptiveCrunch: How Russian Hackers Turned Hotel Wi-Fi Into a Weapon
  
• CVE-2026-12935: The TP-Link Bug Every Router Owner Should Fix Now
  
• Adform Hack Turns Trusted Ad Script Into a Crypto Stealer
  
• The Security Story Hidden Inside Windows 11's Big Update

FAQ

Q1: Were any of these fake extensions found on the Chrome Web Store's "Featured" or "Recommended" listings?
No evidence in Socket's report indicates official Google curation or featuring — the extensions relied on brand-name search matching and paid/organic discoverability rather than any Google endorsement.

Q2: Does using HTTPS protect me even if I have one of these extensions installed?
Partially. HTTPS encrypts the content of your traffic, but the proxy operator can still see your destination domains via TLS SNI, your source IP, and connection metadata — full content exposure is limited to plain HTTP traffic.

Q3: Is this the same as a classic malware infection?
Not exactly. This is better classified as deceptive traffic interception through a legitimate browser API (chrome.proxy.settings) rather than a traditional malware payload — but the practical risk to user data is comparable.

Q4: How do I know if 1082 is the specific proxy port being used on my machine?
Check chrome://net-internals/#proxy or your OS-level proxy configuration for any SOCKS5 entry, and note the port number. Port 1082 is the specific indicator tied to this campaign, though operators can change ports in future variants.

Q5: Are Edge, Firefox, or other Chromium-based browsers affected?
This specific campaign targeted the Chrome Web Store. However, any Chromium-based browser (Edge, Brave, Opera) that supports the same extension APIs and installs from the Chrome Web Store could theoretically load the same malicious packages — always verify extensions regardless of browser.

Q6: What should I do if I already entered banking credentials while connected?
Change your banking password and any reused credentials immediately, enable multi-factor authentication if not already active, and monitor your account statements closely for the next several weeks.

Conclusion

This campaign is a reminder that the most dangerous threats aren't always exotic zero-days — sometimes they're a browser permission most users never think twice about, wrapped in a trusted brand's logo. 737 extensions, 40+ developer accounts, and 75,000+ installs later, the takeaway for both individual users and SOC teams is the same: verify before you trust, and audit what's already installed.

If you manage browser security for an organization, now's the time to run that extension audit — not after the next headline. Got questions about hardening your extension policy or spotted an IOC match in your environment? Drop a comment below or share this with your SOC team.