HWMonitor Trojanized to Deliver Multi-Stage STX RAT via DLL Sideloading

Introduction

HWMonitor, a legitimate hardware monitoring utility developed by CPUID, was observed distributing a trojanized archive through a compromised download workflow. Analysis of a Reddit post led to the discovery of a malicious ZIP archive hosted on a Cloudflare R2 endpoint masquerading as a legitimate HWMonitor package.

The malicious archive was distributed through the following URL:
hxxp://pub-fd67c956bf8548b7b2cc23bb3774ff0c[.]r2[.]dev/hwmonitor_1[.]63[.]zip

This campaign demonstrates how attackers continue to abuse trusted software distribution channels to deliver malware through DLL sideloading and memory-resident execution chains. Because users generally trust widely used software utilities, trojanized installers remain an effective initial access vector.

Following extraction, the archive contains a suspicious CRYPTBASE.dll colocated with the legitimate HWMonitor_x64.exe binary.

The malware abuses DLL search-order hijacking by placing a malicious DLL within the application directory, causing the executable to load the attacker-controlled library instead of the legitimate Windows system DLL.

Upon execution, the malicious DLL initiates a multi-stage in-memory loading chain that ultimately deploys STX RAT. The malware employs several defense evasion and stealth techniques, including:

• DLL sideloading
• Reflective PE loading
• API hashing
• PEB-based anti-debugging
• XOR-obfuscated strings
• Multi-stage memory-only payload execution
• Hidden desktop interaction and screen capture

The final payload includes functionality associated with credential theft and remote operator interaction through hidden desktop monitoring behavior.

Initial Execution and DLL Sideloading

In this campaign, HWMonitor_x64.exe loads CRYPTBASE.dll from the local application directory instead of the legitimate Windows system path, allowing attacker-controlled code to execute within the trusted process context.

After execution, the malicious DLL loads the legitimate cryptbase.dll from the Windows system directory to preserve normal application functionality and reduce user suspicion.

Inside DllMain, the malware spawns two separate threads:

1. A thread responsible for initializing the malicious execution chain
2. A secondary thread used to load the legitimate system DLL

Launching the malicious logic through a secondary thread likely avoids loader-lock-related instability commonly associated with executing complex logic directly from DllMain.

Multi-Stage Reflective Loader Architecture

The malicious DLL extracts obfuscated data from the .rdata section and allocates executable memory using VirtualAlloc with RWX permissions. The allocated memory region is populated with decoded shellcode and an embedded PE payload.

Execution is then transferred to shellcode responsible for reflective PE loading. The loader manually maps embedded payloads entirely in memory by:

• Allocating memory for PE sections
• Resolving imports dynamically
• Applying relocations
• Transferring execution to the payload entry point

This staged architecture allows the malware to avoid writing intermediate payloads to disk, significantly reducing forensic artifacts.

The malware proceeds through multiple reflective loading stages, where each stage decrypts and loads the next payload directly in memory using a TEA-like symmetric decryption routine.

The overall execution chain observed during analysis is shown below:

Stage 2 and Stage 3 operate as intermediate reflective loaders responsible for decrypting and mapping the next payload stage entirely in memory.

Stage 4 follows the same execution pattern and ultimately decrypts and loads the final STX RAT payload without writing artifacts to disk.

STX RAT Analysis

API Hashing

STX RAT dynamically resolves APIs using a ROR13 hashing routine combined with PEB traversal, eliminating explicit import table dependencies and complicating static analysis.

The malware enumerates loaded modules through the PEB loader structures and parses export tables to resolve functions by comparing runtime-generated hashes against hardcoded constants embedded within the binary.

This technique enables the malware to conceal sensitive API usage while maintaining flexible runtime resolution.

Anti-Debugging

The malware implements a lightweight anti-debugging mechanism by directly accessing the Process Environment Block (PEB) and inspecting the BeingDebugged flag located at offset 0x2.

By avoiding standard debugging detection APIs, this approach reduces behavioral visibility while allowing the malware to alter execution flow when analysis tools are detected.

Security Software Discovery

STX RAT enumerates installed security products, including antivirus and EDR solutions such as:

• Avast
• AVG
• Avira
• BitDefender
• CrowdStrike
• SentinelOne
• Elastic EDR
• Kaspersky
• Trellix EDR
• MalwareBytes
• Sophos
• Fortinet

The product names are stored using a lightweight XOR-based obfuscation routine in which each byte is XORed using an incrementing key beginning as 0x36.

This obfuscation technique reduces static signature visibility while remaining computationally inexpensive.

Security software discovery may allow operators to profile the victim environment and adapt post-compromise behavior based on defensive tooling present on the system.

System Information Discovery

The malware collects basic host profiling information including:

• Hostname
• Username
• Operating system details

Collected values are obfuscated using the same XOR-based routine observed elsewhere in the malware.

This information enables victim tracking, infection management, and campaign-level host identification.

Hidden Desktop Interaction and Screen Capture

STX RAT interacts with the interactive window station (WinSta0) using OpenWindowStationW, requesting permissions associated with desktop creation and screen interaction.

The malware subsequently enumerates windows through Z-order traversal using GetWindow, selectively processing visible windows that may contain sensitive user activity.

Screen content is captured using BitBlt with the SRCCOPY raster operation (0xCC0020), enabling lossless capture of visible desktop content.

Combined, these behaviors are consistent with hidden-desktop-based monitoring capabilities commonly associated with HVNC-style malware frameworks.

Captured content could facilitate theft of browser-displayed credentials, authenticated sessions, and other sensitive user activity.

Screen Capture via BitBlt (SRCCOPY)

Command and Control Communication

The malware constructs structured JSON-based network data used for command-and-control communication.

Observed configuration fields include:

The presence of campaign tracking identifiers suggests the operators may distribute multiple trojanized software packages while tracking infection sources independently.

Observed callback endpoint:

hxxps://welcome.supp0v3[.]com/d/callback

Detection with Gurucul SIEM

Gurucul SIEM can help security teams detect and investigate activity associated with this malware campaign by providing visibility into:

• DLL sideloading activity
• Reflective in-memory payload execution
• RWX memory allocation behavior
• API hashing and anti-analysis techniques
• Hidden desktop interaction
• Screen capture activity
• Suspicious process and DLL loading patterns
• Command-and-control communication attempts

By correlating endpoint, process, memory, and network telemetry, Gurucul can assist SOC teams in identifying stealthy multi-stage malware activity and improving detection coverage for memory-resident threats.

MITRE ATT&CK Mapping

Indicators of Compromise (IOCs)

File Hashes (MD5)

URLs