In June 2026, a security researcher pulled apart a malicious email attachment and traced it through seven distinct stages to a fully operational remote access trojan. The malware ran almost entirely in memory. Antivirus barely noticed. Yet the entire operation depended on a single decision the victim’s machine made automatically, and that decision is exactly where a content-trust model breaks the chain.
Case Study: A walkthrough of the VHDX-to-Remcos campaign documented by SANS ISC
The abstract argument for content trust is easy to make and easy to wave away. So let’s not stay abstract. Let’s take one real, publicly documented campaign, follow it from the inbox to full compromise, and see precisely where a prevention-first, structural approach would have ended it, and why every detection-based control in its path had such a hard time.
The case comes from the SANS Internet Storm Center, where handler Xavier Mertens analyzed a sample reported by a reader in June 2026. It is an ordinary campaign in the sense that nothing about it is exotic or nation-state grade. That is what makes it useful. This is the kind of thing that lands in enterprise inboxes constantly.
The chain, stage by stage
The full path from delivery to control runs through seven stages, each one handing off to the next:
It begins with a phishing email carrying a ZIP archive. Inside the ZIP is not a document but a VHDX file, a Microsoft virtual hard disk image, the same format Windows uses for virtual machines and backups. On any modern Windows system, opening that VHDX mounts it automatically as a new drive letter, and the moment it mounts, it exposes a JavaScript file with an innocuous German name, “Partnerschaft_fur_neue_Angebotsanfrage.js,” or “partnership for new quotation request,” aimed at German-speaking recipients.
From there the stages cascade. The JavaScript kicks off a PowerShell decoder. The decoder unpacks a second PowerShell stage that acts as a .NET loader. The loader pulls down shellcode that functions as a downloader, and the downloader retrieves and runs Remcos, a commercial remote access tool long since repurposed by criminals to take full, covert control of a victim’s machine. By the end, the operator can watch the screen, log keystrokes, browse the file system, and run commands at will.
Why the detection stack struggled
Here is the detail that should give any detection-first security team pause. When the researcher checked the JavaScript file against VirusTotal, it scored five detections out of fifty-seven engines. The overwhelming majority of the industry’s antivirus products looked at the actual malicious script and saw nothing worth flagging.
That is not a failure of any one vendor. It is a structural property of how the campaign was built, and it is worth understanding stage by stage.
The VHDX container is the first evasion. Security tools are tuned to scrutinize the file types that commonly carry threats: executables, Office documents, PDFs, scripts. A virtual disk image is a trusted, mundane format that most controls wave through, and its contents are not inspected until Windows mounts it and exposes them. The container buys the payload a free pass through the first line of defense. The researcher noted this directly, observing that using a disk image as a malware container is an old technique that had fallen out of fashion and is now being dusted off precisely because it still works.
The obfuscated JavaScript is the second evasion, and its low detection score shows how well it worked. The in-memory PowerShell and .NET stages are the third. Nothing meaningful is written to disk as a conventional executable, so there is little for a file scanner to catch and little forensic residue left behind. Each stage exists mainly to unpack the next, and the real payload only assembles in memory late in the chain, long after the initial file cleared the perimeter.
Detection-based defenses are being asked to win a race they are structurally disadvantaged in. The container hides the payload from the perimeter, the obfuscation defeats signatures, and the in-memory execution leaves almost nothing to scan. Each layer is chosen specifically to be invisible at the moment of analysis. Against a chain engineered for exactly that, the most reliable move is to stop relying on analysis and neutralize the file itself.
The single point where it all depends
Trace the chain backward and notice something. Every clever, evasive, in-memory stage after the first is contingent on one event: the VHDX mounting and exposing that JavaScript. No mount, no script. No script, no PowerShell decoder. No decoder, no loader, no shellcode, no Remcos. The entire elaborate sequence rests on a single file being accepted, opened, and trusted enough to auto-mount.
This is the pattern behind nearly every file-borne intrusion, and it is easy to lose sight of amid the impressive technical footwork of the later stages. The malware may run entirely in memory, but the compromise still begins with a file. That file is the load-bearing element, and it is the one place in the chain where a defender has complete leverage, because it is the one place that exists before anything executes.
The chain through the content-trust lens
Now walk the same campaign through a content-trust model, the kind of structural, prevention-first approach we have described across this series. Instead of asking “does this file look malicious?” the question becomes “what is this file, structurally, and does its content belong?”
A Content Analysis, Disarm and Reconstruction layer does not scan the VHDX for known-bad patterns and it does not detonate it in a sandbox to watch what happens. It parses the container’s structure directly, at the boundary, before it ever reaches the user’s machine to be mounted. It recursively opens what is nested inside, examines the objects it finds, and identifies active and executable content that has no legitimate place in the delivered file. An unsolicited virtual disk image arriving by email, containing an obfuscated script set to run on mount, is a structural anomaly regardless of whether any signature recognizes the script. The engine then reconstructs a clean version of the delivered content from trusted components, and the executable JavaScript is simply not carried through the reconstruction.
Apply that to this campaign and the chain collapses at stage three, before stage four ever exists. Disarm the VHDX at the boundary and there is no exposed JavaScript, which means no PowerShell decoder, no .NET loader, no shellcode downloader, and no Remcos. Six of the seven stages never occur, not because they were detected and blocked, but because the one file they all depend on was rebuilt into something safe before it arrived.
Where each approach engages
Detection waits for the payload to reveal itself, then races to catch obfuscated, in-memory behavior after the file has already been accepted and mounted. On this campaign, most engines lost that race.
Content trust engages at stage three, at the file boundary, before the mount. It does not need to recognize the specific threat, because it removes the category of active content the chain depends on.
Why obfuscation stops mattering
The most important thing about this approach is what it does to the attacker’s best tricks. The whole reason the JavaScript scored five out of fifty-seven is that it was obfuscated to be unreadable to signature engines. But a content-trust layer never needs to read the obfuscated code or understand what it does. It only needs to recognize that executable script content is present in a delivered file where it does not belong, and remove it during reconstruction. Obfuscation is a defense against being understood. It is no defense against being removed.
The same logic applies to the container trick. It does not matter that a VHDX is a trusted format the perimeter usually ignores, because the content-trust layer is not deciding whether to trust the format. It is opening the container, looking at what is inside, and rebuilding it clean. And it applies to the in-memory execution too, because if the first file never carries its payload through, there is no later stage to execute in memory or anywhere else. Each of the attacker’s three evasions was designed to defeat a defender who is trying to analyze the threat. None of them helps against a defender who simply refuses to carry active content across the boundary.
The takeaway
This campaign is not remarkable, and that is the point. It is a competent, unglamorous piece of criminal tradecraft that slipped past most of the industry’s detection engines using techniques that are individually well known. It worked because it was engineered around a simple truth: if you can get a trusted-looking file accepted and opened, everything that follows can be built to stay invisible.
A content-trust model refuses to play that game on the attacker’s terms. It moves the decisive moment upstream, to the file at the boundary, before the mount and before the first line of script runs. Defend that file, rebuild it from what is provably safe, and the six stages of clever evasion behind it have nothing to stand on. That is the difference between racing the malware after it arrives and ensuring the weapon never crosses the threshold, and it is the principle FileDNA CADR is built on: analyze each inbound file, disarm what does not belong, and reconstruct clean, usable content before it reaches the user, the endpoint, or anything downstream.
References
Primary source: Xavier Mertens, “From a VHDX File to a Remcos RAT,” SANS Internet Storm Center Diary, June 16, 2026. Corroborating coverage: Iron Castle Systems (syndicated SANS analysis) and SOC Prime threat brief. Technical details, including the seven-stage chain, the auto-mount behavior, the German-language JavaScript lure, and the 5-of-57 VirusTotal score, reflect the SANS reporting. This article synthesizes publicly reported research for commentary on container-based delivery and content disarm and reconstruction defenses.
This is the applied case study in an ongoing series on where enterprise security architecture is heading. Read the conceptual companions on why content trust is the AI era’s new security layer, understanding a file instead of guessing whether it’s malicious, and how AI ingestion changes the blast radius, or explore the FileDNA platform.