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

Original text by Pandurang Terkar / Rudra Pratap

Gurucul’s article analyzes a trojanized HWMonitor package used to deliver a multi-stage STX RAT through DLL sideloading. A malicious ZIP, disguised as HWMonitor 1.63 and hosted on a Cloudflare R2 endpoint, contained the legitimate HWMonitor_x64.exe alongside a malicious CRYPTBASE.dll. When launched, HWMonitor loaded the local DLL instead of the legitimate Windows system library, giving the attacker code execution inside a trusted process. The DLL then loaded the real cryptbase.dll to preserve normal behavior while spawning threads for the malicious chain. The payload used reflective in-memory loading, RWX allocation, TEA-like decryption, API hashing, XOR-obfuscated strings, PEB anti-debugging, and several loader stages before deploying STX RAT. The final malware profiled the host, discovered AV/EDR products, captured screens with BitBlt, interacted with hidden desktops, and communicated with C2 using JSON-based data.

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.

Fig: Downloading malicious package

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

Fig: Extracted files contain malicious CRYPTBASE.DLL

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.

Fig: Calling Loadlibrary from malicious CRYPTBASE.DLL to clean CRYPTBASE.DLL

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.

Fig: Thread created to load clean cryptbase.dll

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.

Fig: Obfuscated data in .rdata section

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.

Fig: Unpacked Stage 2 in memory

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:

HWMonitor_x64.exe
└── Malicious CRYPTBASE.dll

└── Stage 1 Shellcode Loader

└── Reflective Stage 2 Loader

└── Stage 3 Intermediate Loader

└── Stage 4 Final Loader

└── STX RAT Payload

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.

Fig: Stage 4 loaded in Memory

Fig: Stage 5 loaded in Memory

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.

Fig: API calls are resolved via hashing.

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.

Fig: Stealth Check: PEB BeingDebugged Flag

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.

Fig: Security tools Identification

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.

Fig: System information gathering

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.

Fig: Hidden Desktop Initialization via WinSta0 Access

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

Fig : Window Enumeration via Z-Order Traversal

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)

Fig: 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.

Fig: C2 configuration

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