Tax-themed phishing now uses VHDX loading to deliver Overlord RAT

At a glance

What this is: A Gurucul threat report details a tax-themed phishing campaign that uses a malicious VHDX image and DLL sideloading to deliver Overlord RAT with minimal disk-based artefacts.

Why it matters: It matters because defenders need to treat mounted virtual disks, sideloaded DLLs, and in-memory payload execution as linked detection problems across endpoint and identity-adjacent controls.

Context

Phishing campaigns increasingly blend social engineering with file formats that look ordinary to users but are operationally useful to attackers. In this case, the security gap is not just user trust in a tax-themed message, but the way Windows-native mounting of VHDX images can turn a downloaded file into an apparently local drive and lower suspicion before malware execution begins.

The identity angle is indirect but real: the lure abuses institutional trust in a government tax authority, while the malware chain relies on execution from a mounted image rather than a credentialed service account or workload identity. For defenders, the important point is that the trust boundary is being manipulated at the point of user execution, not at a later persistence stage.

This is a classic example of a campaign that is atypical in delivery but typical in intent. The unusual container format is what makes it operationally interesting, not the final malware objective.

Key questions

Q: What breaks when phishing payloads are delivered through mounted VHDX images?

A: Mounted VHDX images break assumptions that downloaded content stays visibly remote and easy to inspect. Once users mount the image, the payload looks like local storage, which can bypass weak attachment controls and encourage execution of a fake installer or document. Defenders need behavioural monitoring for mount-and-execute chains, not only file reputation checks.

Q: Why do DLL side-loading attacks remain effective against traditional endpoint controls?

A: They remain effective because the attack often starts inside a legitimate program and leaves little disk evidence. Traditional tools are good at file reputation and static signatures, but they are weaker against trusted executables that load malicious libraries and then steal identity data from memory during normal use.

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 teams respond when phishing combines persistence, evasion, and cleanup?

A: Teams should assume the initial lure is only one stage of the incident and preserve host telemetry as soon as the chain is suspected. Focus on the mount event, sideloaded DLL, persistence artefacts such as Run keys, and any DNS or C2 activity before cleanup removes the visible container. Containment depends on stitching those stages together quickly.

Technical breakdown

Why VHDX delivery changes initial access handling

A VHDX file is a virtual hard disk container that Windows can mount as a local drive. That matters because users often treat mounted drives as trusted storage rather than as downloaded content, and some email and web controls inspect them less aggressively than standard archives. In this campaign, the attacker used that trust shift to package the fake tax assessment application and its supporting DLLs inside a mountable image. The technical risk is not the container alone, but the way it creates a cleaner path from phishing lure to user execution without the obvious friction of an executable attachment.

Practical implication: detection needs to flag newly mounted VHDX images opened from untrusted download sources, not just malicious attachments.

How DLL sideloading turns a legitimate app into a loader

DLL sideloading works when an application loads a malicious library from its own directory before or alongside the expected legitimate library. Because the parent executable is signed or appears plausible, defenders can miss the execution chain if they only watch for suspicious binaries at the surface. In this campaign, the fake tax application launched a malicious DLL that in turn loaded the genuine library to preserve normal app behaviour. That separation lets the malware hide inside routine process startup while gaining code execution early enough to stage memory-only payload delivery.

Practical implication: hunt for unexpected DLLs loaded from user-writable directories by otherwise legitimate executables.

Why memory-only shellcode and anti-analysis checks matter

The loader did not rely on dropping a final payload file to disk. Instead, it decrypted shellcode in memory, validated the environment through username, process, driver, and graphics checks, and only then executed the final Overlord RAT payload. This design compresses the attack into a short-lived execution window and reduces the forensic artefacts available to static tools. The anti-analysis checks are especially important because they reveal an operator assumption that sandboxes and analyst workstations are expected parts of the detection chain. That means defenders need behavioural correlation, not single-event alerts.

Practical implication: prioritise behavioural detections for in-memory execution, sandbox evasion, and suspicious persistence over file hash matching.

Threat narrative

Attacker objective: The attacker’s objective was to gain durable remote access to victim endpoints while avoiding traditional file-based detection and preserving post-compromise control.

1. Entry began with a tax-themed phishing lure impersonating Singapore’s IRAS and directing the target to download a malicious VHDX image.
2. Credential access was not the initial goal here, but the attacker gained execution opportunity by convincing the user to mount the image and launch the fake assessment application, which then enabled DLL sideloading and shellcode decryption.
3. Escalation and persistence followed through in-memory Overlord RAT deployment, registry Run-key persistence, and command-and-control communications that supported post-compromise control.
4. Impact included long-lived remote access, keylogging capability, and cleanup of the VHDX artefact to reduce forensic visibility.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

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

