BlackTree Security · Infrastructure · Automation · AI

The Extension Changed Owners. Its Permissions Did Not.

Users installed a useful browser tool. The browser later delivered malware through the same trusted extension ID.

Socket researchers have identified 18 Chrome extensions and one Microsoft Edge extension carrying a modular malware framework built for wallet draining, credential theft, session abuse and browser-history collection. Five of the extensions had reportedly been acquired from legitimate developers before malicious updates were released to their existing users.

The largest exposed population came from “Enable Right Click & Copy: Smart Unlock + OCR.” Socket says the Chrome version had about 70,000 users when malicious functionality was introduced, while a related Edge version had about 10,000. That is a potential exposure surface of 80,000 users, not a confirmed victim count.

The technical capabilities are serious. The more important platform question is how a change in extension ownership can silently inherit an established product’s permissions, update channel and user trust.

A legitimate install can become tomorrow’s compromise

Chrome normally checks for extension updates at startup and every few hours. That makes the ecosystem easier to maintain and helps security fixes reach users. It also means that an already-installed extension can change substantially without the user making a new installation decision.

Socket separated the campaign into 14 extensions apparently created by the threat actor and five that were bought from legitimate authors:

  • Enable Right Click & Copy: Smart Unlock + OCR
  • RapidLens: Google Lens for Screen Search & Images
  • QuickLens: Search Screen with Google Lens
  • Password Protect PDF
  • Allow Copy: Select & Enable Right Click for Edge

The acquired extensions initially performed their advertised functions. A later version introduced the malicious framework. Users who had assessed the original developer and release were not making a fresh trust decision when the new owner shipped an update.

At the time Socket published its analysis on 27 August, Google had removed the main Chrome extension, while the related Edge listing was reportedly still active. Socket also observed that the Edge version received a new command-and-control domain on 14 August after the Chrome extension had been identified. Store status can change quickly, so administrators should use the extension IDs and network indicators in the original research rather than rely on names alone.

The browser became the execution environment

The extensions used a shared loader and command framework. A background service worker established a persistent WebSocket connection to attacker infrastructure and stored downloaded modules in the extension’s local storage. The command server could rotate endpoints and provide separate exfiltration destinations, making the operation harder to disrupt with a single domain takedown.

Socket found that the extensions registered dynamic browser rules to remove Content Security Policy headers across visited sites. They then injected attacker-provided JavaScript into page contexts using hidden elements and event handlers. This turned broad extension permissions into a reusable execution path inside sites the user opened.

The observed payload set included 16 modules. Capabilities included:

  • A multi-chain wallet drainer targeting EVM, Solana and Tron wallets
  • Full-page Ledger and Trezor seed-phrase phishing
  • Session and account-data collection from cryptocurrency exchanges and wallets
  • A form grabber that captured text, email and password fields across visited pages
  • Facebook and LinkedIn token or session abuse
  • Browser-history exfiltration
  • ClickFix lures that instructed victims to paste and run attacker-supplied commands

One module could replace genuine “Connect Wallet” or “Swap” controls with attacker-controlled handlers. Another imitated Ledger Live or Trezor recovery flows and asked for 12, 18 or 24-word seed phrases. The general form grabber watched input events across pages, giving the framework reach far beyond cryptocurrency sites.

The permissions survived the transfer

Browser extensions occupy an unusual trust position. A modest utility may be allowed to read and change data on every site, modify network requests or run content scripts across logged-in sessions. Once granted, those permissions are attached to the extension identity and travel with its updates.

The user may recognise the extension name, remember that it worked for months and assume the store remains a durable security guarantee. Acquisition breaks that mental model. The software can keep its listing, reviews, install base and extension ID while the party controlling the next release changes.

The campaign also shows why functionality is not proof of safety. DomainTools linked related activity to at least February 2024 and described dual-function extensions that delivered the promised tool while also receiving commands, stealing data or executing code. Malware does not have to replace the product. It can coexist with it.

What organisations should do

Managed browser estates should treat extension ownership and version changes as security events, not just marketplace metadata.

Defenders should:

  1. Inventory Chrome and Edge extensions by ID, version, requested permissions and installation source.
  2. Compare installed IDs with the full list in Socket’s indicators of compromise.
  3. Remove affected extensions and clear associated browser data after preserving evidence required for the investigation.
  4. Review authentication, wallet and exchange activity from affected profiles, then revoke sessions and rotate credentials where exposure is plausible.
  5. Hunt for the published command-and-control domains in DNS, proxy and endpoint telemetry.
  6. Restrict extension installation with enterprise policy and maintain an allowlist for high-risk roles.
  7. Reassess extensions after ownership changes, permission changes or long periods of inactivity followed by a new release.

For higher-risk users, extension governance should include the developer identity and recent change history, not only the extension ID. A previously approved ID is not enough when control of its release channel can be transferred.

Stores need a new trust boundary

Marketplace review remains valuable, but it cannot be the only control. Store operators could make ownership transfers visible to users and administrators, require renewed review for updates following a transfer, and provide enterprise telemetry for publisher changes. Browsers could also prompt again when the identity controlling a privileged extension changes, even if its declared permissions remain the same.

The issue is not that automatic updates are inherently unsafe. It is that an update can preserve the appearance of continuity after the accountable party has changed.

These users did not necessarily install malware. Some installed a legitimate extension that later became the delivery channel. The permissions stayed in place while the trust behind them moved.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *