16 Malicious Firefox Extensions Steal Cryptocurrency Wallet Credentials

What it is

Two distinct Firefox extension families from Socket's analysis: a Rabby Wallet clone family ("Raabby WaIIet" — note the misspelling, with author listed as "Debrunk") and an OKX Wallet-impersonating "Portal WALLET" family. The existing summary covers counts and exfiltration endpoints; this adds the mechanism, detection fields, and IOC-level specifics needed to actually hunt or respond.

How it works

The Rabby clones hook importPrivateKey, createKeyringWithMnemonics, and mnemonic/account import paths with an injected function self._lv that accepts only 12/24-word strings or 64-char hex private keys, deduplicates in memory, URL-encodes the secret, and GETs it to the Worker with mode: "no-cors", keepalive: true (falling back to XMLHttpRequest on fetch failure). A second helper in 977.js duplicates collection at UI-level import paths, tagging requests action: ui vs action: import — meaning a single secret entry can generate multiple exfil requests.

The OKX clones post a SEED_PHRASE_IMPORT runtime message (legacy alias WALLET_SYNC) containing the raw phrase, which background scripts validate (12/24 words, non-empty, deduplicated) before transmission. One variant uses a three-stage fallback: navigator.sendBeacon, fetch POST with no-cors/keepalive, then an image-pixel GET — its code comments falsely claim only a hash and word count leave the device, but the payload field w carries the raw phrase (an FNV-1a hash is computed only for dedup, not sent instead).

All exfil requests share four JSON/query fields: a (action), s (campaign marker EQOx7EIPZSNi), k (login), w (the raw secret).

flowchart TD
    A[User imports wallet secret] --> B{Extension family}
    B -->|Rabby clone| C[self._lv hook fires on import functions]
    B -->|OKX clone| D[SEED_PHRASE_IMPORT message to background.js]
    C --> E[GET with secret in URL query, XHR fallback]
    D --> F[POST JSON, or sendBeacon+fetch+pixel fallback chain]
    E --> G[icy-star-f45c.workers.dev]
    F --> G
    F -.broken variant.-> H[fondationanimalaidrelief.workers.dev]

Preconditions / Affected

One extension, sipoo-grozza@browserweb.com (v2.1), is non-functional as packaged: its manifest omits the background declaration so background.js never loads, and even if manually triggered, the frontend sends SEED_PHRASE_IMPORT while the packaged background only handles WALLET_SYNC. All manifests falsely declare data_collection_permissions.required = ["none"]. As of October 5, 2026, Mozilla has unpublished all 16 extensions.

What to do

Static/network detections given by the page:

• Flag the string Raabby WaIIet and message types SEED_PHRASE_IMPORT/WALLET_SYNC near raw seedPhrase handling.
• Match JSON/GET fields a, s, k, w, t with s=EQOx7EIPZSNi, k=login — but redact field w before logging, since it carries the raw secret.
• Check extension inventories against the five listed background.js/frontend SHA-256 hashes and the 16 extension ID/XPI hash pairs.
• Search proxy/DNS logs for the three Worker namespaces under icy-star-f45c.workers.dev plus fondationanimalaidrelief.workers.dev.
• For affected users: assume compromise if a real phrase/key was entered into any functioning variant — password changes don't revoke a stolen mnemonic; create a new wallet from a clean environment and move assets/revoke approvals immediately.

Caveats

The page explicitly cautions that upstream Rabby/DeBank hosts (api.rabby.io, static.debank.com, etc.) retained in the clone's code are inherited legitimate infrastructure, not campaign IOCs, and should not be blocked. It also notes the extensions' broad content-script/webRequest permissions exceed what's needed for the observed secret theft, but states no separate form-grabber behavior was confirmed — so broader browsing-data theft is flagged as a risk, not a proven finding.