2026-09-21 · view entry permalink →
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.
VIEW is the one worth sitting with. Opening the document while signed in, clicking nothing, and downloading nothing, was enough to report the viewer's IP address, location, browser, and whether they were running a crypto wallet extension.
It hollowed MsBuild.exe and imported only kernel32, ultimately establishing what Jon called "purpose-built and working public key infrastructure on your machine."
Because the CA was regenerated per host, blocking a single certificate thumbprint does nothing.