Socket Threat Research has catalogued sixteen Firefox extensions that impersonated cryptocurrency wallets in order to collect recovery phrases and private keys. Mozilla had unpublished all sixteen by 5 October.

The interesting half is how four of them were built.

The real wallet, plus a hook

Four of the extensions were not imitations of Rabby Wallet. They were Rabby Wallet — the full codebase, taken and rebuilt, published under a name that reads as the original at a glance and is not: Raabby WaIIet, with a doubled letter and capital I standing in for lowercase L.

The modification was narrow. The import function — the code that runs when a user pastes a recovery phrase or private key into the wallet to restore it — was hooked, so that the secret was sent out as well as used. The exfiltration went by HTTP GET to endpoints on Cloudflare Workers.

Everything in the extension other than that one hooked function worked exactly as Rabby Wallet does. That is the point of starting from the real thing: it behaves correctly, because it is the correct software. There is no broken screen, no missing feature, nothing that fails in a way a careful user would notice. The only abnormal moment is the one where the user hands over the one secret that matters, which is also the moment the product is supposed to ask for it.

The other twelve were cheaper work: a lighter interface modelled on OKX Wallet's branding, presented as a generic wallet, posting captured seed phrases as JSON to similar Worker endpoints.

Socket links the whole set to a campaign it reported in August, with high confidence, on shared code, shared infrastructure and a common marker string across the builds.

Cloudflare Workers, again

The exfiltration endpoint is the part that should feel familiar if you read yesterday's piece on a botnet that resolves its command server out of a poem hosted on GitHub. Different campaign, different crime, same reasoning.

Traffic to a Cloudflare Workers domain from a browser is traffic to one of the most widely used edge platforms on the internet. It is not going to be blocked at a corporate egress point, it carries a valid certificate, and it reaches a subdomain nobody can distinguish from legitimate application traffic without inspecting content.

We wrote yesterday that the list of services every network must allow out to is short, well known, and being worked through. It is a day later and here is the next entry on it.

Removing the extension does not help

Socket's own guidance is the sentence this site keeps writing: a user who entered a recovery phrase into one of these should treat the wallet as compromised, create a new wallet in a clean environment, and move the assets. Uninstalling does not undo it.

That is worth being precise about, because the intuition is wrong in a specific way. A recovery phrase is not a password on a server that someone can reset. It is the key material from which the wallet's addresses are derived. Once it has been copied, whoever holds it has the wallet, permanently and from anywhere, whether or not the software that leaked it is still installed. There is no revocation. There is only moving the funds somewhere the attacker has no key for, before they do.

This is the fourth time in three weeks the same correction has applied. Packages pulled from npm do not uninstall themselves from the machines that already have them. A Kibana integration deleted after it hijacked a data stream leaves the redirection in place. Delisting an extension stops the next install and nothing else.

Removal is the step that ends distribution. It is persistently mistaken for the step that ends the incident, and the two are not close together.

What the store check cannot catch

It is tempting to read sixteen malicious extensions as a review failure, and partly it is. But consider what review is being asked to do here.

Four of these submissions were a legitimate open-source wallet's source, which reviews cleanly because it is the real thing, with one hooked function somewhere inside it. The name differs from the original by a doubled letter and a glyph substitution that is invisible in most interface fonts. The exfiltration target is a platform that half the web uses.

Catching one hooked function inside a large and otherwise legitimate codebase, reliably, means reading every line of every submission against its upstream, forever. The structural answer is probably not better review but fewer places a secret can be typed — which is the argument for hardware wallets and for wallet software that never asks for a phrase outside a flow the user initiated.

What to do

  • If you restored a wallet in a Firefox extension recently, check what it was called. The impersonations differ from the originals by a character.
  • If you entered a phrase into one of these, move the assets now, from a clean machine, to a wallet generated there. Uninstalling is not a remedy.
  • Install wallet extensions only from the vendor's own link, not from a store search. Search ranking is the attack surface here.
  • For organisations: extension installs are software installs. A browser extension with access to a page has access to what is typed into it.

What is not established

  • How many installs the sixteen extensions had between them, or how many people entered a phrase.
  • How much, if anything, was stolen.
  • Who is behind the campaign, beyond Socket's linkage to its own August reporting.
  • How the four Rabby-derived builds passed review, and whether the hook was present at submission or added in a later version.
  • Whether equivalent builds exist for other browsers.