A researcher at Socket found 16 malicious Firefox extensions posing as Rabby Wallet and OKX Wallet, built specifically to capture recovery phrases and private keys and send them to attacker-controlled infrastructure. The extensions were taken down on October 5, 2026, but the campaign is a continuation of an earlier wave documented in August, and it is not an isolated incident. Over the past year, security researchers have flagged similar extension clusters across Chrome, Edge, and Firefox, targeting crypto wallets, AI assistant sessions, and browser traffic generally.
For business readers, the headline is not "crypto theft." It is that browser extensions remain one of the least monitored entry points into a company's environment, and this campaign shows how cheaply and quickly attackers can scale it.
How the malicious Firefox extensions operated
According to The Hacker News, the 16 extensions masqueraded as wallet portals, desktop utilities, and browser tools. Four cloned Rabby Wallet; the rest cloned OKX Wallet. The malicious code intercepted recovery phrases and private keys during the wallet import flow and exfiltrated them to Cloudflare Workers domains, mostly a single *.icy-star-f45c.workers.dev address.
What stands out is the operational discipline behind it. The threat actors rotated extension names, version numbers, extension IDs, and descriptions between releases, while reusing the same wallet interface, the same credential-handling logic, and the same backend infrastructure. That is a deliberate evasion strategy: each individual listing looks new to store review systems and to users, even though the underlying theft mechanism is unchanged.
A wider pattern of malicious Firefox extensions and lookalikes
Socket's researchers noted this pattern connects to a string of other browser extension abuses reported in recent months, including:
- A fake "ID-Pay" Firefox extension that injected JavaScript into the real Google accounts login page to steal session cookies.
- A cluster of 32 Chrome and Edge extensions, attributed to a Korean-speaking group, that silently redirected active browser tabs using remotely fetched configuration.
- Roughly 30 extensions impersonating well-known financial personalities to redirect victims to wallet phishing pages, while deliberately skipping English-language users and sandboxed analysis environments.
- 31 Russian-language Chrome extensions sold as VPNs for blocked services that instead routed all browser traffic through attacker-controlled proxies.
- A "Stylish" Chrome extension that intercepted ChatGPT, Gemini, Perplexity, Character.AI, and GitHub Copilot conversations and forwarded them to its operator.
- A "Poper Blocker" ad-blocking extension that downloaded and executed commands from a C2 server, in violation of Chrome's Manifest V3 restrictions.
None of these required a user to click a phishing link or open a suspicious attachment. The entry point was a browser extension marketplace that most employees treat as trustworthy by default.
Why malicious Firefox extensions matter even if nobody holds crypto
If your company does not touch cryptocurrency, it is tempting to file this under "not our problem." That would be a mistake for two reasons.
First, the technique generalizes. Recovery-phrase theft works because the malicious code sits inside the browser, watching form fields and clipboard activity during a specific workflow. The same mechanism can target SSO login pages, payment processor dashboards, or any SaaS admin console where a password or API token gets typed in. The ID-Pay extension example above proves this: it targeted Google account cookies, not crypto at all.
Second, extension stores do not reliably catch this before damage is done. These listings lived on the Firefox Add-ons store, a curated marketplace, not some obscure third-party site. Review processes catch obvious malware signatures; they do not reliably catch code that behaves normally until a specific trigger (a wallet import screen, a login form) appears.
For companies that do hold treasury funds in crypto wallets, or whose finance team interacts with exchanges like OKX, the exposure is direct: a compromised recovery phrase means funds can be moved out instantly, with no chargeback and no recovery path.
What we recommend doing this week
Treat this as a prompt to run a browser extension audit across the company, not just a one-time read-and-forget news item.
- Inventory installed extensions across every managed device, including personal laptops used for work through BYOD policies. Most IT teams have never done this for browsers the way they do for installed software.
- Remove anything unused or unverified. If nobody can explain why an extension is installed, it should not be installed.
- Separate wallet and treasury activity onto a dedicated, locked-down browser profile with no extensions beyond the wallet's own official one, verified against the vendor's published ID.
- Never type a recovery phrase into any browser-based interface unless you initiated the import yourself from a known, verified source. Legitimate wallet software rarely needs it typed into a web form at all.
- Deploy extension allow-listing in managed browser policies (Chrome Enterprise, Firefox Enterprise policies) rather than relying on marketplace review alone.
- Add browser extension telemetry to your monitoring stack. Behavior-based detection, flagging extensions that make outbound calls to newly registered domains, catches rotation-based campaigns like this one that signature-based tools miss.
This is the same discipline we apply when we build out cybersecurity services for clients: start with an inventory of what is actually installed and running, then layer monitoring on top, rather than buying a tool first and hoping it covers the gap.
The trade-off worth naming
Locking down extensions and browser profiles adds friction. Finance and ops staff who are used to installing a convenience extension whenever they want one will feel the change, and some legitimate productivity tools will get swept up in a stricter allow-list policy. That friction is the cost of closing a gap that, as this campaign shows, keeps getting exploited at scale. We have found it easier to accept that trade-off on a small number of high-risk roles first, treasury, finance, and anyone with admin access to payment systems, rather than rolling it out everywhere at once.
If your business runs any part of its operations through API integration services or exposes admin dashboards to a distributed team, the same audit logic applies beyond the browser: know what has access, verify it regularly, and assume marketplace vetting alone is not enough.
