The VM Next Door: When Threat Actors Build Their Own Blind Spots

Executive Summary 

In multiple recent incidents, we have observed threat actors deploying lightweight virtual machines onto compromised servers. These VMs, often running stripped-down Linux distributions consuming as little as 120MB of disk space, establish outbound connections to attacker infrastructure while remaining completely invisible to the host's security stack. The technique is elegant in its simplicity and devastating in its effectiveness. 

The Fundamental Problem: EDR's Architectural Blind Spot 

Endpoint detection and response tools work by monitoring processes, file system activity, network connections, and system calls on the host operating system. They hook into the kernel, intercept API calls, and build behavioural models of what legitimate activity looks like. When something deviates from that baseline, alerts fire. 

But here's the problem. A virtual machine is, from the host's perspective, just another process. VirtualBox appears as VBoxHeadless.exe. QEMU might be renamed to something innocuous. The hypervisor process itself does nothing overtly malicious. It simply emulates hardware and executes whatever operating system runs inside it. 

The EDR agent on the host has no visibility into the guest operating system. It cannot inspect the processes running inside the VM. It cannot see the files being created on the virtual disk. It cannot examine the network traffic originating from within the virtualised environment before it leaves via the host's network adapter. The VM is a black box. 

This creates a perfect hiding place. Threat actors can deploy malware, establish reverse shells, exfiltrate data, and maintain persistent access to a network without triggering a single EDR alert. The legitimate hypervisor process provides cover for everything happening inside. 

Why Threat Actors Are Adopting This Technique 

The motivation is straightforward. EDR has become genuinely effective. Modern endpoint protection regularly blocks ransomware deployment, catches lateral movement, and interrupts credential harvesting. Threat actors have responded by developing increasingly sophisticated evasion techniques: BYOVD attacks using signed vulnerable drivers, direct syscalls to avoid usermode hooks, and in-memory execution to evade static analysis. 

Virtual machine deployment represents the logical endpoint of this arms race. Rather than trying to evade detection on the host, attackers simply move their operations into an environment where detection doesn't exist. It's not about being stealthy. It's about being invisible. 

The technique offers several operational advantages: 

Complete operational freedom. Inside the VM, attackers can run any tools they want. Port scanners, password crackers, data compression utilities, exfiltration frameworks. None of these trigger host-based detection because the host cannot see them running. 

Persistent access. The VM can be configured to start automatically when the host boots. Even if defenders detect suspicious activity and respond, they may not think to look for rogue virtual machines. The persistence mechanism survives incident response actions that focus on traditional indicators. 

Network obfuscation. Depending on the network configuration, traffic from the VM may appear to originate from a different IP address or hostname than the compromised host. Bridged network adapters can make the VM look like a separate physical machine on the network. This can also delay response activity whilst the security team are hunting for an IP address nobody recognises.

Clean forensic environment. The virtual disk is a self-contained file. Attackers can delete it when they're finished, leaving minimal traces. No browser history, no event logs, no prefetch files on the host pointing to their tools. 

Technical Implementation: How It Works in Practice 

The deployment typically follows a consistent pattern. After gaining initial access through whatever means, whether phishing, exploited vulnerabilities, or purchased credentials, attackers establish a foothold and begin reconnaissance. Once they've identified a suitable host, usually a server with sufficient resources and limited interactive use, they deploy the virtualisation infrastructure. 

QEMU-Based Deployments 

QEMU is particularly attractive for this purpose because it doesn't require installation. The entire emulator can be dropped as a portable executable along with a pre-built disk image. We've observed attackers deploying customised Tiny Core Linux images, some as small as 50MB, containing pre-configured backdoors. 

The QEMU process is often renamed to blend in. In one case, it appeared as fontdiag.exe in the user's profile directory. In another, it was placed in a folder mimicking Windows update infrastructure. The command line arguments specify a headless boot with no graphical interface, making it invisible to any user who might be logged into the compromised system. 

Inside the VM, a tool called Chisel establishes the command and control channel. Chisel is a legitimate open-source utility designed for creating TCP tunnels over HTTP, secured via SSH. It's commonly used by penetration testers and system administrators. In the hands of threat actors, it creates an encrypted tunnel from the VM through the host and out to attacker infrastructure. The traffic appears as HTTPS connections, blending with legitimate web traffic. 

Persistence is achieved by modifying startup scripts within the VM's Linux environment. The bootlocal.sh file executes Chisel automatically when the VM starts. A batch file or scheduled task on the Windows host ensures the QEMU process launches at system boot. The result is a persistent backdoor that survives reboots and operates entirely outside the host's security monitoring. 

Hyper-V and VirtualBox Approaches 

On Windows servers where Hyper-V is available, attackers take a slightly different approach. Rather than deploying a third-party hypervisor, they enable the native Windows feature if it isn't already active. This is particularly insidious because Hyper-V is a legitimate Microsoft component. Its presence raises no alarms. 

