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.

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.

If AI is writing most of the code we run today, how can we verify and trust what's in the software we run?

The Software Supply Chain

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.

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.

CPU-Z Backdoor Incident

Over the past few months, one of the most discussed supply chain campaigns has involved malware distributed as legitimate CPU-Z software. Between the 9^th and 10^th 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.

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.

Figure 1: Triage analysis output for the malicious CRYPTBASE.dll.

Exploring the analysis

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.

Figure 2: Investigating DLLMain to validate CreateThread argument

Following 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.

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: 0x2198f501233 - 0x2198f50003f = 0x11F4.

This offset is then adjusted relative to the .text section (which starts at raw 0x400, corresponding to virtual address 0x180001000). Subtracting 0x400 gives 0xD3C and adding this to the image base results in the final virtual address, 0x180001DF4, which corresponds to one of the main functions highlighted by the triage analysis for the new binary (SHA-256: 7396673fdc5ee5572db9a0691ba8888fc9e8887d35c69d906733f5e728d459c2) .

The Second Stage

The decoded binary was put back through Reverser and found to contain a new set of malicious capabilities.

Figure 4: Triage analysis summary for the new loader.

The function at 0x180001DF4 is an exported function named init. Taking a closer look, it does exactly what the triage workflow described, acts as a routine that dynamically resolves Windows API functions. It accesses the Process Environment Block (PEB) to locate loaded modules, then parses their export tables to resolve function addresses using hash comparisons. This is a common stealth technique used by malware and packers to hide imports and capabilities from static analysis.

In the end, the objective of this function mirrors the previous stage, it prepares and loads yet another binary directly into memory and transfers execution to it. This shows a chaining of stages, where each step is responsible for preparing and handing off control to the next payload.

Following the Chain

Continuing in that infection chain, we will find many samples that look alike and follow exactly the same approach. Most of them resemble the second step mentioned here, but instead of using the init function, they start at the function marked as the EntryPoint (0x180001000) and receive 0xA as an operation_mode parameter, which means they will continue decrypting and passing execution to the next step until reaching a final binary. This process can go on through more than 8 binaries.

Figure 5: AI Decompilation result of EntryPoint.

The function mentioned in the EntryPoint is also highlighted in the triage analysis report as ShellcodeLoader (0x18000115C), and it presents the behaviour pointed out by the AI in both the report and the decompilation. It contains numerous hashed values that are later resolved into valid API functions, which are then used by other parts of the code.

Figure 6: AI Decompilation result of initialize_and_process_resources.

The function named ResolvingApiByHash by AI in Figure 6 corresponds to the same function 0x18000102C referenced in the triage analysis summary. Its behaviour can also be validated with a debugger tool, once it receives a hash, it searches for a match and returns a pointer to the corresponding function.

Figure 7: Arguments and return value of the `ResolvingApiByHash` function.

Final Stage

After many binaries that continue the chain and passing execution along by creating threads, you will reach one that behaves very differently from the steps before it. That is the last loader binary of that part of the chain, and it has environment checks that might break your reverse engineering process. One of those is a field in the binary header that can break some decompilation tools. This can be bypassed by changing the values of the Import, Export, and Exception tables to 0 in the Data Directories section of the Image Optional Header.

One of the main anti-analysis techniques applied was looking for environment files and flags that would indicate an analysis lab. By increasing the value returned by the function, the sample knew it might be running in a controlled analysis environment and could proceed with the process termination approach.

Figure 9: AI Decompilation result of get_environment_status_flags.

This binary marks the final stage of the chain analysed here. Once it has cleared its environment checks, it establishes communication with the C2 server and relies on PowerShell to continue the execution. This represents the final state of the infection chain, where the previous decryption and loading steps converge, and it deploys the last step of the campaign on the compromised host.

Full AI Analysis

If we run the full AI analysis on the sample, we quickly verify the malicious nature of the sample and extract the following IoCs.

Reverser's analysis was also able to map key file capabilities and functionality back to the MITRE ATT&CK framework:

Figure 11: MITRE ATT&CK techniques automatically identified.

And generated the following YARA rule for automated remediation:

rule Win64_Trojan_Reflo_A
{
    meta:
        description = "Detects Win64 Reflo malware loader based on unique strings and C2 configuration artifacts"
        author = "RevEng.AI"
        date = "2026-05-22"
        hash_sha256 = "8a6c39f97fb86a4ff9dc9226fa8b3445c5fe123abab532ea6afb9be2608780e1"
        severity = "high"
        confidence = "high"

    strings:
        $c2_url = "https://welcome.supp0v3.com/d/callback?utm_tag=snip&utm_source=CityOfSin" ascii wide
        $json_config = "{\"tag\":\"snip\",\"referrer\":\"CityOfSin\"" ascii wide
        $str_hello = "{\"hello\":\"\"}" ascii wide
        $str_sc1 = "c:48:83:e4:f0:e8" ascii wide
        $str_sc2 = "fc:48:83:e4:f0:e8" ascii wide
        $cryptbase = "C:\\Windows\\System32\\CRYPTBASE.dll" ascii wide

    condition:
        uint16(0) == 0x5A4D and (
            any of ($c2_url, $json_config) or
            all of ($str_sc*) or
            ($str_hello and $cryptbase and 1 of ($str_sc*))
        )
}

Conclusion

The quick analysis of a multi-stage infection chain shows how AI-driven analysis plays an essential part in malware analysis. RevEng.AI highlights key malicious behaviours, such as execution pivots, staged payload loading, and dynamic API resolution, and provide a clear path for analysts to follow, reducing time spent on manual discovery and allowing faster validation of critical functionality.

If you’re looking to streamline your analysis and apply these capabilities in practice, it’s worth exploring the features available in RevEng.AI. From accelerating initial triage to highlighting key execution paths and behaviours, these tools can help reduce manual effort and provide clearer insights, allowing you to focus on deeper investigation and decision-making.

IOCs

SHA-256	Description
https://welcome.supp0v3.com/d/callback?utm_tag=snip&utm_source=CityOfSin	C2 URL used on CRYPTBASE.dll
9dc9226fa8b3445c5fe123abab532ea6afb9be2608780e1	The content of CRYPTBASE.dll, identified by its SHA-256 hash
7396673fdc5ee5572db9a0691ba8888fc9e8887d35c69d906733f5e72	The content of the Second Stage binary, identified by its SHA-256 hash

Detecting Malicious Code at Scale