Silent Swap: Unsigned Installers Drop Fake Chromium Extensions That Hijack Crypto Transactions
McAfee Labs documents a clipper campaign using .NET and Golang loaders to sideload a malicious browser extension that rewrites wallet addresses at send time.

Researchers at McAfee Labs have detailed an active clipper campaign, dubbed Silent Swap, that swaps destination wallet addresses inside the victim's browser the moment a transaction is initiated.
The delivery chain starts off-browser. Victims pick up unsigned installers — observed in both .NET and Golang variants — typically masquerading as productivity tools and pushed through SEO-poisoned download portals. Once executed, the installer drops a Chromium-compatible extension and force-loads it via command-line flags or registry policy keys, bypassing the Web Store entirely.
The extension itself is presented to users (when they bother to check chrome://extensions) as a benign note-taking add-on resembling Google Keep. Under the hood it injects a content script into every page and watches for wallet-shaped strings in the DOM and clipboard.
That's the clipper logic. When a user copies a BTC, ETH, SOL, TRX or LTC address — or pastes one into a send field — the script substitutes an attacker-controlled address of the same format. The swap happens after the user's last visual check, which is the whole point of clipper malware and the reason it keeps working.
McAfee says the addresses are pulled dynamically from a remote server, so seizing one wallet doesn't kill the campaign. Telemetry points to victims across multiple regions, with the unsigned-installer stage flagged by SmartScreen and Defender inconsistently depending on signing-status caching.
A few operational notes for defenders.
The persistence mechanism is the interesting bit. Force-installed extensions land via the ExtensionInstallForcelist policy under HKLM\Software\Policies\Google\Chrome (and the Edge/Brave equivalents). That key shouldn't be writable by a normal user-mode installer on a properly configured endpoint — which tells you something about the target population. Auditing that registry path, plus chrome://policy, will surface the extension faster than EDR will.
Block unsigned installer execution where you can. WDAC or AppLocker policies that require Authenticode signatures will stop both the .NET and Golang variants at the door (they're unsigned by design — signing costs money and burns infrastructure). For consumer-grade endpoints without that luxury, the practical detection is the policy key write itself.
McAfee has not published IOCs in a machine-readable feed at time of writing, but the writeup includes installer hashes and the extension ID pattern. No CVE is assigned; this is a malware campaign, not a product vulnerability, and the abused mechanisms (force-install policies, content scripts) are working as designed.
If you run a crypto desk or handle treasury transactions from a general-purpose workstation, the mitigation hasn't changed in five years: verify the destination address on the hardware wallet screen, not the browser. The clipper can rewrite what your eyes see in Chrome. It cannot rewrite what a Ledger or Trezor displays on its own screen.
That verification step is the only control that survives an in-browser adversary.



