Forty Malicious Firefox Extensions Ran a Five-Month Supply-Chain Campaign Against Crypto Wallets

A single browser extension ecosystem has been quietly compromised for nearly half a year. On March 2025, Socket's security team identified 40 Firefox add-on identities with confirmed malicious behavior. Nine of those identities had previously distributed harmless sports score tools. The version history is clear: each ID started benign, accumulated users, then flipped to malware. This is not a zero-day exploit. This is supply-chain poisoning executed with patience. Extension-based attacks represent a distinct threat vector in crypto. The user's browser is the last mile between their intent and the blockchain. Every DApp interaction, every signature request, every wallet connection passes through this layer. Compromise this layer and you bypass all the security built into the underlying protocols. The attack does not break the cryptography. It breaks the trust boundary the user relies on to reach the network. Socket's analysis reveals a deliberate and modular attack framework across the 40 malicious identities. Seven were remote-controlled phishing loaders. Fifteen captured recovery phrases, private keys, or other wallet secrets directly. Thirteen were modified clones of the Rabby wallet — serialized key strings were sent to attacker infrastructure before local encryption could occur. Five collected credentials and clipboard data. These are not random malware samples. They are a coordinated toolkit designed to intercept different types of users through different attack paths. The most significant detail is the tactical evolution. This is version two of extension-based wallet theft. Previous campaigns relied on users directly installing malicious extensions from phishing sites or deceptive ads. This campaign used a reputation-first approach. The developers published legitimate sports score tickers — the kind of utility tool a user installs without a second thought — and waited. The waiting period matters. Chrome and Firefox stores accumulate trust signals over time, including user installs, ratings, and review history. An account with months of benign behavior passes through the automated review filters that would flag a freshly registered extension requesting broad permissions. The timeline is consistent with an organized operation. From March to August 2025, the malicious versions remained live. The attacker or attackers sustained a multi-month campaign across at least nine distinct extension IDs, each with its own update path. This is not a single disgruntled developer. This is resource-intensive, methodical execution. From my audit and infrastructure analysis experience, the production pipeline behind these extensions points to tooling. Generating variants of the same malicious payload, applying different obfuscation layers, and managing the update channels for nine separate store listings simultaneously requires automation. The manual workload would be error-prone and slow. Automated build scripts and C2-driven payload updates are the standard approach for maintaining this kind of operation at scale. Mozilla has since responded with a statement acknowledging the use of automated risk indicators and manual review processes to identify malicious wallet extensions. The company advises users to install extensions only from the official websites of wallet providers. The recommendation is technically sound for the immediate case, but inadequate as a systemic solution. Browser extension stores are centralized distribution channels with a near-total dependence on heuristic filtering. The store review process is not a security audit. It never has been. The volume of submissions makes deep manual verification economically impossible at scale. The practical takeaway for users is more difficult to accept. Any recovery phrase, private key, or wallet key string that has come into contact with a malicious version must be considered compromised. Uninstalling the extension does not roll back the exposure. There is no remedy beyond generating a new wallet, transferring all assets, and treating the old seed phrase as permanently burned. A counter-intuitive aspect of this attack is how little the technical execution mattered. The malware itself harnesses nothing groundbreaking. The stealth and extraction mechanisms are well-known. The adversarial innovation here was entirely in trust amortization — the ability to turn the extension store's own trust mechanisms into the delivery channel. The attacker's familiarity with browser ecosystem heuristics and user psychology was the decisive factor. This is a critical blind spot in the broader security conversation. The technical vulnerability is trivial. The systemic vulnerability is the trust infrastructure itself. Socket has not confirmed specific victims, attributable transactions, or the total value lost on-chain. The absence of confirmed losses is not evidence of limited losses. It is a strong signal that the operation integrated high-quality obfuscation and likely automated the fund exfiltration process. Private keys and recovery phrases, once extracted, move through a variety of privacy mixers and cross-chain bridges in minutes. Recovery is theoretically possible with accurately configured chain analysis tooling, but practically implausible in most cases without early intervention. A secondary implication involves the broader wallet ecosystem. The Rabby wallet clone component is significant. Rabby is a popular wallet among institutional and power users, which means the target selection specifically favored higher-balance accounts. The modified clone functioned identically during ordinary use — until the user initiated a transaction or viewed their portfolio within a window that triggered the serializer. The event exposes a deeper systemic risk across browser-based Web3 infrastructure. Platform-level review is a trust heuristic, not a security guarantee. Code signing through store identities provides authenticity, not safety. Delegating wallet security to the distribution platform's diligence was always a risk assumption. This attack demonstrates that the assumption has been exploited. The expected progression here is the increased marketing emphasis on hardware wallets and browser-native wallets. Both circumvent the extension risk surface. Hardware wallets isolate private keys from the signing environment entirely. Browser-native wallets are controlled by the browser vendor directly, reducing third-party extension permissions. A user migration toward these alternatives does not solve every threat model, but it reduces the exposed surface area. Browser vendors will face pressure to implement stronger code audits and more granular permission monitoring for extensions. The trade-off is velocity. Security hardening always imposes drag on ecosystem flexibility. Independent developers and smaller privacy-focused extensions will carry the regulatory and technical cost of that shift. This incident was a marker. The operation confirmed a playbook that will be reused — and it will be copied. Compromise a trusted utility, wait for the user base to accumulate, push the malicious update, and automate the extraction. One point of comfort remains: the attack's success depended on the platform's failure to detect a version-level tamper. The network itself was never at risk. The protocols held. The user-facing interface layer failed. Verify the proof, ignore the hype. Code is law, but bugs — and malicious code — are reality.