If you’ve ever built a server, diagnosed a thermal issue, or just wanted a quick look at what’s running under the hood, you’ve probably reached for CPU-Z or HWMonitor. These aren’t obscure utilities. They’re the tools that IT professionals, sysadmins, and engineers have been grabbing for years, often from USB drives, often on production systems, often with admin privileges.
On April 9, 2026, that trust became a weapon.
Why This One Matters#
Before the technical details, consider who downloads CPU-Z.
Not casual users. The people pulling CPU-Z and HWMonitor from cpuid.com are sysadmins, infrastructure engineers, and IT operations staff. They run these tools on production servers during hardware provisioning, on workstations during troubleshooting, on systems where they hold administrative credentials. Compromising the download page for CPU-Z isn’t an attack on a general user base. It’s a direct path to the people most likely to have privileged access.
The ZIP distribution makes it worse. CPU-Z is specifically designed to run without installation. No registry changes, no elevation required for basic functions, no software deployment policies triggered. That portability is why IT professionals love it, and exactly why it’s dangerous when weaponized. It reaches environments that block installer-based software.
And be honest: how many times have you downloaded CPU-Z from the official site without checking a hash? The attackers didn’t need to compromise the binary or defeat code signing. They just needed to change where the download link pointed. That’s a much lower bar.
What Happened#
Between approximately 15:00 UTC on April 9 and 10:00 UTC on April 10, attackers compromised a backend API on cpuid.com and replaced download links for CPU-Z, HWMonitor, HWMonitor Pro, and PerfMonitor 2 with links to trojanized packages hosted on attacker-controlled Cloudflare R2 storage.
CPUID’s founder confirmed the breach on X, attributing it to a compromised “secondary feature” (a side API) rather than a direct intrusion into the build pipeline. The signed original binaries weren’t tampered with. The links were simply redirected.
Reddit users spotted it first. Someone downloading HWMonitor v1.63 noticed the file arrived named HWiNFO_Monitor_Setup.exe, a completely different product from a different developer. Windows Defender flagged it, community discussion escalated, and security research collective vx-underground confirmed the compromise. Kaspersky subsequently published a detailed analysis tying it to the same threat group behind a trojanized FileZilla campaign from March 2026.
The Technical Chain#
The infection chain used DLL sideloading with a Zig-compiled CRYPTBASE.dll packaged alongside the legitimate signed executables. When the real CPU-Z or HWMonitor binary launches, Windows loads the attacker’s DLL first due to standard search order, giving them code execution under a trusted, signed process.
From there, the malware resolved its C2 domain through DNS-over-HTTPS via Cloudflare (1.1.1.1), completely sidestepping traditional DNS monitoring. It compiled additional payloads in memory using csc.exe and executed PowerShell through stdin piping to avoid command-line logging. The final payload was STX RAT, a remote access trojan focused on credential theft from browsers, FTP clients, and crypto wallets, with hidden VNC capability for invisible desktop interaction.
Persistence was established through four independent mechanisms: MSBuild .proj files with embedded shellcode loaders, scheduled tasks, COM TypeLib hijacking, and PowerShell profile modification. Killing one doesn’t kill the others.
The Attacker’s Biggest Mistake#
Kaspersky flagged something worth noting: the attackers reused the identical infection chain, the same STX RAT binary, and the same C2 domains from their March FileZilla campaign. Every detection rule and IOC published after that operation applied directly to this one.
The C2 configuration even contained campaign tracking tags (“cpz” for CPU-Z, “monitor3” for HWMonitor, campaign name “CityOfSin”), suggesting organized operations. But the infrastructure reuse was sloppy enough that Kaspersky described the whole thing as “orchestrated quite poorly.”
That’s cold comfort if you were among the 150+ confirmed victims across retail, manufacturing, consulting, telecom, and agriculture, primarily in Brazil, Russia, and China.
Detection and Response#
If you need to check whether your environment was affected:
Network indicators: DNS or HTTPS traffic to welcome.supp0v3[.]com (C2 callback endpoint) and connections to 95.216.51.236 (Hetzner, Finland), the same IP from the FileZilla campaign.
Host indicators: Unexpected CRYPTBASE.dll files in application directories alongside CPU-Z or HWMonitor executables, MSBuild .proj files with embedded C# inline tasks in unusual locations, COM TypeLib registry modifications, and PowerShell profile changes your team didn’t make.
AV classifications: Backdoor.Win64.Alien.de (Kaspersky), Trojan-Spy.StxRat (Ikarus), Gen:Variant.Tedy (BitDefender).
The Takeaway#
The distribution channel is the attack surface. The signed binaries were fine. The build pipeline was fine. A side API got compromised, and that was enough to turn a trusted tool into a credential-stealing RAT for six hours.
Three questions worth asking your team today: Do you have visibility into what portable executables your staff downloads and runs on production systems? Can you detect DLL sideloading attempts on servers and workstations? Are you monitoring for DNS-over-HTTPS traffic that bypasses your DNS security layer?
The attackers in this case reused their infrastructure and made detection straightforward. The next group won’t be that generous.