In one observed incident, after an initial persistence attempt using QEMU was detected and blocked, the threat actor pivoted to Hyper-V. They created virtual machines with names designed to blend in with the existing infrastructure: names like DC-BACKUP-02 or DVCS-PROD-01. To a defender quickly reviewing the Hyper-V manager, these appeared to be legitimate infrastructure VMs. Only careful examination of creation timestamps and configuration revealed they were rogue. 

VirtualBox deployments follow a similar pattern to QEMU. The attacker drops a portable installation of VirtualBox, often an older version that doesn't require kernel driver installation, along with a minimal virtual disk image. Shared folders are configured to give the VM access to the host's drives, enabling both data theft and the deployment of additional payloads. 

Observed Threat Actor Behaviour 

We have tracked this technique across several distinct incidents, with two particularly notable cases demonstrating the range of ways threat actors employ virtual machine persistence. 

Case Study: QEMU with SSH Tunnel 

In this incident, a threat actor compromised a Windows server that was not operating as a hypervisor. There was no legitimate reason for virtualisation software to exist on this machine. The attacker deployed QEMU with a minimal Linux image and established an outbound SSH connection to their command and control server. 

The SSH tunnel provided bidirectional access. The attacker could execute commands within the victim's network while all traffic appeared to originate from inside a process the EDR had no visibility into. The legitimate QEMU process made network connections, but the content of those connections and the activity inside the VM remained invisible. 

When this initial persistence was discovered and removed, the same threat actor returned and attempted a different approach. They enabled Hyper-V on several servers and created VMs with naming conventions matching the organisation's standards. This fallback behaviour demonstrates that attackers are not merely experimenting with this technique. They consider it a reliable persistence option worth attempting multiple times. 

Case Study: VirtualBox for Exfiltration 

A ransomware affiliate used VirtualBox not just for persistence but specifically to hide data exfiltration. After gaining access to the network and identifying valuable data, they deployed a VirtualBox VM with shared folder access to the host's file system. 

All data staging and compression occurred inside the VM. The files were packaged, encrypted, and transmitted to external infrastructure from within the virtualised environment. The host's monitoring saw VirtualBox making outbound connections, but had no visibility into the fact that terabytes of sensitive data were being stolen. The exfiltration appeared in no host-based logs. No file access events, no process creation for compression utilities, nothing. 

This approach adds a layer of operational security for the attacker. Even if defenders detect the VM and capture it for analysis, all evidence of the exfiltration is contained within that virtual disk. The host's forensic artifacts provide no indication of what was taken or where it went. 

Detection Strategies 

Detecting rogue virtual machines requires looking for indicators that traditional EDR may overlook. The following strategies provide coverage at different points in the attack chain. 

Process Monitoring 

Monitor for virtualisation binaries executing in unexpected locations. QEMU running from a user's profile directory or from a folder mimicking system paths should trigger immediate investigation. Look for VirtualBox or VMware components on systems without business justification for virtualisation software. 

Pay attention to command line arguments. Headless execution flags (-nographic, -display none) suggest automated operation rather than interactive use. Processes spawned by scheduled tasks or startup scripts deserve additional scrutiny. 

Hyper-V Monitoring 

On Windows servers, regularly audit the Hyper-V configuration. Compare the output of Get-VM against known good baselines. Investigate any VMs created outside change management processes. Pay particular attention to creation timestamps, especially VMs appearing shortly after suspected compromise events. 

Monitor for the Hyper-V role being enabled on systems where it should not exist. This requires an attacker to have administrative privileges, but the action itself may not trigger alerts in environments where role installation is not closely monitored. 

Network Analysis 

While EDR cannot see inside the VM, network monitoring can detect suspicious traffic patterns. Look for unusual outbound connections from hypervisor processes. QEMU or VirtualBox making SSH or HTTPS connections to external IP addresses warrants investigation, particularly if those addresses are newly observed or have poor reputation. 

Consider the volume and timing of connections. A hypervisor process maintaining persistent outbound connections, especially outside business hours, is abnormal. Legitimate virtualisation software rarely needs sustained external connectivity. 

File System Indicators 

