On April 9, 2026, cpuid.com was actively serving malware through its own official download button. Threat actors had compromised the CPUID domain at the API level and were silently redirecting legitimate download requests to attacker-controlled infrastructure. The attack ran for approximately 19 hours. Users who navigated directly to the official site received a legitimate, properly signed binary with a malicious payload bundled inside it.

That morning, SentinelOne’s behavioral detection flagged an anomaly inside cpuz_x64.exe. The binary was genuine. The digital signature was valid. The download had arrived from the vendor’s own infrastructure. The process chain cpuz_x64.exe began constructing was the tell: it spawned PowerShell, which spawned csc.exe, which spawned cvtres.exe. CPU-Z does not do that.

CPU-Z, HWMonitor, HWMonitor Pro, and PerfMonitor are staples in IT toolkits. The users who downloaded them followed every instruction they’d been given. The trust chain broke above them. The next attack will work the same way.

SentinelOne’s Annual Threat Report identifies exactly this pattern as a systemic shift: “This [shift] extends deeply into the software supply chain, where the identity of a trusted developer becomes the vector of attack.” In late 2025, we observed the GhostAction campaign, where a compromised GitHub maintainer account pushed malicious workflows to extract secrets. A concurrent phishing attack against a maintainer of popular NPM packages deployed malicious code capable of intercepting cryptocurrency transactions. In each case, the commit logs and push events appeared legitimate because they originated from accounts with valid write access. The identity was verified. The intent had been subverted. The CPUID incident extends this pattern to software distribution itself: the supplier’s download infrastructure became the delivery channel.

What the Agent Saw

The SentinelOne agent triggered the alert “Penetration framework or shellcode was detected” within the first seconds of execution. The detection came from what the process was doing, with five specific behavioral indicators converging:

• Anomalous API resolution: The process located system functions through non-standard discovery methods, bypassing the OS loader entirely.
• Reflective code loading: Executable code was running in memory regions with no corresponding file on disk.
• Suspicious memory allocation: Read-Write-Execute (RWX) memory permissions were requested, a staging pattern for malicious payloads.
• Process injection patterns: Execution flow consistent with code being redirected into a secondary process to mask its origin.
• Heuristic shellcode signatures: Sequential operations characteristic of automated exploitation toolkits preparing an environment for command execution.

The agent autonomously terminated and quarantined the involved processes before the attack advanced further. The malicious CRYPTBASE.dll, placed in the same directory as the legitimate CPU-Z binary, was loaded by Windows before the real system DLL could be reached, and it never completed its job.

The agent was watching for what the software was trying to do. Behavioral detection is the layer that holds when authorization cannot be trusted, because the behavior reveals intent regardless of what signed the package.

What Was Actually Inside

The trojanized packages were designed to leave no trace. A reflective PE loader decrypted and injected a second-stage DLL using XXTEA encryption and DEFLATE decompression, no disk writes, no file artifacts. Three redundant persistence mechanisms were then installed: a registry Run key, a 68-minute scheduled task with a 20-year duration, and MSBuild project files in AppData\Local engineered to survive reboots and partial remediation.

The 2026 Annual Threat Report describes this persistence design as “masquerading as maintenance”: adversaries blend into the environment by mimicking legitimate system updates and background processes. To a busy defender, a scheduled task with a generic name and a timed execution interval appears entirely routine until you examine what it is executing. STX RAT’s 68-minute task with a 20-year duration operates on exactly this logic.

The process chain visible in EDR logs made the intent clear: cpuz_x64.exe spawned powershell.exe, which spawned csc.exe, then cvtres.exe. CPU-Z does not do that.

The final payload, STX RAT, delivered hidden VNC providing an attacker-controlled desktop session invisible to the user, keyboard and mouse injection, browser credential theft across Chrome, Firefox, Edge, and Brave, Windows Vault extraction, cryptocurrency wallet access, and a reverse proxy for follow-on payload delivery. C2 communication ran over a custom encrypted protocol using DNS-over-HTTPS to 1.1.1.1 to bypass DNS monitoring.

