The loader lives in the background service worker. On the first run after the update it generates an installation UUID and opens a WebSocket to the command and control server [4]. The JavaScript modules that come back are stored in `chrome.storage.local`, encrypted with AES-GCM under a key derived from the extension ID and that installation UUID [5]. That key derivation has a practical consequence for anyone hunting: the stored bytes differ per install, so a hash of module content is not a portable indicator, and the module only exists on machines the C2 chose to answer [18].
The privilege step is a documented API call. The extension registers dynamic `declarativeNetRequest` rules that strip `Content-Security-Policy` response headers from pages the user browses [6]. A content script then sets the malicious code as an event handler on a hidden DOM element, fires the event, and gets execution in the page's main world rather than the extension's isolated world [7]. The two steps compose in one direction: the header strip removes the page-side policy that would otherwise have something to say about injected script running in that main world [19].
An allowlist admits extension IDs. The ID is stable across a sale, the change of ownership is not explicitly notified to users, and the browser updates to the new version automatically, often with no install prompt and no warning [3]. So the control that decides which extensions may run holds no opinion about who now writes them. An allowlist that pins IDs is an excellent defence against the previous owner.
The writeup's recommended controls are ID blocking plus removal of unnecessary high-privilege extensions, an enterprise allowlist with continuous monitoring of ownership and permission changes, network blocks on the listed C2 and exfiltration destinations, user education against ClickFix, and EDR [15]. Rank them by half-life. The domain blocks decay fastest, since the traffic goes to C2 servers or Cloudflare Workers on `.top`, `.pro` and `.sbs` names [12] and fresh names are cheap. The permission diff is the one that lasts, because it fires on the version bump itself instead of waiting for an indicator someone else has to publish. The same reasoning applies to the report's hunting hypothesis about managed browsers holding unnecessary high-privilege extensions [17]: privilege you never granted cannot be inherited by a new owner.
Two of the four preconditions in the report are not the attacker's to arrange. Credential and session theft needs the user on the target page, logged in or typing; recovery-phrase theft, asset transfers and ClickFix execution need the user to follow the prompt [16]. The prompts are built to be followed. Full-screen update and recovery pages appear on the official Ledger and Trezor sites asking for 12, 18 or 24 words [9], and clicking a real Connect Wallet or Swap button routes into a process the attacker swapped in [10]. Where the fake Chrome update prompt lands, the pasted commands run locally on the device, outside the browser entirely [11].
The material names 19 targeted extensions [8] without giving the IDs here, so it does not close a ticket. What it does specify is the query worth writing: a per-device extension inventory joined to version history and to the permission set each version requested.