Virtual disk images are large files with distinctive extensions: .vdi for VirtualBox, .vhdx for Hyper-V, .qcow2 for QEMU (albeit some threat actor qemu VMs we've seen were .db files). Monitor for the creation of these file types, particularly in unusual locations. User profile directories, temp folders, and paths mimicking system locations should never contain virtual disk images on production systems. 

Track the installation of virtualisation driver components. VirtualBox requires VBoxDrv.sys, even in portable deployments. QEMU may install virtio drivers. The presence of these components on non-virtualisation hosts indicates potential compromise. 

Key Detection Indicators

Prevention and Hardening 

Preventing this technique requires a combination of technical controls and operational practices. No single measure provides complete protection, but layered defences significantly raise the cost and complexity for attackers. 

Application control. Implement application whitelisting that prevents execution of virtualisation binaries on systems without legitimate need. Block QEMU, VirtualBox, and VMware Workstation executables on servers and workstations where virtualisation is not required. This doesn't prevent Hyper-V abuse but addresses third-party hypervisors. 

Disable unnecessary features. On servers that should not run virtual machines, disable Hyper-V at the BIOS level if possible, or remove the Windows feature entirely. Consider using Group Policy to prevent installation of the Hyper-V role on systems where it's not needed. 

Privilege management. Deploying virtual machines requires administrative privileges. Limiting the number of accounts with local administrator access reduces the attack surface. Implement just-in-time access for administrative tasks rather than persistent elevated privileges. 

Network segmentation. Even if a VM is deployed successfully, proper network segmentation limits its utility. Restrict outbound connectivity from servers to only necessary destinations. Require proxy authentication for internet access, which complicates the establishment of C2 channels from rogue VMs. 

Incident Response Considerations 

When responding to incidents where VM-based persistence is suspected, several additional steps should be incorporated into standard procedures. 

First, inventory all virtualisation software and running VMs across the environment. This should include not just Hyper-V managers and vCenter consoles but also searches for portable virtualisation binaries and disk images. Attackers may deploy VMs on systems where no hypervisor infrastructure is expected. 

Second, capture running VMs before powering down compromised hosts. A VM that is shut down can be deleted or its disk encrypted by defensive automation. If the VM disk is captured while running, forensic analysis can recover the attacker's tools, command history, and potentially their infrastructure details. 

Third, examine host logs for evidence of VM creation and management. Windows Event Logs record Hyper-V activity. File system timestamps show when virtualisation binaries were dropped. Process creation events may capture command line arguments revealing attacker techniques. These host artifacts provide context even when the VM itself has been deleted. 

Fourth, review network flow data for connections from hypervisor processes. Even though the content of traffic from within the VM is invisible, the metadata shows which external hosts the VM communicated with. This information is valuable for identifying attacker infrastructure and potentially compromised systems at other organisations. 

How Strand Helps

Traditional EDR solutions focus on behavioural analysis and threat detection. They're looking for malicious activity. The problem is that a hypervisor process doing hypervisor things doesn't register as malicious, even when the activity inside that hypervisor is catastrophic for your organisation.

Strand Intelligence takes a different approach. Our DFIR agent performs comprehensive forensic collection, capturing the raw data that incident responders need to identify anomalies, regardless of whether those anomalies triggered security alerts.

Running processes. Strand captures a complete inventory of running processes, including their paths, command line arguments, parent processes, and execution context. When a QEMU instance is running from a user's profile directory with headless flags, that anomaly is visible in Strand's collection even if EDR never flagged it. We see fontdiag.exe and immediately question why a font diagnostic tool is running with virtualisation arguments.

Network connections. Every active network connection is captured, mapped to its owning process. When VBoxHeadless.exe maintains a persistent outbound connection to an external IP address, Strand records that relationship. Your responders can pivot from suspicious destination to process to executable path in seconds, building the picture of what's actually happening on the endpoint.

Services and persistence. Strand collects service configurations, scheduled tasks, and startup items. The batch file that launches QEMU at boot, the scheduled task that restarts the VM if it crashes, the service registration for VirtualBox drivers: all of this is captured and available for analysis. Persistence mechanisms that slip past real-time detection are surfaced during forensic review.

The distinction matters. EDR asks "is this malicious?" and sometimes gets the answer wrong. Strand asks "what is running, what is it connected to, and how did it get there?" Those questions have objective answers that don't depend on behavioural heuristics or signature databases. A rogue VM might not look malicious to automated analysis. It absolutely looks anomalous to an experienced responder and to Strand.

When you're responding to a suspected intrusion, you need ground truth. You need to know what's actually on the endpoint, not what your security tools decided was worth alerting on. Strand provides that ground truth, and in the case of VM-based persistence, that visibility is often the difference between finding the attacker's foothold and missing it entirely.

Conclusion 

The use of virtual machines for persistence and evasion represents a natural evolution in attacker tradecraft. As endpoint detection becomes more effective, threat actors seek environments where that detection doesn't reach. A virtual machine provides exactly that: an isolated operating environment invisible to host-based security controls. 

This technique is not theoretical. We are observing it in real incidents, deployed by threat actors ranging from ransomware affiliates to more sophisticated operators. The tooling is mature, the disk images are small, and the detection gap is real. 

Defenders must adapt. Traditional endpoint monitoring remains essential but is no longer sufficient. Organisations need visibility into virtualisation activity, whether that's monitoring for unexpected hypervisor processes, auditing Hyper-V configurations, or analysing network traffic from virtualised workloads. The VM next door might be hiding your next breach. 

MITRE ATT&CK Reference 

This technique is catalogued as T1564.006: Hide Artifacts: Run Virtual Instance. Related techniques include T1059 (Command and Scripting Interpreter), T1071 (Application Layer Protocol), and T1572 (Protocol Tunneling) for the C2 mechanisms commonly deployed within rogue VMs.