GreedyBear - How 150+ Malicious Firefox Wallet Extensions Stole $1M in Crypto

GreedyBear - How 150+ Malicious Firefox Wallet Extensions Stole $1M in Crypto

In early August 2025 researchers uncovered a large-scale campaign — dubbed GreedyBear — that weaponized over 150 Firefox browser extensions to impersonate popular crypto wallets. The campaign used a method called Extension Hollowing to build apparent trust before flipping extensions into credential-stealing malware, resulting in more than $1 million in stolen digital assets. This post dissects the technique, the attack chain, the broader implications for browser extension trust models, and practical defenses for security engineers and analysts.

Background

Researchers at Koi Security (reporting by Tuval Admoni) and independent analysts (including Lukasz Olejnik) documented the campaign in a disclosure published on August 8, 2025. The threat actors created publisher accounts in the Firefox add-on marketplace and uploaded hundreds of benign-looking extensions with minimal or no functionality. Over time they accumulated fake positive reviews and built reputational credibility. At scale — more than 150 extensions — the adversary later updated the extensions to include malicious code that impersonated widely used wallets such as MetaMask, TronLink, Exodus and Rabby, intercepting wallet credentials and siphoning funds to attacker-controlled addresses. The reported theft exceeds $1 million in crypto assets.

Technical Analysis

Attack vector and technique — Extension Hollowing. Instead of attempting to smuggle obviously malicious code through review gates, the attackers used a two-stage lifecycle:

  1. Bootstrapping phase: create publisher accounts and upload innocuous extensions (low functionality, no network callbacks). Post fake reviews and maintain benign behavior to pass marketplace heuristics and build user installs.
  2. Weaponization phase: push an update that injects credential-capturing logic, exfiltration endpoints, and telemetry collection. Because the extension already had an established install base and positive reviews, users and the marketplace were less likely to suspect the update.

Key technical components observed and expected in this campaign:

  • UI impersonation: the extension overlays or replaces wallet UI flows to capture secret phrases, private keys, or seed inputs typed into browser UI.
  • Content script interception: content scripts hook DOM events on known wallet provider sites or on injected dapp frames to harvest credentials and transaction approvals.
  • Network exfiltration: harvested secrets and metadata (IP addresses, user agent) are POSTed to attacker-controlled endpoints. The campaign reportedly gathers IPs for tracking and follow-up targeting.
  • Persistence and stealth: the malicious functionality is delivered as an update, reducing the chance of detection by initial static analysis or manual review.

Simple depiction of the flow:

Publisher account -> benign extension uploaded -> positive reviews & installs -> extension update -> malicious content scripts capture secrets -> exfiltrate to C2 -> funds drained

Why Firefox extensions are a desirable target. Browser extensions run with elevated DOM and network privileges relative to normal web pages. Wallet extensions are particularly high-value: they mediate signing operations and contain seed material. A compromised wallet extension can sign transactions, export keys, or trick users into approving malicious transfers.

Impact & Implications

The GreedyBear campaign has several broad implications:

  • Supply-chain trust erosion: The campaign shows that marketplace reputation (install counts, reviews) can be gamed and later weaponized. Organizations and users who rely on these signals are at risk.
  • High-value theft vector: Attacking wallets is a direct route to financial theft with irreversible outcomes for victims.
  • Scale and automation: Using many small publisher accounts and dozens-to-hundreds of extensions makes detection by marketplace-wide heuristics harder and raises the bar for remediation.
  • Implications for enterprises: Developers and SOC teams that allow browser extensions in managed environments need to treat extension updates as potentially risky events, similar to software supply-chain updates.

Defensive Recommendations

Security engineers, developers, and incident responders should treat browser extensions (especially those related to crypto, SSO, or developer tooling) as high-risk software supply-chain components. Recommended actions:

  1. Enterprise policy & allowlisting: enforce an extension allowlist through group policy or enterprise browser management. Disallow user installs of unapproved extensions in sensitive environments.
  2. Monitor extension updates: track version changes for installed extensions centrally. Flag updates that introduce network endpoints, new host permissions, or content scripts that touch wallet-related origins.
  3. Least privilege for extensions: prefer extensions that request the minimal necessary permissions. Block extensions that request broad host access (e.g., "http://*/").
  4. Detect suspicious behavior: create detections for extensions that intercept DOM events on wallet pages, inject script tags into web3 frames, or POST seed/seed-related patterns to unknown external domains. Network monitoring of telemetry to unusual endpoints is critical.
  5. Harden developer/operational hygiene: educate users to prefer hardware wallets or custodial solutions for large balances; never enter seed phrases into browser prompts or non-official UI; treat wallet extension updates with the same scrutiny as OS or browser updates when funds are at stake.
  6. Marketplace engagement: report malicious extensions to the browser vendor and coordinate takedowns. Security teams should use vendor reporting channels and consider automated signals to inform marketplaces about suspicious mass updates originating from the same publisher cluster.
  7. Post-compromise response: if an extension compromise is suspected, remove the extension, rotate keys / move funds (if possible), and audit transaction approvals. For wallet compromise where keys are exposed, assume funds are unrecoverable and act quickly to move remaining assets to a hardware wallet or a new wallet whose seed was generated offline.

Conclusion

GreedyBear demonstrates a pragmatic adversary approach: manipulate marketplace trust signals over time, then trigger malicious functionality at scale. For defenders, the lesson is that supply-chain trust is brittle — reputation metrics are insufficient on their own. Treat extensions as first-class components in your threat model, instrument update monitoring, and enforce allowlists in managed environments. For crypto users, assume that any browser-hosted wallet is a potential risk and use hardware wallets or other air-gapped key storage for significant holdings. Finally, fast, coordinated reporting to browser vendors and transparency from marketplaces about publisher provenance are essential to reduce the window of exposure for similar campaigns in the future.