Back to Articles
Cybersecurity

Threat Intel: Unpacking the CPU-Z Supply Chain Attack and MSBuild LotL Execution

In a recent investigation, VSAT Security analyzed a live endpoint infection stemming from a massive supply chain compromise of popular CPUID hardware profiling tools (such as CPU-Z and HWMonitor).

April 19, 20264 min readVSAT Security

Supply chain attacks continue to evolve, leveraging highly trusted applications to bypass perimeter defenses. In a recent investigation, VSAT Security analyzed a live endpoint infection stemming from a massive supply chain compromise of popular CPUID hardware profiling tools (such as CPU-Z and HWMonitor).

Tracked as the "CityOfSin" campaign, the threat actor (suspected Russian-nexus) successfully deployed a variant of the Alien RAT backdoor. This article breaks down the full kill chain, from the initial trojanized download to the evasive "Living off the Land" (LotL) memory injection techniques used in the final stage.


Phase 1: Initial Access via DLL Sideloading

The attack does not originate from a compromised CPUID build server, but rather from repackaged ZIP files distributed via malvertising or SEO poisoning.

The attacker bundles genuinely signed, legitimate CPU-Z executables alongside a malicious CRYPTBASE.dll. When the victim launches the legitimate cpuz_x64.exe, the application transitively loads ADVAPI32.dll, which in turn falls victim to DLL search order hijacking and loads the malicious CRYPTBASE.dll from the local directory instead of the Windows system folder.

Phase 2: Staging and C2 Callback

Once loaded into the trusted CPU-Z process, the malicious DLL executes a highly obfuscated routine:

  1. It decodes a reflective PE loader (out.dll) from its .rdata section.
  2. The loader performs DNS-over-HTTPS (DoH) resolution via Cloudflare (1.1.1.1) to resolve the C2 domain welcome.supp0v3.com, bypassing traditional DNS monitoring.
  3. It reaches out to the C2 server, which actively drops the final-stage backdoor components onto the disk.

Note: In our endpoint analysis, the C2 payload attempted an outbound callback to 95.216.51.236 before being intercepted and blocked.

Phase 3: MSBuild Abuse and Memory Injection (The Payload)

The C2 server drops two critical files into the user's hidden AppData directory: an MSBuild project file (c_3791.proj or CommonBuild.proj) and an encrypted shellcode blob (BuildCache.dat).

The attacker then uses PowerShell to silently execute Microsoft's Build Engine (MSBuild.exe), passing it the .proj file. This LotL technique effectively bypasses Application Whitelisting (like AppLocker), as MSBuild is a trusted Windows developer utility.

The .proj file contains inline C# code masquerading as a legitimate "Microsoft Package Optimizer." Its true function is a custom XOR decryption loop:

C#


private void ProcessOptimizationCache(byte[] data) {
for (int i = 0; i < data.Length; i++) {
// Decrypts the BuildCache.dat payload in memory
data[i] = (byte)(data[i] ^ (1 + (i % 17)));
}
ExecuteOptimization(data);
}

Once decrypted, the loader imports ntdll.dll to call NtAllocateVirtualMemory. It carves out a block of system memory with 0x40 (PAGE_EXECUTE_READWRITE) permissions—a massive indicator of shellcode injection—and executes the Alien RAT backdoor directly in memory via a dynamic delegate pointer.

Phase 4: Persistence via COM Hijacking

To survive reboots, the malware establishes a complex quad-persistence mechanism. Alongside Scheduled Tasks and Registry Run keys, it utilizes COM TypeLib Hijacking. By dropping scriptlets (ActiveX.sct and Clippy.sct), the malware intercepts legitimate COM object calls, chaining them into an IPv6-encoded .NET deserialization routine that re-launches the memory-resident backdoor.

Defensive Takeaways and Hunting Guidance

Relying purely on file hashes is insufficient for this campaign, as the attacker dynamically generates the BuildCache.dat and data.dat payloads per victim. Defenders must focus on behavioral telemetry:

  1. Monitor MSBuild Execution: Alert on MSBuild.exe executing project files from unusual locations, especially AppData\Local or Temp directories.
  2. Hunt for RWX Memory: EDR platforms should heavily scrutinize trusted binaries (MSBuild, InstallUtil, Regsvr32) attempting to allocate PAGE_EXECUTE_READWRITE memory blocks.
  3. Audit DLL Loads: Implement strict rules for applications loading CRYPTBASE.dll or version.dll from non-system directories.

Indicators of Compromise (IOCs)

Network Infrastructure:

  1. 95.216.51.236 (C2 Server - Blocked)

Host Artifacts (SHA1):

  1. 9E177911FBD5E337AE65E78917010DB8C6D15158 (c_3791.proj - Loader)
  2. 455A33434F9858BFD35BBD2D34BE9F8301B19E52 (BuildCache.dat - Encrypted Payload)
  3. BFCED57626DCF0BB29AC9E02A491569A441833B6 (InstallUtil.InstallLog)

File Paths to Monitor:

  1. C:\Users\*\AppData\Local\Microsoft\MSBuild\*.proj
  2. C:\Users\*\AppData\Local\Microsoft\MSBuild\Current\Cache\*.dat
  3. C:\Users\*\AppData\Local\Temp\*.dll (Specifically look for generic naming conventions like ClassLibrary*.dll)

(Note: BuildCache.dat hashes are victim-specific due to dynamic generation and should not be relied upon for global blocklisting).

References

  1. https://gist.github.com/N3mes1s/b5b0b96782b9f832819d2db7c6684f84#a5-buildcachedat--datadat---final-stage-shellcode
  2. https://www.bleepingcomputer.com/news/security/supply-chain-attack-at-cpuid-pushes-malware-with-cpu-z-hwmonitor/