A Firefox add-on can keep the same identity while becoming different software underneath.
That is the sharpest finding in new research from Socket, which tracks 77 extension identities linked through reused code, shared infrastructure, publishing patterns, misleading marketplace descriptions, and version history. The researchers confirmed wallet- or credential-stealing behavior in 40 extensions. Another 37 were deceptive sports-score shells associated with the same broader publishing operation, but their analyzed builds contained no confirmed theft payload.
The distinction matters. So does the bridge between the groups: historical versions of nine confirmed malicious extension identities used sports-score shells before later releases under the same Firefox IDs became wallet stealers.
Continuity of identity became cover for discontinuity of behavior.
The 77-extension corpus is not one undifferentiated malware count: 40 were confirmed malicious, while 37 deceptive shells remain a separate evidence category.
Forty were malicious. Thirty-seven require precision.
The confirmed set divides into several operating models. Seven extensions used remote content controls to deliver phishing interfaces. Fifteen packaged interfaces that captured recovery phrases, private keys, or other wallet secrets. Thirteen modified wallet-derived code to transmit serialized keyring data before local encryption. Five collected credentials and clipboard content through hardcoded command-and-control infrastructure.
Those categories total 40 confirmed malicious extensions. The other 37 matter because of their deceptive functions, repeated publishing artifacts, shared code, clustered signing activity, and links through version history—not because theft was found in every analyzed build.
Socket provisionally calls the activity “Offside Wallet Theft Factory,” but its report does not establish that one actor controlled every extension. That uncertainty should remain intact. The defensible conclusion is narrower: the artifacts indicate a common publishing pipeline or closely related threat actors capable of producing cover applications, cloned wallets, remote phishing loaders, and credential stealers.
This is an artifact story before it is an attribution story.
The version history is the evidence
Extension stores encourage users to read continuity as reassurance. The listing exists. The identifier is stable. An update arrives through the expected channel. Nothing appears to have been sideloaded.
The nine sports-shell-to-malware histories break that mental shortcut. Earlier versions presented sports scores; later versions under the same IDs carried wallet-stealing behavior. A control that recognizes only the extension ID can therefore preserve an allow decision even as the code and purpose change.
That does not make extension IDs useless. They remain essential inventory anchors. But an ID should answer which software object changed, not whether the new version is trustworthy.
Nine confirmed malicious identities had earlier sports-score shell versions, making version transitions a primary detection surface.
Mozilla explains that signing applies basic security checks. Its separate safety guidance is equally important: scanning and possible human review do not guarantee that an extension is absolutely safe. Signing raises the floor. It does not turn future updates into trusted intent.
Low permissions can still deliver a perfect lie
One analyzed extension, “0KX WEB3,” requested only storage and tabs. It contained no working wallet. Instead, it queried a remote configuration and loaded a convincing wallet interface that asked the user to enter a recovery phrase or private key.
The extension did not need permission to search browser storage for secrets. It persuaded the victim to provide them.
Six related variants used byte-identical loader components, and a seventh used a closely related architecture. A remote switch allowed the operator to show a harmless local notepad or activate hosted phishing content without submitting a new extension version.
Permission prompts describe technical access. They cannot measure a workflow designed to manufacture consent.
The confirmed embedded-wallet variants made the problem harder to see. Some preserved expected wallet behavior while copying recovery phrases or serialized keyrings. A functional interface can be more dangerous than a broken counterfeit because success reassures the user while the secret has already crossed the boundary.
Different code paths reached the same security outcome: a wallet secret or credential left the browser under attacker control.
Govern extensions like production software
Extension governance should account for versions, behavior, and business use—not only names and permission counts.
For managed Firefox fleets, Mozilla's ExtensionSettings enterprise policy can block extensions by default and explicitly allow approved IDs. That is a useful boundary, but an allowlist still needs a review process for updates. Record the extension ID, version, publisher, install source, approved use, and population. Alert when a wallet-related extension appears outside that inventory or an allowed extension changes function, ownership signals, requested access, or network behavior.
Network review also needs precision. The campaign abused specific projects and deployments on legitimate hosting platforms. Blocking broad parent domains would create collateral damage and still miss rotated infrastructure. Match exact indicators where available, then combine them with extension identity, version, install events, and unusual outbound activity.
For people who administer valuable self-custodial wallets, reduce the browser's extension set and separate routine browsing from wallet operations where practical. Marketplace presence, familiar branding, user counts, and low permissions are context—not authorization.
Removal is not recovery
If a listed extension was installed, preserve the package, browser extension inventory, relevant network evidence, and install/update timing as operationally feasible without delaying containment. Remove or block the extension, then determine which version ran and whether it reached any known campaign infrastructure.
If a recovery phrase or private key was entered, assume the wallet secret is compromised. Removing the extension stops future execution but cannot revoke knowledge already disclosed. Official wallet guidance recommends creating a wallet with a fresh recovery phrase from a clean browser profile or device, moving remaining assets, and discontinuing use of accounts derived from the exposed phrase. MetaMask's compromise-response guidance also warns that missing transactions cannot simply be reversed.
Where the credential- and clipboard-stealing variants were present, rotate potentially exposed credentials from a clean device and review active sessions and high-risk transactions. Do not use a potentially affected browser to establish the replacement secrets.
Closure depends on what the extension could access: remove the code, investigate the path, and replace any secret that may already be outside your control.
Trust the release, not the label
The campaign did not defeat every browser control. It worked around the assumptions people attach to those controls.
A signature was read as safety. A stable ID was read as continuity. Low permissions were read as low impact. A functioning wallet was read as legitimacy. Each signal contained some truth, but none answered the decisive question: what does this version do now?
Extension security needs the same discipline applied to other production software: version-aware inventory, controlled change, behavioral evidence, scoped access, and a response plan that treats exposed secrets as exposed.
The extension ID stayed put. Trust should not have.