A conference-targeted phishing chain installs a self-regenerating rogue root CA plus a hosts-file/firewall local proxy that fabricates clean HTTPS results for any domain, surviving reboot

A Huntress researcher was targeted after DEFCON by an X account impersonating a CoinDesk marketing executive, who sent a legitimate Google Doc carrying a custom Google Apps Script sidebar (Huntress Labs, 2026-08-19). The sidebar runs client-side with no OAuth consent prompt; per Huntress's own recap of the incident, merely opening the document while signed in, no click, no download; was enough for it to silently report the viewer's public IP address, geolocation, browser, and whether a MetaMask, Phantom, Tron or Solana wallet extension was installed, beaconing every action through the Telegram Bot API (Huntress Labs, 2026-09-15), a reconnaissance and victim-qualification step requiring no interaction at all. A fake "decryption failure" overlay then delivered OS-specific ClickFix remediation instructions, each offering a choice between pasting a clipboard command or downloading a file manually. On macOS, the pasted command launched a piped zsh chain that never actually delivered a payload in Huntress's own testing, the fetched URL looped through repeated redirects until the browser gave up, so the actor's evident intent for that path went unconfirmed; the manual-download option instead led to a disk image bundling its own Gatekeeper-bypass instructions and password prompt, and running it delivered a confirmed AMOS-family stealer harvesting browser, crypto-wallet, Telegram, Apple Notes, cookie and login-keychain data, plus a LaunchDaemon-installed backdoor capable of arbitrary remote commands and of turning the host into a SOCKS5 proxy. On Windows, pasting the ClickFix command launched an encoded PowerShell command that fetched a loader which pulled down three further payloads; by the time Huntress analyzed the kit all three had already gone offline, and their existence is known only because copies had reached VirusTotal; no certificate or further technical detail on this particular set was recoverable. Windows victims who instead chose the manual download were led down an entirely separate route: the same fake decryption-failure message told them to update a "Google API Connector," an application signed with a certificate belonging to a small Norwegian company (either stolen or fraudulently issued) that deployed via abuse of Microsoft's ClickOnce feature, the first of the three stolen code-signing certificates Huntress recovered across the whole campaign.

In a later message, the same actor sent a second document link, this time via DropBox DocSend, that routed macOS victims to another host serving the same AMOS payload and told Windows victims to install a DocSend-branded desktop installer signed with a second stolen certificate, from Discord Inc., whose signature did not validate (Huntress Labs, 2026-08-19). That installer's own DocSend flow was itself a non-functional distraction, a five-screen fake onboarding carousel using genuine Dropbox marketing pages that installed nothing. Per Huntress's own recap, the firm reconstructed the sample's own command-and-control registration protocol from its bundled @sentry/electron module and queried the live infrastructure directly (Huntress Labs, 2026-09-15), recovering three payload archives this way: Manager.zip (NetSupport Manager), Localcertificate.zip (a TLS-intercepting local proxy) and asusdriverld.zip (a Ledger-wallet implant), each downloaded encrypted, launched detached and hidden, then relaunched twenty seconds later with an elevation request. The first, NetSupport Manager (a legitimate remote-monitoring tool reconfigured to redirect data to attacker infrastructure and disable its own chat/connect/disconnect alerts) carries persistence for all three payloads: a kernel-mode keyboard-filter driver, a Windows service, a Winlogon modification and its own registered COM object (Huntress Labs, 2026-08-19). The third, the Ledger-wallet implant, reuses the second payload's disguise and technique.

The most novel component is that second payload, the TLS-intercepting local proxy itself: disguised as a Lenovo driver package and signed with a genuine stolen Lenovo certificate, the third of the three abused code-signing certificates, after the Norwegian and Discord ones, it hollows MsBuild.exe and generates its own self-signed certificate authority presenting itself as "Google Trust Services CN=WR3" plus a fabricated www.virustotal.com leaf certificate, installs that CA into the system root store, adds a hosts-file entry and a local-proxy firewall rule, and thereby locally answers HTTPS connections with fabricated "clean" results and no certificate warning for any domain the operator chooses, crypto-wallet sites, antivirus update checks, or anything else (Huntress Labs, 2026-08-19). Because the certificate authority is regenerated per infected host, blocking a specific certificate thumbprint achieves nothing. The interception process itself dies at reboot, but the installed root CA, the hosts-file entry and the firewall rule all persist across reboots untouched.

Triage: a locally-installed root CA is not automatically malicious; some legitimate enterprise MDM and TLS-inspection proxies do this deliberately. The discriminator is provenance: a root CA your own PKI/MDM inventory does not recognize as provisioned by it, especially one impersonating a well-known public CA's name, is the signal; one your MDM issued is not.