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.
Key points
- McAfee Labs has named an active clipper campaign "Silent Swap" that swaps destination wallet addresses inside the victim's browser the moment a transaction is initiated.
- Delivery starts with unsigned .NET or Golang installers, typically disguised as productivity tools and spread through SEO-poisoned download portals.
- The dropped extension masquerades as a note-taking add-on and injects a content script that watches for wallet addresses in the DOM and clipboard.
- Attacker-controlled addresses are pulled from a remote server, so seizing one wallet does not kill the campaign.
- The only control that survives an in-browser adversary is verifying the destination address on a hardware wallet screen, not inside Chrome.
How does Silent Swap get onto a machine?
The delivery chain starts off-browser. Unsigned installers, observed in .NET and Golang variants, masquerade as productivity tools and arrive 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. SmartScreen and Defender flag the installer inconsistently depending on signing-status caching, so some victims get no warning at all.
What does the extension actually do?
The extension presents itself, when a user checks 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. When a user copies or pastes a BTC, ETH or LTC address 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. Clipper malware keeps working precisely because it exploits that gap.
Should you worry about the persistence mechanism?
Yes, and it tells you something about the target population. Force-installed extensions land via the ExtensionInstallForcelist policy under HKLM\Software\Policies\Google\Chrome and the Edge and Brave equivalents. That key should not be writable by a normal user-mode installer on a properly configured endpoint. Auditing that registry path, plus chrome://policy, will surface the rogue extension faster than EDR will.
This campaign fits a pattern we have tracked since mid-June. Our 17 June report on a clipper crew abusing sponsored news placements and our 18 June story on a Windows clipper worm routing its C2 over Tor both documented unsigned-installer delivery to the same general victim profile. Silent Swap adds browser policy abuse to that playbook.
What should defenders do right now?
Block unsigned installer execution at the policy layer. WDAC or AppLocker rules requiring Authenticode signatures stop both variants before they run: unsigned by design, because signing costs money and burns infrastructure. For consumer endpoints without that luxury, the practical detection signal 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. The abused mechanisms, force-install policies and content scripts, are working as designed.
If you run a crypto desk or handle treasury transactions from a general-purpose workstation, verify the destination address on the hardware wallet screen, not the browser. A Ledger or Trezor displays the address on its own screen. The clipper cannot touch that.