VHDX delivery is a trust-boundary problem, not just a malware-container problem: When attackers use a mountable disk image, they exploit the mental model that local drives are safer than downloaded files. That weakens controls that are built around email attachments and archive inspection alone. Defenders need to treat mounted images as executable delivery surfaces and align monitoring with user-driven mount events.

DLL sideloading remains effective because endpoint controls still over-index on the obvious parent process: A legitimate-looking executable can be the delivery wrapper for a malicious library, and the actual malicious behaviour may begin before the user notices anything unusual. This campaign shows why application trust and library trust cannot be separated in endpoint policy. Teams should assume the execution chain is the attack surface, not the file name on the desktop.

Memory-resident execution is now a core evasion pattern, not an advanced edge case: The combination of encrypted shellcode, runtime decryption, and anti-analysis checks is designed to defeat static scanning and delay dynamic observation. In practical terms, this shifts the defender’s problem from malware identification to behavioural correlation across mount events, process creation, DLL loads, and network activity.

Endpoint detection priorities need to move toward staged execution correlation: When the payload is delivered through a mounted image and only becomes visible after several runtime checks, single-event alerts create too much blind space. The right response is to correlate suspicious download source, image mounting, sideloading, persistence, and outbound DNS behaviour into one detection story. That is the control gap this campaign exposes.

Malicious VHDX chaining creates a detection gap between user trust and host telemetry: The real failure mode is the assumption that a file which mounts successfully is therefore safe enough to execute from. Once that assumption breaks, traditional file reputation and attachment filtering lose much of their value. Practitioners should treat mounted-image execution as a separate governance and detection class, especially where phishing lures use institutional branding.

What this signals

Malicious mounted-image delivery creates a detection blind spot between phishing and endpoint execution: The campaign shows that once a VHDX is mounted, the threat model shifts from attachment filtering to host-based behavioural correlation. Security teams should expect more abuse of native file formats that make downloaded payloads appear local and therefore less suspicious.

Staged loaders are increasingly built to defeat single-control detection: DLL sideloading, runtime string decryption, memory-resident shellcode, and anti-analysis checks work together as one chain. The practical response is to correlate process lineage, library loads, persistence writes, and outbound DNS into a single investigation path rather than treat them as unrelated alerts.

For practitioners

• Instrument mounted image execution Alert on downloaded VHDX images that are mounted and then used to launch executables from the new virtual drive, especially when the source domain is newly observed or impersonates a trusted authority.
• Detect sideloading by trusted launchers Build detections for legitimate applications loading unexpected DLLs from the same directory, followed by immediate child-process creation, shellcode decryption, or network activity.
• Correlate anti-analysis behaviour Treat sandbox checks, debugger enumeration, virtualization-driver inspection, and graphics-adapter validation as one behavioural cluster rather than isolated events.
• Harden persistence monitoring Watch for new Run-key values created by user-context malware, especially when the value name resembles Windows components and appears shortly after mounted-image execution.
• Join host and network telemetry Correlate hidden PowerShell, DNS lookups to low-prevalence domains, and immediate outbound connections so post-execution cleanup does not mask the intrusion path.

Key takeaways

• This campaign shows that the real weakness is not one file type but the way trusted containers and familiar launchers can be chained into a stealthy delivery path.
• The report documents a multi-stage infection chain that uses mounted VHDX delivery, sideloading, in-memory shellcode, anti-analysis checks, and post-execution cleanup to reduce forensic visibility.
• Defenders need behavioural correlation across mount events, DLL loads, persistence creation, and network activity because static file inspection alone will miss the attack sequence.

Key terms

• VHDX Image: A VHDX image is a virtual hard disk file that Windows can mount like a real drive. In malware campaigns, that native trust can be abused to package executables and DLLs inside what looks like local storage, reducing user suspicion and sometimes bypassing simple attachment controls.
• 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.
• In-Memory Shellcode Execution: In-memory shellcode execution is a technique where decrypted payload code runs directly in memory rather than being written to disk as a normal executable. That approach limits file-based indicators, complicates static analysis, and shifts defensive value toward behavioural monitoring and memory-aware detection.
• Anti-Analysis Techniques: Anti-analysis techniques are behaviors malware uses to slow down, confuse, or mislead human and automated inspection. They include sleep loops, junk arithmetic, timing checks, and misleading control flow. Their purpose is not stealth alone, but to delay detection long enough for the payload to reach its main logic or network stage.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect identity controls to the wider security programme they run every day.