CPU-Z Backdoor: Detecting Malicious Implants at Scale | RevEng.AI

← BackCPU-Z Backdoor: Detecting Malicious Implants at Scale<br>7/14/2026<br>The security landscape of software is evolving at a pace never seen before. Today, AI now writes a significant part of code being created by developers and its abilities are accelerating at a pace no one could have predicted. Few have considered the security impact from AI writing complex code bases in which humans are no longer writing and verifying the code generated.<br>This change in how software is being developed and released is now presenting a number of unsolved security problems for the industry and wider community. Code can be generated at such a pace that it is almost impossible for security teams and human beings to conduct proper code reviews. From the attackers perspective, AI has driven down the expertise and time needed to exploit vulnerable code. As a result, we're now seeing that software exploitation is the most common attack vector threat actors use to break into systems overtaking what was historically phishing and credential theft. Similar results were shared by the Google Threat Horizons report which announced that threat actors were exploiting vulnerabilities in third party libraries just days after disclosure.<br>If AI is writing most of the code we run today, how can we verify and trust what's in the software we run?<br>The Software Supply Chain<br>The scale of the software supply chain security problem is huge and cannot be understated. With the way modern software is created, relatively small software projects can have hundreds of dependencies that are constantly being updated. Validating the security of all of the pieces of code is prohibitively expensive and almost impossible if you have third-party dependencies. To verify the security of software we use today, we need to be able to verify the security of the binary artefacts that users actually execute in production, rather than rely on traditional SAST techniques. Verifying the binary artefact has traditionally been incredibly challenging and the only historical method of doing so requires manual reverse engineering to ensure it hasn’t been tampered with.<br>RevEng.AI solves this problem by analysing software after it has been built and before it's shipped into production. Our foundational AI model for binary analysis understands the DNA of the software package and detects malicious components and security threats. As such, we decided to evaluate our Reverser platform on the latest CPU-Z software supply chain attack containing a backdoor. The remainder of this blog posts focuses on a technical write-up and analysis of the incident.<br>CPU-Z Backdoor Incident<br>Over the past few months, one of the most discussed supply chain campaigns has involved malware distributed as legitimate CPU-Z software. Between the 9th and 10th April 2026, hackers breached an API for the CPUID website and replaced download links with trojanised installers. These installers contained a malicious Windows DLL named CRYPTBASE.dll that installed a Remote Access Trojan (RAT) known as STX RAT. The malware was designed to evade detection and steal sensitive information such as browser credentials, cryptocurrency wallets, and user passwords.<br>The RevEng.AI research team analysed the malicious package with Reverser which automated a semantic code search and decompiled the binary to understand how the DLL file was created. Reverser's initial Triage analysis correctly identified the sample as a threat, highlighting key defensive evasion, obfuscation and processes injection techniques. Whilst the sample is stripped, our analysis recovered debug information and renamed both DllMain and loader_and_injector functions, highlighting that they contain suspicious and malicious execution capabilities.<br>Figure 1: Triage analysis output for the malicious CRYPTBASE.dll.Exploring the analysis<br>From the triage analysis, we can see a highly suspicious execution capability that spawns a new thread upon entry with DllMain. This is usually the main entry point to a loaded DLL file in Windows. Taking a closer look, we can see that a new thread is created with what appears to be the start of the samples main logic which the Reverser has automatically renamed to LocateAndExecuteShellcode.<br>Figure 2: Investigating DLLMain to validate CreateThread argumentFollowing the execution chain, the file makes use of byte-like strings to decode a new binary, along with a small shellcode stub that jumps to the correct initialization function in the newly decoded payload. This crafted shellcode is then written into the memory region allocated via VirtualAlloc, allowing execution to transition into the next stage of the malware.<br>Figure 3: Process of allocating and writing in memory for later execution.To resolve the target of the call rbx, we start from the loaded base address 0x2198f50003f. The call points to 0x2198f501233, so subtracting the base gives the in-memory offset:...