A conference-targeted phishing chain installs a rogue root CA generated fresh on every host, plus a hosts-file/firewall local proxy able to fake clean VirusTotal results and to mint trusted certificates 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 · Huntress Labs, 2026-09-15). The sidebar runs client-side with no OAuth consent prompt, and merely opening the document while signed in, with no click or download, was enough for it to 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 API (Huntress Labs, 2026-09-15). A fake "decryption failure" overlay then delivered OS-specific ClickFix instructions, each offering a choice between pasting a command or downloading a file manually (Huntress Labs, 2026-09-15). On macOS, the pasted command launched a piped zsh chain that never delivered a payload in Huntress's testing, because the fetched URL looped through redirects. The manual download led to a disk image bundling its own Gatekeeper-bypass instructions and password prompt, which 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 (Huntress Labs, 2026-08-19 · Huntress Labs, 2026-09-15). On Windows, one path launched an encoded PowerShell command that fetched a loader, which pulled down three further payloads that were offline by the time Huntress looked but already on VirusTotal (Huntress Labs, 2026-09-15). The other told the victim to update a "Google API Connector", an application signed with a certificate belonging to a small Norwegian company (stolen or fraudulently issued) and deployed through Microsoft's ClickOnce feature, the first of three abused code-signing certificates in the campaign (Huntress Labs, 2026-08-19 · Huntress Labs, 2026-09-15).

Contradiction: Huntress's two pieces assign the Windows paths differently. The 2026-08-19 write-up says the update button launches the ClickOnce installer and the manual path shows ClickFix-style instructions with an encrypted PowerShell script (Huntress Labs, 2026-08-19). The 2026-09-15 recap assigns ClickOnce to the manual download and the encoded PowerShell command to the ClickFix lure (Huntress Labs, 2026-09-15).

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). The installer's DocSend flow was a non-functional distraction: a five-screen fake onboarding carousel using genuine Dropbox marketing pages that installed nothing. Huntress reconstructed the sample's command-and-control registration protocol from its bundled @sentry/electron module and queried the live infrastructure of a sibling campaign directly (Huntress Labs, 2026-09-15), recovering three payload archives this way: NetSupport Manager, a TLS-intercepting local proxy and a Ledger-wallet implant. Each was downloaded encrypted, launched detached and hidden, then relaunched twenty seconds later with an elevation request. The first, NetSupport Manager, is a legitimate remote-monitoring tool reconfigured to redirect data to attacker infrastructure and disable its own chat, connect and disconnect alerts, and it 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. Disguised as a Lenovo driver package and signed with a genuine stolen Lenovo certificate, the third abused code-signing certificate, it hollows MsBuild.exe, generates its own self-signed certificate authority presenting itself as "Google Trust Services CN=WR3", issues a www.virustotal.com leaf certificate from it, installs the CA into the system root store, adds a hosts-file entry pointing www.virustotal.com at the local machine and creates a local-proxy firewall rule (Huntress Labs, 2026-08-19). VirusTotal lookups from the host then reach a local proxy that answers over fully validating HTTPS and can block them or return fabricated results. VirusTotal was the only target Huntress observed, but the CA's private key is written to disk, so a trusted certificate can be minted for any domain at will (Huntress Labs, 2026-08-19). A Huntress researcher named crypto-wallet domains and antivirus update signals as targets the operator could intercept the same way (Huntress Labs, 2026-09-15). Because the certificate authority is regenerated per infected host, blocking a specific certificate thumbprint achieves nothing. The interception process dies at reboot, but the installed root CA, the hosts-file entry and the firewall rule persist (Huntress Labs, 2026-09-15).

Triage: a locally-installed root CA is not automatically malicious, since some legitimate enterprise MDM and TLS-inspection proxies do this deliberately. The discriminator is provenance: a root CA your own PKI or 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.