VHDX Containers: When a Virtual Disk Becomes the Payload

Researchers at the SANS Internet Storm Center recently walked through one such attack in detail. A reader submitted a malicious ZIP archive; inside it was a VHDX disk image that, once mounted, quietly kicked off a multi-stage chain ending in Remcos RAT. What stands out is not the payload. Remcos has been around for years and does nothing here that it has not done a thousand times before. The clever part is the packaging, and the way each stage was chosen to slip under a different category of defense.

It Starts With an Archive Nobody Questions

The entry point is an unremarkable phishing email carrying a ZIP attachment. ZIP files move through business inboxes constantly, so they rarely trip alarms on their own. The interesting choice is what sits inside: a VHDX file, Microsoft’s modern virtual hard disk format, the kind Hyper-V and other virtualization tools use every day.

On current versions of Windows, double-clicking one of these images mounts it automatically, as if someone had plugged in an external drive. To the person at the keyboard, the file just opens into a folder with a few items in it. To the attacker, that automatic mounting is the whole point. Email gateways, antivirus engines, and attachment filters tend to scrutinize executables and Office documents far more aggressively than they inspect a disk image. The trust extended to the container becomes the way in.

Stage One: A Script Wearing a Business Disguise

Once the VHDX mounts, it reveals a JavaScript file with a deliberately ordinary, procurement-flavored name (the SANS analysis cites a German-language filename built around a request for a new quotation). The German naming points at German-speaking targets, almost certainly through the kind of vendor and purchasing workflows where a quotation request is routine and gets opened without much thought.

The script is heavily obfuscated, padded out with junk comments and filler strings whose only job is to confuse pattern-matching engines. When the SANS handler first checked it, antivirus detection was extremely low, which tells you the disguise did its job against reputation and signature scanners. The script itself does very little; it is a launcher, and its real task is to start PowerShell without creating the kind of process relationship that gives the game away.

Stage Two: Borrowing WMI to Stay Off the Radar

When a script launches PowerShell directly, endpoint detection tools notice immediately. A scripting engine spawning a command interpreter is a classic red flag, and the parent-child link between the two is exactly what behavioral rules look for.

So the attackers added a middleman. Rather than going straight from JavaScript to PowerShell, the code routes the launch through Windows Management Instrumentation, calling WbemScripting.SWbemLocator, connecting with ConnectServer(), and creating the process via Win32_Process.Create(). The chain becomes JavaScript to WMI to PowerShell. To a monitoring tool, it now looks like a legitimate Windows management component starting a process rather than a script doing something it should not. As the SANS write-up notes, that small detour is often enough to weaken the behavioral logic many EDR products rely on.

Stage Three: PowerShell Built to Be Unreadable

The PowerShell that runs next is wrapped in several layers of obfuscation. Instead of plain code, the script arrives as blocks of text deliberately polluted with meaningless filler. At runtime it strips those insertions out and rebuilds the real code in memory. A second routine reconstructs hidden commands by pulling out every fourth character from the polluted strings, according to the researcher’s analysis.

On top of that, the payload is Base64-encoded and XOR-encrypted with a static key (reported in the SANS diary as the string “Identificational”). Everything stays encrypted until the moment of execution, so a static scan of the file finds almost nothing worth flagging. Once decoded, the script reaches out to a remote endpoint, pulls down the next stage, and tucks it away inside the user’s profile directory, all without dropping a recognizable malware binary early in the chain.

Stage Four: Loading the Payload Without Touching Disk

The second-stage file looks broken at first glance, as if it were corrupted or encrypted. A closer look showed the malicious code had been buried deep inside the file rather than placed where you would expect it. The loader carves out that hidden chunk and loads a reflective .NET assembly straight into memory using the .NET reflection APIs.

Reflective loading is popular for a reason: it skips writing an executable to disk, which is exactly where antivirus scanners do most of their work. From there the loader fetches the final piece, and that piece is Remcos RAT.

The Payload: Remcos Hiding Inside a Trusted Process

With Remcos in place, the attacker has full remote control of the machine. To stay hidden, the malware injects itself into a legitimate Windows process, backgroundTaskHost.exe, so its activity blends into normal system behavior. It then opens an outbound channel to attacker-controlled command-and-control infrastructure and settles in.

From that position Remcos can do the usual damage: stealing credentials, exfiltrating files, logging keystrokes, capturing screenshots, manipulating processes, running commands, and pulling down additional malware whenever the operator wants.

Why the Container Matters More Than the RAT

It is worth saying plainly: the noteworthy part of this campaign is not Remcos. The noteworthy part is the delivery. Most security architecture is still built around catching executable malware, malicious macros, and browser exploits. Meanwhile, attackers are increasingly hiding their payloads inside trusted file structures that glide through enterprise workflows untouched.

Virtual disk formats like VHDX are a textbook example of that blind spot. This chain did not succeed because the payload was advanced. It succeeded because the malicious content lived inside a file type that first-line controls simply do not open up and examine closely enough.

The Case for Inspecting the File Itself

Campaigns like this point to a broader shift. Files are no longer just attachments to be scanned; they are engineered delivery containers, designed specifically to get past your controls before any malware actually runs.

That is why approaches built on deep file inspection, such as Content Analysis, Disarm and Reconstruction (CADR), are becoming so relevant. Rather than waiting for malicious behavior to surface after execution, CADR focuses on the file itself. It opens embedded active content, examines hidden scripts, unpacks nested containers, looks for abnormal file structures, removes dangerous executable logic, and rebuilds a clean, safe version of the file before anyone interacts with it.

Apply that to this campaign and the chain falls apart early. Stop the VHDX container before it ever exposes that obfuscated JavaScript, and there is no WMI call, no PowerShell decoder, no in-memory loader, no persistence key, and no Remcos. The infection never reaches the second stage because the first one was disarmed.

The takeaway is simple enough to put on a sticky note. The malware may run entirely in memory, but the compromise still begins with a file. And that file is fast becoming the most important place to fight back.

References

Note: This article summarizes publicly reported research, principally the SANS Internet Storm Center analysis by Xavier Mertens, for commentary on container-based malware delivery and content disarm and reconstruction defenses. Technical particulars may evolve as the campaign is tracked further.