Trojanized HWMonitor shows how DLL sideloading delivers STX RAT

At a glance

What this is: This is a threat research post showing how a trojanized HWMonitor archive used DLL sideloading and multi-stage in-memory execution to deliver STX RAT.

Why it matters: It matters because trusted software downloads can bypass conventional trust assumptions, forcing IAM, endpoint, and SOC teams to correlate process, memory, and network signals around non-human execution paths.

Context

DLL sideloading is a technique where a legitimate executable loads a malicious library from its own directory instead of the expected system path. In this campaign, a trojanized HWMonitor archive turned a trusted download into an execution vehicle for STX RAT, showing how software provenance failures become identity security problems once code runs under a legitimate process context.

The governance gap is not just malware delivery. It is the assumption that users can trust a familiar utility because the binary name looks right, even when the distribution path, loaded DLL, and in-memory stages have already been compromised. That matters for NHI, endpoint, and monitoring teams because the compromise lives across execution, memory, and telemetry layers rather than in one control domain.

The article’s detail also shows why simple reputation checks are insufficient. Once the loader preserves normal application behaviour while hiding the malicious chain in memory, defenders need controls that see the load path, the module relationship, and the resulting network behaviour together.

Key questions

Q: What breaks when DLL sideloading is possible in trusted software downloads?

A: DLL sideloading breaks the assumption that a trusted executable only runs trusted code. If an attacker can place a malicious library where the application looks first, the binary becomes a launch point for attacker-controlled execution inside a legitimate process context. Teams should watch for downloaded software in user-writable paths and treat nearby DLLs as part of the trust boundary.

Q: Why do DLL sideloading campaigns create such a high stealth risk?

A: They hide malicious code inside a legitimate process and can preserve normal application behaviour by loading the real system DLL alongside the rogue one. That makes the attack harder to distinguish from routine execution. The risk rises further when the payload uses in-memory loaders, anti-debugging, and obfuscated strings to avoid static detection.

Q: What are the signs that a malware loader is using memory-only execution?

A: Look for RWX memory allocation, manual mapping, dynamic import resolution, and rapid stage changes without matching file writes. When those patterns appear together, they often indicate a reflective loader chain rather than benign software behaviour. The clearest signal is a trusted process that spawns unusual memory activity before making outbound connections.

Q: How should security teams respond when hidden desktop capture appears in endpoint telemetry?

A: Treat it as a post-compromise access pattern, not a user-interface oddity. Hidden desktop access, window enumeration, and screen capture are often used to observe credentials, sessions, and application content. Teams should correlate those behaviours with process ancestry, loaded modules, and callback traffic to decide whether the host is being used interactively by an operator.

Technical breakdown

How DLL sideloading turns a trusted executable into an execution host

DLL sideloading, also called search-order hijacking, works when an application loads a library from a local directory before the intended system path. Here, HWMonitor_x64.exe loaded a malicious CRYPTBASE.dll placed beside it, which let attacker code run inside a trusted process while the genuine system DLL was loaded separately to preserve normal behaviour. That combination reduces user suspicion and complicates basic file reputation checks because the visible executable remains legitimate while the library path is not.

Practical implication: validate expected DLL load paths and alert on trusted binaries loading same-name libraries from user-controlled or downloaded directories.

Why reflective loading hides malware stages from disk-based detection

Reflective loading means the payload is manually mapped into memory rather than written to disk and started by the operating system loader. The article describes a multi-stage chain that decrypted shellcode, allocated RWX memory, resolved imports dynamically, applied relocations, and transferred execution entirely in memory. Each stage decrypted the next, which creates a short-lived chain with little disk artefact and makes static scanning far less useful than memory and behavioural telemetry.

Practical implication: inspect RWX allocation, manual mapping, and rapid parent-child loader chains as indicators of staged in-memory execution.

How anti-analysis and hidden desktop features support operator access

STX RAT used PEB-based anti-debugging, API hashing, and security product discovery to shape behaviour under analysis, then interacted with the hidden desktop and captured screen content with BitBlt. That matters because the payload is not only trying to survive inspection. It is also trying to reach visible user sessions, harvest what appears on screen, and adapt based on the defensive tooling present. In practice, this shifts the threat from simple execution to interactive post-compromise access.

Practical implication: correlate debugger checks, security product discovery, and desktop capture activity as a single suspicious operator workflow.

Threat narrative

Attacker objective: The objective is to gain stealthy remote access inside a trusted process, observe user activity, and preserve control long enough to capture sensitive session data and interact with the victim environment.

1. Entry occurred through a trojanized HWMonitor ZIP hosted on a compromised download workflow and disguised as a legitimate software package.
2. Credential and execution control were bypassed when the local malicious CRYPTBASE.dll was loaded through DLL sideloading inside the trusted HWMonitor process.
3. Escalation followed through reflective, multi-stage in-memory loaders that decrypted and mapped the final STX RAT payload without writing intermediate stages to disk.
4. Impact included hidden desktop monitoring, screen capture, and command-and-control communication that could expose sessions, credentials, and user activity.

