The Infinite Loop: Deconstructing WSHRAT’s Fileless Injection and Defeating Lab Routing Blindspots

Malware analysis is rarely a straightforward sequence of executing a payload and watching the indicators neatly populate your dashboards. Sometimes the malware waits, and sometimes your own laboratory hides the evidence.

Recently, I isolated a VBScript variant of the infamous WSHRAT (also known as Houdini) from MalwareBazaar. My objective was to deconstruct its obfuscated code statically, detonate it in a controlled, host-only environment, capture its fileless PowerShell injection via Event Tracing, and map its Command and Control (C2) infrastructure on the wire.

Instead of a quick win, I found myself navigating a game of cat-and-mouse against the malware's synchronous execution loops, Windows diagnostic background noise, and a fundamental flaw in virtualised DNS routing.

This is the story of hunting WSHRAT, where understanding why an exploit failed to fire was the key to cracking the entire operation.

The Blueprint: Static Discovery

The investigation began by air-gapping my Windows 10 victim host and REMnux analysis gateway. After extracting the password-protected archive, I staged the raw malware.vbs file inside Visual Studio Code to perform static analysis before detonation.

The threat actor was remarkably careless. Right at the top of the file, nestled in a comment block, was their moniker and Skype contact information (recoder : kognito).

As I scrolled through the un-obfuscated script, I mapped out a highly sophisticated execution chain. The malware was designed to enumerate installed Antivirus products using Windows Management Instrumentation (WMI) queries to SecurityCenter2.

More alarmingly, I discovered a faceMask function detailing a modern "Living off the Land" (LotL) execution tactic: Process Hollowing. Instead of dropping a malicious .exe to the disk, the VBScript was programmed to take massive chunks of Base64-encoded text, store them inside the Windows Registry (HKCU\SOFTWARE\Microsoft\mPluginC), and use a hidden PowerShell command to reflectively load the payload directly into a legitimate MSBuild.exe process in memory.

The Silent Detonation

Eager to catch this fileless injection in the act, I configured my dynamic capture tools. I launched INetSim and Wireshark on my REMnux gateway. On the Windows host, I fired up Process Explorer and cleared my Event Viewer, specifically ensuring PowerShell Script Block Logging (Event ID 4104) was enabled.

I double-clicked malware.vbs. I waited.

I refreshed Event Viewer, expecting to see the malicious PowerShell command logged cleanly. An Event 4104 appeared, but the script block was full of functions like Get-FreeSpace and Delete-OldFolders executing from C:\Windows\TEMP\SDIAG_….

The PowerShell injection didn't run. I hadn't made a mistake in my lab setup; I had just collided with the fundamental difference between a Dropper and a Remote Access Trojan (RAT).

The "Aha!" Moment

Reviewing the static code revealed the glitch. If this were a standard dropper, it would execute its payload immediately upon detonation. But WSHRAT is a backdoor.

The code contained a synchronous while true loop. Upon execution, the malware sends an HTTP POST request to its C2 server (snkcyp.duckdns.org) asking "is-ready". Because my lab was air-gapped, the request hit my local INetSim sinkhole, which replied with a generic, fake HTTP 200 OK webpage. The malware read that generic page, realised it wasn't a valid command from its master, and simply went to sleep for 5 seconds (wscript.sleep 5000) before looping back to ask again.

The brilliant fileless PowerShell injection I wanted to capture would only execute if the attacker's C2 server explicitly replied with a command to deploy a plugin. Trapped in the sinkhole, the malware was stuck in an infinite "phone home" loop.

The Network Blindspot

Even though the injection didn't fire, the malware was still actively running. I verified this in Process Explorer. A hidden wscript.exe process was actively running with the //B flag, not from my Desktop where I detonated it, but from the %appdata%\Roaming folder. The malware had successfully copied itself and established persistence.

But when I pivoted to my REMnux machine to view the Wireshark capture, the network was completely devoid of DNS or HTTP traffic. The malware was active, but the wire was silent, as the Wireshark capture only showed background ARP and broadcast noise, completely failing to capture the malware's active unicast DNS requests.

I realised I was facing a virtualised routing blindspot. My Windows machine (.128) was using the default VMware virtual router (.254) as its DNS server. When the malware requested the IP for snkcyp.duckdns.org, it sent a direct, private Unicast message to the router. Because my REMnux machine (.129) was just sitting adjacent on the network, it was blind to that private conversation. The air-gapped router simply dropped the request, and the malware failed to connect.

The Trap Snaps

To force INetSim to intercept the traffic, I had to force Windows to ask REMnux for directions instead of the virtual router. I opened the Windows IPv4 adapter settings and manually overrode the Preferred DNS server to point directly to my REMnux IP (192.168.134.129).

I flushed the DNS cache. Because the malware was still trapped in its 5-second sleep loop, I didn't even need to restart it.

Within seconds, the Wireshark interface exploded with traffic. INetSim successfully lied to the malware, claiming to host snkcyp.duckdns.org. The malware began aggressively firing its DNS queries and HTTP beacons. I also captured a secondary query to ip-api.com, proving the script's internal getCountry() function was attempting to geolocate my lab to report back to the attacker. The network trap had snapped shut.

Execution Analysis & Evasion

Once the network was correctly routed, the malware continued its execution, attempting to elevate its privileges.

Finally, I analysed the core RAT engine, which functions as a command dispatcher for the attacker.