A reflective payload executing entirely in memory, inside a signed process, with no disk writes, compresses the detection window to milliseconds. Autonomous response is the only response fast enough.

The Attacker’s Critical Mistake

Kaspersky’s analysis linked the CPUID samples to a March 2026 campaign targeting FileZilla users within hours, and the connection required no advanced forensics. The attacker reused the identical C2 infrastructure and deployed the unmodified STX RAT payload, the same one eSentire’s Threat Response Unit had already fingerprinted and published YARA rules for after the FileZilla campaign.

Those rules detected the CPUID variant without modification.

The actor invested time compromising CPUID’s download API and did nothing to retool after being publicly fingerprinted. The C2 domain, the backend server, the payload: all identical across campaigns. The same backend server had been operating since at least July 2025. Per Kaspersky’s own assessment, the C2 reuse was the gravest mistake of the operation. A more disciplined actor burns infrastructure between campaigns. This one did not, and defenders had working detection before most victims knew an attack had occurred.

What the Attack Was Really For

The 150+ confirmed victims span retail, manufacturing, consulting, telecommunications, and agriculture. The count is almost certainly low, CPUID’s tools have tens of millions of users globally, and the portable ZIP variant of CPU-Z runs commonly on production systems in environments that block installer-based software.

Victim count is secondary to victim profile. CPU-Z users skew toward IT professionals: system administrators, developers, security engineers, the people with domain admin rights, production access, and infrastructure keys. One compromised sysadmin carries a fundamentally different blast radius than one compromised user.

The operational pattern points to an initial access broker. The goal was to sell persistent, hidden access. Someone else would do the extracting.

For organizations where an infection occurred, two questions need answers. What did the attacker do during the window they had access, especially if that machine belonged to a privileged user? And what happens over the next 60-90 days, when whoever purchased that access decides to activate it? Ransomware affiliates who buy IAB access typically move within that window. Cleaning the machine closes one exposure. Monitoring for lateral movement, credential reuse, and unusual authentication in the weeks following remediation closes the other.

What Defenders Should Do Now

For practitioners

The indicators are specific and actionable.

• Check your fleet for CRYPTBASE.dll in any directory other than C:\Windows\System32.
• Look for the process chain cpuz_x64.exe or any CPUID application spawning PowerShell.
• Block supp0v3[.]com and 147.45.178.61 at DNS and firewall layers.
• At the network layer, watch for DNS-over-HTTPS queries to 1.1.1.1/dns-query resolving welcome.supp0v3.com; STX RAT specifically uses DoH to bypass DNS monitoring, and any endpoint generating this pattern is a high-confidence indicator.

If you find an infected machine, remediate all four persistence mechanisms explicitly: the registry Run key, the scheduled task, any MSBuild .proj files in AppData\Local, and PowerShell profile autoruns. The malware installs redundant footholds specifically because partial cleanup leaves it alive.

For security leaders

The harder conversation is about supply chain trust. Your users followed every rule they were given. They downloaded from the official website. They trusted a vendor they had used for years. That vendor’s infrastructure failed them. Behavioral detection, security that watches what software does rather than where it came from, is the layer that caught this.

The business case is specific. When an initial access broker sells a foothold obtained this way, the buyer typically activates within 60-90 days. With average ransomware recovery costs exceeding $4 million per incident, even a single privileged endpoint sold through an IAB represents material, quantifiable exposure. The organizations that already had 24/7 autonomous behavioral monitoring in place closed the window before it opened. The ones that did not are still counting.

The adversary’s tooling was unsophisticated. The OPSEC was poor. The C2 reuse was a gift to defenders. And yet: 150+ confirmed victims and a 19-hour window during which clean, legitimate software was being replaced by a remote access trojan is a demonstration of how far attacker leverage has extended into the software supply chain, and how quickly behavioral detection closes the gap when it acts autonomously, before the attack completes its first stage. The attacker’s poor OPSEC saved defenders this time. The structural failure in the trust model (the assumption that software from a trusted source is safe to run) persists regardless of attacker discipline.

