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 hardware monitoring download was used to deliver a multi-stage RAT through DLL sideloading and in-memory execution.

Why it matters: It matters because identity and endpoint teams need to treat trusted installer paths, privileged execution contexts, and post-compromise visibility as one control problem across NHI, autonomous, and human access.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility.

👉 Read Gurucul's analysis of the HWMonitor trojanisation and STX RAT chain

Context

A trojanized software download is a supply-chain problem first, but it becomes an identity problem once a trusted binary is used to run attacker-controlled code inside a legitimate process context. In this case, the compromise of a hardware monitoring utility turned the user’s trust in signed software into an execution path for hidden malware.

That matters to NHI and IAM programmes because the abuse pattern sits between software distribution, execution trust, and post-compromise access. When attackers can hide inside the launch path of a trusted application, conventional perimeter assumptions do little to protect credentials, sessions, or operator workflows.

The article’s starting position is typical of modern malware delivery: the payload is not trying to look novel, it is trying to look legitimate long enough to execute. That is the pattern security teams now need to treat as normal rather than exceptional.

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 trusted installers increase the risk of session theft and remote monitoring?

A: Trusted installers matter because they often run with the user’s normal access, which gives malware the same visibility into browser sessions, desktop content, and operator workflows. Once that happens, the attacker does not need to steal a password file to gain useful access. Visible session activity becomes the target, and that greatly broadens the blast radius.

Q: How do security teams know if reflective loading is happening in memory?

A: The best signals are combinations, not single events. Look for executable memory allocation, import resolution without a normal on-disk image, unusual thread start points, and a process ancestry that does not match the application’s normal behaviour. When those appear together, treat the process as a memory-resident payload chain rather than a benign application.

Q: Who is accountable when a trojanized download is used to steal active sessions?

A: Accountability usually spans software distribution, endpoint engineering, and identity operations. The team that owns download integrity must validate the package path, the endpoint team must detect malicious process behaviour, and the identity team must understand which sessions and privileged workflows were exposed. The right framework is shared responsibility around trusted execution, not a single control owner.

Technical breakdown

DLL sideloading through trusted software downloads

DLL sideloading, also called search-order hijacking, works when a legitimate executable loads a malicious library placed in the application directory before it reaches the intended system DLL. That gives attacker code execution inside the trusted process without modifying the visible behaviour of the host application. In this campaign, the malware preserved normal functionality by loading the real system library after the malicious code had already executed. The practical significance is that trust in the executable name is not enough when load order can be manipulated.

Practical implication: monitor for unexpected DLLs beside trusted binaries and treat application-directory DLL loads as a control failure, not a curiosity.

Reflective loading and memory-resident payload stages

Reflective loading means the payload maps itself into memory rather than relying on a conventional file-based install path. The loader resolves imports, applies relocations, and transfers execution entirely in memory, which reduces disk artefacts and makes post-event reconstruction harder. Multi-stage reflective chains also let each layer decrypt the next, so defenders see a sequence of transient states instead of a single static sample. That architecture is designed to minimise forensic evidence and delay detection by endpoint tooling.

Practical implication: correlate RWX memory allocation, import resolution, and process ancestry because file-based detection alone will miss this class of chain.

Hidden desktop interaction, screen capture, and operator visibility

Hidden-desktop tradecraft turns the victim’s active session into a remote monitoring surface. By accessing the interactive window station, enumerating windows, and capturing desktop pixels with BitBlt, the malware can observe browser activity, authenticated sessions, and user-entered information without needing to steal a credential file directly. That shifts the attack from code execution to session observation, which is harder to detect if teams only watch for credential dumping. The key point is that visible user work can become the exfiltration channel itself.

Practical implication: alert on unexpected desktop-access permissions and screen-capture behaviour from non-interactive processes.

Threat narrative

Attacker objective: The attacker’s objective is to gain covert remote access through a trusted software path and use hidden desktop visibility to harvest session data and maintain operator control.

1. Entry via a trojanized HWMonitor ZIP hosted on a compromised download endpoint and delivered as trusted software to the user.
2. Credential or session exposure through a malicious DLL loaded by the legitimate executable, followed by in-memory loader stages that conceal their activity.
3. Impact through STX RAT capabilities including screen capture, host profiling, and command-and-control communication for remote operator access and possible credential theft.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted software execution is now part of identity governance. This campaign worked because a legitimate binary became the carrier for attacker-controlled execution, which means the control boundary is no longer only download provenance or endpoint reputation. Identity teams need to treat trusted application launch paths as governance surfaces because they determine what code can run under a user, admin, or service context. The practitioner conclusion is that software trust and execution trust must be reviewed together.

