How Malicious Firefox Add-ons Hijack Crypto Wallets Through Deceptive Updates

The relevant question for anyone holding wallet-connected state in a browser is not whether the storefront looked legitimate at install time. It did. It is whether any of the four distinct exfiltration paths reached a key, phrase, or serialized keyring.

Anatomy of the Exfiltration

The campaign Socket provisionally labels "Offside Wallet Theft Factory" linked 77 add-on identities; 40 carried confirmed theft behavior, the remaining 37 were sports-score shells with no confirmed payload in the analyzed versions. The 40 split into four technical profiles, and each one neutralizes a different assumption about wallet safety.

Seven operated as remote-controlled phishing loaders, capable of swapping UI on demand. Fifteen captured recovery phrases, private keys, or wallet secrets directly through form interception. Thirteen were modified clones of Rabby wallet that transmitted serialized keyrings before local encryption could protect them; a serialized keyring exposes the full account state of a wallet, not just one signature. Five collected credentials and clipboard data, a lower tier but still a viable input-sniffing layer for address-substitution attacks.

Of the nine IDs with sports-score origins, the historical record shows clean utility distributions that pivoted into crypto-targeting behavior. Signing records ran from March 9 through Aug. 3, with activity clustering in April and late July. One remote-controlled phishing ID, 0KX WEB3, was live with seven users during analysis; Mozilla removed it before publication. Socket did not attribute confirmed victims or a campaign loss total.

Practical Posture for a Compromised Browser

A browser extension sits in the trust boundary above the wallet. It can read form inputs, intercept clipboard events, and call wallet APIs. Uninstalling the extension does not revoke any secret that was already transmitted. The remediation logic follows the attack path.

For the 15 secret-capture cases and the 13 Rabby-clone cases, the wallet itself must be considered compromised at the protocol level. Move remaining assets to a fresh wallet generated from a new recovery phrase on a clean device session. Do not import the old seed into the new environment to "check" balances; that re-exposes the secret. Replay the conclusion: a recovery phrase or serialized keyring that reached an attacker is permanent, and rotation is the only mitigation.

For the five credential-and-clipboard cases, the threat is narrower. Change passwords on any account whose credentials touched the compromised browser, terminate active sessions where the platform supports it, and verify any destination address copied during the exposure window against the intended recipient. Clipboard-rewrite attacks on crypto addresses are a known technique and one paste can reroute funds silently.

For anyone who installed but did not interact with any of the 40, the operative check is the Mozilla add-on manager: confirm whether the ID is still listed, and assume any extension that requested broad permissions during install was reading page content by default. Mozilla's stated tooling is automated risk indicators plus human review, and the official guidance is to install extensions only via links from the wallet provider's own site. That guidance collapses a meaningful surface area; the add-on marketplace is, on this evidence, a shallow trust boundary, and the supply chain is the actual perimeter.

The binary verdict: for wallets whose keys or keyrings entered one of these add-ons, treat the wallet as burned. The protocol does not offer a recall.