Breaches seen in the wild

• Sumo Logic breach 2023: A compromised credential opened a Sumo Logic AWS account; customers were told to rotate API keys and stored credentials. No data impact was found.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted software distribution is now an identity problem, not just a malware problem. The article shows how a legitimate executable can become a delivery mechanism when its download path is compromised and its local DLL loading behaviour is predictable. That means software provenance, execution context, and trust in the binary name all have to be treated as part of access governance. The practitioner implication is that download trust cannot be separated from runtime trust.

Process legitimacy can mask malicious identity behaviour inside the same runtime session. HWMonitor remained the visible host process while the malicious DLL and reflective loaders performed the real work. That collapses the old assumption that a trusted process context is itself evidence of trusted activity. The implication is that defenders need to distinguish process name from process intent, especially when memory-only stages and proxy loading preserve the appearance of normal execution.

Identity controls fail when they assume the meaningful unit of risk is the account or the file, not the execution chain. This campaign used local library hijacking, staged shellcode, and networked callback behaviour to move across layers that are often monitored separately. The named concept here is runtime trust gap: the space between a trusted download, a trusted executable, and an untrusted in-memory payload. The practitioner implication is that control design has to follow the runtime chain, not the installer alone.

Detection must fuse endpoint, memory, and network evidence because the attack is intentionally split across those planes. API hashing, anti-debugging, security product discovery, and screen capture each look modest in isolation, but together they indicate an operator preparing for persistence and interactive theft. This is where SIEM value depends on correlation quality rather than alert volume. The practitioner implication is that multi-stage malware requires cross-telemetry detection logic, not single-signal hunting.

Service-account-style governance thinking still matters here because the attacker is exploiting implicit trust, not a human login. The compromise path behaves like a non-human execution problem: a controlled package, a trusted host, and delegated runtime authority. That places it squarely in the same governance conversation as machine identity and workload trust. The practitioner implication is that endpoint execution policy and non-human trust boundaries should be reviewed together, not as separate programmes.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Runtime trust gap: attacks like this succeed when organisations trust the executable name but not the library load path, the memory stage, and the callback behaviour as one chain. That gap is where software provenance and runtime telemetry need to converge in the same investigation workflow.

The practical lesson for NHI and endpoint teams is that a trusted application can become an untrusted execution host without changing its filename. When reflective loaders and hidden desktop activity are present together, the SOC should treat the event as an operator session, not a simple malware drop.

For practitioners

• Harden trusted download paths Block execution from user-writable download locations when the binary is expected to load same-named libraries from the application directory, and treat unexpected local DLL co-location as a high-fidelity alert.
• Detect reflective in-memory loading Tune endpoint and memory telemetry to flag RWX allocations, manual import resolution, and rapid loader chains that never stage payloads on disk.
• Correlate anti-analysis with post-execution behaviour Join debugger checks, security product discovery, hidden desktop access, and screen capture events into one investigation path because the sequence indicates operator preparation rather than isolated noise.
• Inspect trusted utility updates and mirrors Review download sources, mirrored packages, and archive contents for DLL names that overlap with system libraries, especially when distribution endpoints sit outside your normal software provenance controls.
• Raise SIEM rules for hidden desktop activity Alert when a process opens WinSta0, enumerates windows, and captures the screen while also initiating suspicious callback traffic or loading obfuscated payload stages.

Key takeaways

• The campaign used a legitimate-looking HWMonitor package to deliver STX RAT through DLL sideloading and multi-stage in-memory execution.
• The loader chain hid intermediate payloads on disk, which makes memory telemetry and process correlation more important than file-based scanning alone.
• Teams should focus on library load paths, RWX memory, and hidden desktop activity because those controls would have narrowed the attacker’s room to operate.

Key terms

• DLL Sideloading: A technique where a legitimate executable loads a malicious library from a location the application checks before the real system path. It works because the program’s trust is inherited by the code it loads, which makes execution control as important as file reputation.
• Reflective Loading: A method of executing payloads directly in memory without a normal install or load path on disk. The loader resolves imports and relocations itself, which reduces forensic artefacts and makes the malware harder to detect with file-centric controls.
• Hidden Desktop Monitoring: A post-compromise technique in which malware accesses the interactive desktop to observe windows, sessions, and on-screen activity. It is especially dangerous because it targets live user behaviour rather than stored secrets, allowing attackers to capture credentials and sensitive actions in real time.
• API Hashing: API hashing is a technique that replaces readable function names with hash values so the malware does not store obvious import strings. During execution, the code resolves required system functions by matching hashes to exports, which makes reverse engineering and static detection more difficult.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.