Trojanized CPUID HWMonitor Installer Delivers Fileless .NET Payload via Obfuscated IPv6 Scriptlet

Overview

Recent reporting has identified a trojanized version of the CPUID HWMonitor installer being used to deliver a multi-stage, fileless malware chain leveraging trusted Windows binaries. Upon execution, the installer initiates a sequence involving PowerShell, MSBuild, and regsvr32, ultimately leading to the execution of malicious scriptlet files such as Clippy.sct and a secondary launcher scriptlet. These scriptlets utilize ActiveX (WScript.Shell) to silently invoke:

"C:\Windows\System32\regsvr32.exe" /s /u "/i:C:\Users\user\AppData\Local\Microsoft\Internet Explorer\Clippy.sct" scrobj.dll

This is a well-known living-off-the-land technique that enables the execution of remote or local scriptlet payloads without dropping traditional executables to disk.

An analysis of Clippy.sct reveals that it serves as the core payload loader, leveraging .NET interoperability within JScript to reconstruct and execute a hidden assembly entirely in memory. The scriptlet contains a large embedded array of fake IPv6 addresses, which are not network indicators but rather an obfuscated representation of raw binary data.

Figure 1. An array of fake IPv6 addresses.

At runtime, the script expands compressed IPv6 notation (::), converts each 16-bit segment into its corresponding byte pair, and appends the result into a .NET MemoryStream.

Figure 2. IPv6 decoding routine converting 16-bit segments into raw byte stream.

This process rebuilds a serialized .NET payload, which is then deserialized using BinaryFormatter and executed via dynamic invocation, leading to the instantiation of a malicious class (ServiceClass) responsible for further payload execution.

Figure 3. Deserialization and dynamic invocation of reconstructed .NET payload.

This technique demonstrates a layered evasion strategy combining obfuscation, in-memory execution, and abuse of legitimate system utilities. Encoding the payload as IPv6 strings helps bypass static detection and complicates analysis, while deserialization-based execution avoids writing the reconstructed binary to disk. Additionally, references within the payload suggest follow-on behavior involving reading a secondary file (data.dat) and executing it via native Windows APIs, such as VirtualAlloc and CreateThread, likely indicating shellcode execution.

Recommendations

Organizations should recognize that even trusted vendor sites can be compromised and should validate all downloaded installers prior to execution. This includes verifying code signatures, comparing file hashes against known-good values, and scanning binaries with security tools before deployment. Where possible, restrict the execution of newly downloaded files until they have been validated in a controlled environment.

Deploying and properly configured endpoint detection and response (EDR) solutions is critical to identify behaviors consistent with this technique, including unusual process chains involving installers spawning PowerShell, MSBuild, or regsvr32. Monitoring command-line activity and enforcing alerts on suspicious parent-child relationships can help detect this type of fileless execution early.

Organizations should also monitor for the abnormal usage of regsvr32 with scriptlets (.sct files), the execution of MSBuild from user-writable directories, and script-based payload reconstruction patterns such as large embedded arrays or encoded data transformations. These behaviors can be indicators of this threat technique and should be prioritized for detection and response.

Indicators of Compromise