The Structural Problem That Remains

SentinelOne’s latest Annual Threat Report documents GhostAction and the NPM package compromise as supply chain identity attacks through code repositories and package managers. CPUID adds a third layer: the vendor’s distribution infrastructure itself. Across all three cases, access controls validated a legitimate identity. The report frames this plainly: “The identity is verified, but the intent has been subverted, rendering traditional access controls ineffective against the resulting supply chain contamination.”

This shift means authorization, the cornerstone of traditional software trust, is no longer a sufficient security boundary. When the distribution channel becomes the failure point, verification has to move from the point of origin to the point of execution.

In the CPUID case, users followed every rule. They downloaded from the official vendor website. That vendor’s download API was the failure point, compromised at the infrastructure level for 19 hours, with no visible indication.

SentinelOne’s Behavioral AI engine detects suspicious and malicious patterns in real time, watching what the software does regardless of where it came from.

SentinelOne customers were protected through autonomous behavioral detection at the point of execution. The structural failure in the trust model (the assumption that software from a trusted source is safe to run) is a gap that better user behavior cannot close. Behavioral detection at machine speed is what closes it.

To understand how the Singularity Platform identifies threats across your environment, including those arriving through trusted software channels, request a demo.

The post The CPUID Watering Hole Attack Turning CPU-Z into a Trojan appeared first on Daily CyberSecurity.

Threat actors compromised the CPUID website and spread STX RAT through fake CPU-Z and HWMonitor downloads.

Attackers breached the website CPUID and replaced download links for CPU-Z and HWMonitor with malicious files for several hours. Users who downloaded them got infected with the STX RAT, giving attackers remote access to their systems. The short attack window still exposed many users to compromise.

Investigations show attackers compromised a secondary API for about six hours, causing the site to display malicious links. The maintainers of the website confirmed that the original signed files remain safe, and the issue has been fixed.

Kaspersky reported that on April 9, 2026, the CPUID website was compromised, and download links for tools like CPU-Z and HWMonitor were redirected to malicious domains for several hours. Attackers used these sites to distribute infected installers, and Kaspersky published related indicators of compromise.

“We observed that starting from approximately April 9, 15:00 UTC, until about April 10, 10:00 UTC, the legitimate download URLs for installers of that software have been replaced” states Kaspersky. “with URLS to the following malicious websites:

• vatrobran[.]hr.
• cahayailmukreatif.web[.]id;
• pub-45c2577dbd174292a02137c18e7b1b5a.r2[.]dev;
• transitopalermo[.]com;

Kaspersky found that attackers distributed trojanized CPU-Z and HWMonitor installers with a malicious DLL (“CRYPTBASE.dll”) using DLL sideloading. The DLL handled C2 communication, anti-sandbox checks, and payload delivery, reusing infrastructure from a previous fake FileZilla campaign.

“The interesting part here is that the attackers reused both the C2 address and the connection configuration from the March 2026 campaign where the attackers hosted a fake FileZilla (an open-source FTP client) site distributing malicious downloads.” continues the report. “The configuration embedded in the DLL is presented further. The “referrer” field in the configuration equals “cpz” which tends to be a shorthand for “CPU-Z”.”

The attack ultimately deployed a sophisticated RAT after multiple staged loaders. Attackers reused the known STX RAT, making detection easier thanks to existing rules. Despite compromising a popular software site, they failed to evade detection. Researchers found over 150 victims, mainly individuals but also organizations across multiple sectors, with most cases in Brazil, Russia, and China.

Kaspersky experts advise checking DNS logs and systems for signs of infection.

“Compared to other recently occurred watering hole and supply chain attacks, such as the Notepad++ supply chain attack, the attack on the cpuid.com website was orchestrated quite poorly.” concludes the report. “The gravest mistake attackers made was to reuse the same infection chain involving STX RAT, and the same domain names for C2 communication, from the previous attack related to fake FileZilla installers.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CPUID)