Screen capture malware turns session visibility into access theft. The final payload did not need to steal a password database if it could observe browser activity, operator workflows, and authenticated sessions in real time. That collapses the old assumption that credential theft always begins with direct credential extraction. The implication is that access governance must account for what a process can observe, not just what secrets it can read.

DLL sideloading is a control-gap story about execution context, not just malware family. The malware abused a trusted process context, then layered reflective loading and anti-analysis to stay invisible long enough to operate. That means process allowlisting alone is insufficient when application directories can host malicious libraries. The practitioner conclusion is that execution control must extend to library resolution and process integrity.

Identity blast radius expands when attacker code runs under trusted software. Once malicious code inherits the user’s active context, it can interact with applications, sessions, and network paths that would otherwise be unavailable. That makes blast-radius analysis more useful than binary reputation scoring for this class of threat. The practitioner conclusion is to map which identities and workflows a trusted binary can reach if its load path is compromised.

Hidden desktop monitoring is a named concept for modern post-execution abuse. The malware’s use of WinSta0 access and BitBlt capture shows that compromise can pivot from code execution into live session surveillance without obvious credential theft. That is a distinct failure mode from simple remote access trojans because the operator is watching and harvesting in-session activity. The practitioner conclusion is to treat visible desktop interaction as a privileged capability requiring detection.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• For a broader view of how identity exposure turns into breach conditions, see The 52 NHI breaches Report for real-world patterns and response lessons.

What this signals

The governance signal here is that trusted software can become an identity exposure surface the moment attacker code runs in a legitimate process context. Hidden desktop monitoring: a useful concept for this pattern, because it describes when post-execution abuse shifts from file theft to live session observation and operator surveillance. Teams should therefore connect endpoint telemetry, session protection, and privileged access monitoring rather than treating them as separate disciplines.

When memory-resident payloads are the delivery mechanism, conventional “known bad file” thinking loses value quickly. The stronger programme response is to anchor detection around behavioural combinations such as library hijacking, RWX memory, and screen-capture access, then tie those detections back to the identities and workflows that were active at the time. That is where incident triage becomes identity analysis, not just malware analysis.

For security programmes that already invest in lifecycle governance, the next step is to treat execution trust as part of entitlement scope. In practice, that means mapping which user and admin sessions can be observed or manipulated if a trusted application is replaced or hijacked, then prioritising the workflows with the highest operational sensitivity first.

For practitioners

• Harden application load paths Block unexpected DLLs in the same directory as trusted executables and alert on library loads from user-writable or downloaded locations.
• Correlate memory-only execution signals Detect RWX memory allocation, reflective loading, and unusual import resolution together, because any one signal in isolation is easy to miss.
• Watch for hidden desktop abuse Flag non-interactive processes that request WinSta0 access, enumerate visible windows, or invoke screen capture functions such as BitBlt.
• Inspect trusted download workflows Review distribution channels that rely on third-party hosting or user-driven downloads, and validate that the package path cannot be swapped with attacker content.
• Map session exposure to identity blast radius Identify which identities and authenticated workflows a compromised application can observe, then prioritise controls around those sessions first.

Key takeaways

• Trojanized trusted software can turn a legitimate process into a covert malware launcher, which makes execution context a security boundary.
• The campaign combines DLL sideloading, reflective in-memory loading, and hidden desktop capture, showing how attackers reduce artefacts while increasing control.
• Teams need to align endpoint detection, session visibility, and identity governance so that trusted binaries cannot quietly expand attacker access.

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.
• Process Environment Block: A Windows data structure that stores runtime process information, including flags and loader state. Malware often reads it directly to avoid obvious detection APIs, which is why endpoint controls need behavioural correlation rather than simple API monitoring.

What's in the full article

Gurucul's full post covers the operational detail this post intentionally leaves for the source:

• The exact DLL sideloading chain and the file layout that let the malicious library load before the legitimate system DLL.
• The reflective loader stages and memory artefacts that analysts can use to reconstruct the in-memory payload chain.
• The API hashing, anti-debugging, and XOR-obfuscation methods used to slow static analysis and endpoint inspection.
• The IoCs, hashes, and callback details needed for practical threat hunting and containment.

👉 The full Gurucul post covers the DLL sideloading chain, memory-resident loaders, and detection details.

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.