Executive summary
A compromise of the CPUID website briefly turned trusted download links for CPU-Z, HWMonitor, HWMonitor Pro, and PerfMonitor into a malware delivery channel. According to Kaspersky, attackers replaced legitimate installer links between roughly April 9, 15:00 UTC and April 10, 10:00 UTC, distributing trojanized packages that paired signed legitimate software with a malicious CRYPTBASE.dll for DLL sideloading.
The final payload was STX RAT, a malware family with infostealer capabilities. For defenders, the important lesson is that a short-lived compromise of a popular software distribution path can still create a meaningful enterprise incident. If users downloaded affected binaries, the right response is not just “reinstall the tool,” but hunt for execution, persistence, follow-on command-and-control traffic, and potential credential exposure.
What happened?
Public reporting and vendor analysis indicate that attackers gained access to a secondary API or side feature on the CPUID site and caused the main site to randomly serve malicious download links instead of the original software packages.
The poisoned distribution path affected these products:
- CPU-Z 2.19
- HWMonitor 1.63
- HWMonitor Pro 1.57
- PerfMonitor 2.04
Kaspersky says the malicious packages contained two components:
- a legitimate, signed executable for the expected product
- a malicious
CRYPTBASE.dllused to launch the infection chain through DLL sideloading
This matters because the attack abused trust in the software source rather than tricking users with a fake domain alone. In practice, that turns a software update or utility download into a potential software supply chain incident even when the original vendor binaries themselves remain signed and intact.
Why this matters for defenders
1. Trusted software channels are still prime attack surface
Users downloading diagnostics and hardware tools from an official vendor site generally do not expect to validate every redirect, host, or archive component. That assumption is exactly what made this intrusion useful to the attacker.
2. The attack chain reused known tradecraft
Kaspersky linked the campaign to infrastructure and configuration previously seen in a fake FileZilla operation from March 2026. That reuse suggests defenders should not treat this as a one-off random compromise. It looks more like an operator repeatedly targeting broadly used utilities with a working delivery chain.
3. Short exposure windows can still produce real downstream risk
Kaspersky identified more than 150 victims, including organizations across retail, manufacturing, consulting, telecommunications, and agriculture. Even a compromise lasting less than a day can be enough for widespread initial access when the target is a popular download hub.
Technical takeaways
The publicly described chain is straightforward but effective:
- the CPUID site served malicious URLs in place of normal downloads
- victims received trojanized ZIP archives or installers
- a malicious
CRYPTBASE.dllwas sideloaded by the expected signed executable - the loader performed anti-sandbox checks and connected to attacker infrastructure
- the final stage deployed STX RAT
Kaspersky noted reuse of the same C2 address pattern and connection configuration seen in the earlier fake FileZilla campaign. That kind of overlap is valuable for threat intelligence teams because it helps connect what might otherwise look like separate download-related incidents.
Researchers also observed that the attacker operational security was not especially strong. Reused infrastructure and a known final-stage RAT made the campaign easier to detect than a cleaner custom operation. That is good news, but only if defenders go back and look.
What organizations should do now
🔴 Identify who downloaded affected tools
Review proxy, DNS, EDR, and browser download logs for access to the malicious domains and suspect installer filenames linked to CPU-Z, HWMonitor, HWMonitor Pro, and PerfMonitor during the exposure window.
🔴 Hunt for DLL sideloading and suspicious child processes
Look for signed CPUID executables loading unexpected CRYPTBASE.dll files, unusual outbound connections shortly after tool execution, and any artifacts tied to STX RAT or the malicious download domains.
🟠 Treat affected hosts as potentially credential-exposed
Because the delivered payload has infostealer behavior, organizations should assume browser-stored credentials, session material, and local secrets may have been exposed from impacted systems.
🟠 Isolate and investigate before simply deleting files
If there is evidence an affected binary executed, do a proper incident response workflow. Preserve forensic artifacts, review persistence, rotate credentials tied to the user or host, and assess whether any lateral movement followed.
🟠 Tighten download validation for admin tools
For sensitive utilities used by admins, engineers, or IT staff, use internal software repositories, hash validation, code-signing verification, and controlled distribution instead of ad hoc public downloads wherever possible.
Detection ideas
Security teams should look for:
- connections to the malicious domains documented by Kaspersky
- execution of CPUID tools followed by
CRYPTBASE.dllloads - new processes spawned after launching CPU-Z, HWMonitor, or PerfMonitor
- signs of infostealer collection activity or browser credential access
- suspicious outbound traffic consistent with post-download RAT beaconing
Example Splunk hunt
splindex=edr OR index=sysmon OR index=proxy ("CPU-Z" OR "HWMonitor" OR "PerfMonitor" OR "CRYPTBASE.dll") ("supp0v3" OR "cahayailmukreatif" OR "transitopalermo" OR "vatrobran" OR "r2.dev") | stats count min(_time) as firstSeen max(_time) as lastSeen by host, user, process_name, command_line, dest, file_name
Strategic takeaway
This CPUID incident is a reminder that defenders should classify widely used admin and performance tools as part of the privileged software trust boundary. If attackers can tamper with where those tools are fetched, they gain a low-friction path into systems that often belong to technically trusted users.
That makes the core lesson less about one utility vendor and more about software acquisition discipline. Internal mirroring, verification, download monitoring, and rapid post-execution hunting all matter when the infection path starts with a tool the user expected to trust.
Were CPUID's original signed binaries compromised?
Public statements indicate the original signed files were not altered. The problem was that the website briefly served malicious links and trojanized packages instead.
Which products were affected?
Public reporting named CPU-Z, HWMonitor, HWMonitor Pro, and PerfMonitor during the malicious-link window.
Why is STX RAT important here?
Because it turns this from a simple website defacement story into a real post-download compromise with potential infostealer and remote access implications.
What should defenders do first?
Identify downloads and executions during the exposure period, isolate impacted hosts, investigate for follow-on activity, and rotate credentials if compromise is suspected.