The Memory Trap: Dynamic YARA Testing

To finalise the investigation, I engineered a behaviour-based YARA rule targeting the threat actor's signature strings, the C2 domain, and the registry keys used for the fileless PowerShell injection.

However, detection engineering requires precision. During my first test, the YARA compiler threw a strict error: unreferenced string "$reg_runpe". I had defined the registry string in my variables, but forgot to append it to the condition logic at the bottom of the rule.

After correcting the logic, I didn't just want to scan the dead file on the disk. Because of the malware.vbs payload was still actively trapped in its execution loop under wscript.exe (PID 8004), so I ran the YARA scanner directly against the live process memory using the -s flag to expose exactly which strings triggered the alert.

Key Takeaways, Lessons Learned & Personal Reflections

• The Frustration of the Blindspot: Troubleshooting the DNS routing issue was incredibly frustrating but ultimately rewarding. It is a stark reminder that in a lab, the environment is the analysis. My initial failure to capture the C2 traffic wasn't a flaw in the malware, but a configuration error in my own virtual routing. Never assume your sensors are perfectly placed.
• Understand the Trigger: Backdoors don't always behave like droppers. Identifying the synchronous "is-ready" loop was the key to understanding why the fileless PowerShell payload remained dormant without an attacker's green light.
• Compilers are Unforgiving: The YARA unreferenced string error was a humbling reminder that security tools operate on absolute logic. Writing detection rules requires just as much rigorous debugging as writing the malware itself.

Technical Resources

· Detection Engineering: View the custom YARA rule here

· IoC Publication: Access the full list of IoCs on AlienVault OTX

Technical Incident Report: WSHRAT (Houdini) Dropper Evasion & Infrastructure Analysis

• Report ID: 2026–06–28-WSH-01
• Classification: TLP:CLEAR
• Subject: Fileless Process Hollowing, VBScript Obfuscation, and Network Beaconing of WSHRAT (Houdini) Payload

Executive Summary

A detailed behavioural and network analysis was performed on a VBScript variant of the WSHRAT/Houdini malware inside a restricted laboratory environment. The payload operates as a remote access trojan that initially establishes persistence within the AppData directory. The malware utilises a synchronous execution loop to beacon a hardcoded command and control (C2) server. While secondary fileless PowerShell injection techniques (Process Hollowing into MSBuild.exe) are present in the code, their execution is strictly dependent on receiving valid command triggers from the C2 infrastructure. Custom network routing and packet-level inspection successfully intercepted the payload's outbound command beacon and geolocation requests.

List of Affected Entities

• Internal Source (Assigned): 192.168.134.128 (Windows 10 Lab Workstation / Hostname: DESKTOP-KHTFPG0 / Local User: Analyst).
• Target Identity: Malicious Command and Control Node (snkcyp.duckdns.org) and third-party Geolocation API (ip-api.com).
• Attacker IP: 192.168.134.129 (Redirected locally via manual DNS routing to INetSim network sinkhole topology).
• Identity: WSHRAT / Houdini (VBScript Payload / Hash: 207ac97e60aeb989a14feaae8a365f5b35233ac7800f1357b325a0bd8d3bdd5c).
• VPN Gateway: None (Host execution isolated strictly within a non-routing host-only architecture).
• External Actor: "kognito" (Identified via internal script comments: recoder : kognito © skype : live:unknown.sales64).

Technical Findings & Analysis Steps

1. Static Code Analysis & Persistence Mechanism: Initial static analysis of the un-obfuscated .vbs payload revealed hardcoded configuration variables, including the C2 host (snkcyp.duckdns.org), operating port (3369), and target installation directory (%appdata%). Upon execution, the script verifies its current running directory. If it is not executing from %appdata%, it copies itself to the target location, utilises wscript.exe //B to silently launch the newly copied instance, and terminates the original process.

2. Anti-Virus Reconnaissance: The payload includes a dedicated function security block designed to perform local system reconnaissance. It utilises Windows Management Instrumentation (WMI) to query winmgmts:\localhost\root\securitycenter2 (or securitycenter for legacy OS versions), extracting the display names of installed Antivirus products to transmit back to the C2 infrastructure.

3. Fileless Execution Mechanism (Process Hollowing): The script contains dormant, highly advanced execution capabilities designed to evade disk-based heuristics. The faceMask function reveals a sequence that stores Base64-encoded payload blocks directly into the Windows Registry (HKCU\SOFTWARE\Microsoft\mPluginC and mRunPE). A hidden PowerShell instance is then spawned to reflectively load the injector string directly into system memory ([System.Reflection.Assembly]::Load), bypassing the disk entirely, before hollow-injecting the malicious RAT payload into a newly spawned, legitimate MSBuild.exe process.

4. C2 Beaconing & Geolocation: Because the malware functions as a backdoor rather than a pure dropper, the aforementioned PowerShell injection is gated behind a synchronous while true loop. The malware repeatedly attempts an HTTP POST request ("is-ready") to the C2 domain. By modifying the local host IPv4 DNS adapter settings to force resolution through the REMnux sinkhole, packet capture analysis confirmed active DNS queries to the hardcoded C2 domain, as well as subsequent queries to ip-api.com, confirming the payload's routine to geolocate the victim's country code (e.g., cc = "01", cn = "Unknown") for threat actor telemetry tracking.