SURIQ
A browser extension you installed last year can turn hostile tonight without you touching it. That is the uncomfortable lesson from a campaign the application security firm Socket calls Superior: 19 Chrome and Edge extensions that shipped clean, earned real installs and reviews, then pushed an update that emptied cryptocurrency wallets and swept up saved logins. The interesting question is not how these passed the store's checks. It is why the trust you grant an add-on at install never expires, even after the code, and sometimes the owner, has quietly changed.
Socket published its analysis this week, and BleepingComputer and The Hacker News confirmed the details. The count is 18 Chrome extensions plus one on Edge, and the researchers date the operation to February 2024. That two-year runway is the point: this was patient, not opportunistic.
How a clean extension becomes a wallet drainer
Two paths lead to the same place. Fourteen of the extensions were built by the operator from the start. The other five were bought from the people who originally made them, then poisoned. Either way the playbook is identical: publish a working, malware-free version, wait while installs and good reviews pile up, then ship an update that Chrome installs on its own. Socket put the economics plainly, and they are what should worry you: an add-on with 10,000 users can change hands for less than $2,000. That is a market for pre-earned trust, and it is the same resale-of-trust problem we flagged when malicious npm packages hid a stealer in their install scripts. A package registry and a browser store are both supply chains, and both let a trusted component go bad after you have already accepted it.
Inside the poisoned update
The malicious build behaves the same across the family, which is what makes it detectable. On startup it registers a dynamic declarativeNetRequest rule that removes the Content-Security-Policy header on every site the user opens, clearing the path for injected scripts to run in the page. It then opens a WebSocket back to a command-and-control server and keeps the channel alive with a heartbeat every five minutes. From there Socket documented a wallet drainer that hits EVM-compatible chains, Solana and Tron by hijacking wallet-connection buttons, seed-phrase phishing that imitates Trezor and Ledger prompts, session and credential theft across exchanges including Coinbase, Binance, Kraken and MetaMask, browser-history exfiltration, and fake update prompts in the ClickFix style. This is the same class of in-browser credential theft we covered with malware that rode a live browser session, delivered this time by software the user chose to install.
The gap store review cannot close
Store review is an install-time gate. It inspects the version in front of it and signs off. The auto-update path that ships the next version is not held to that same scrutiny, and users are never told when an extension changes owner. So the real trust boundary is not the store listing. It is the publisher's identity over time, and no store surfaces that to the person clicking Add. We saw a narrower version of this trust gap when a browser extension reached across origins it had no business touching; here the abuse arrives through the update channel instead of a permission.
Removal from one store does not end it. According to Socket, after Google pulled the malicious Chrome versions, a fresh Edge build of the most-installed extension went live on August 14, 2026 with a new C2 domain, and the Edge listing stayed available after the Chrome one came down. Same code, two review regimes, two independent clocks. A defender who reads "Google removed it" and stops has left Edge users exposed.
Watch the behavior, not the domain
Socket listed 20 C2 domains, and blocking them is worth doing, but on its own it is a losing game: the operators rotated to a new domain the same week Google acted. The durable signals survive a domain change because they describe what the malware does, not where it calls. An add-on that strips security headers on every page at startup, holds open an outbound WebSocket, or injects handlers into pages it has no reason to touch is behaving like this family no matter which server it reaches. That is a hunt worth running against your browser and endpoint telemetry, and a steady outbound callback to an unfamiliar host is exactly the kind of pattern a monitoring desk triages, independent of any indicator list.
The stronger control is policy, and it is yours to set in the browser's own enterprise management, not something to leave to user judgment. Force-install an allowlist of vetted extension IDs, block sideloading, and treat any change to an extension's version, permissions, or publisher as an event worth a look. User vetting cannot catch a post-install ownership transfer, because the thing the user vetted is not the thing that later runs.
Move the crypto and revoke approvals before you hunt
If you ran any of the flagged extensions, order matters. Move cryptocurrency to a newly created wallet and revoke outstanding token approvals first, because a drainer that already holds your session will not wait for you to finish an audit. Then change passwords on exchange and wallet accounts, remove the extension from every browser you use it in (Chrome and Edge are separate installs with separate exposure), and pull your full extension inventory to see what else carries broad permissions. For a team, publish the allowlist policy now. The individual audit is the cleanup; the policy is the fix.