Table of contents
Security insight: The invisible threat lurking inside modern endpoints
Security teams working toward Zero Trust eventually reach a challenging but decisive question: how much freedom is an attacker permitted once they land on an endpoint? The answer to this question shapes whether ransomware, remote access trojans, and other malware tools can operate out of sight.
A common malicious control point is an attacker’s potential ability to run virtual machines locally on a compromised host. When abused, virtualization tools give attackers a concealed, isolated execution environment that most defenders cannot see.
Recent reporting, including a widely circulated Dark Reading investigation, shows attackers enabling Hyper-V on Windows systems and deploying a lightweight Linux virtual machine (VM) to run a post-exploitation toolkit. Because nearly all malicious activity occurs inside the virtualized guest operating system, many EDR products on the host barely detect anything unusual.
This trend has reached the point where VM-based attack chains must now be treated as a core security threat, not a fringe tactic.
Understanding the invisible threat of attacker-controlled VMs
Virtualization is fundamental to modern IT, but it also introduces a security blind spot.
ThreatLocker Chief Product Officer Rob Allen summarized the risk:
“Threat actors increasingly use virtualization technologies to create a separate execution environment inside a compromised endpoint. Built-in Windows components like Hyper-V make it easy for an attacker with initial access to start a malicious VM. The VM is an isolated space to safely run their tools.”
Once a threat actor moves into their new VM, several advantages emerge over simply having remained on the physically installed operating system:
1. Reduced visibility across host-based EDR
Most threat detection engines in EDR and XDR products monitor the host operating system but do not have visibility into any running virtual operating systems. To inspect and scan the processes, memory, and user behavior within a VM, detection agent software needs to be installed onto it the same way its installed onto any physical computer, something an attacker probably isn’t going to do.
2. Execution of unsigned or malicious tools
Application allowlists cannot prevent execution inside the VM because, like EDR and XDR platforms, their enforcement typically stops at the hypervisor boundary.
3. Concealed command-and-control (C2)
Network traffic originating inside the VM still has to make its way through the victim host computer and network boundary to the attacker’s C2 hosts. Successful evasion through a custom reverse shell and reverse proxy squashed any opportunity the victim in the Dark Reading article had to stop or detect suspicious traffic. Any successfully deployed malicious VM is free to run any tools and software within itself to help disguise traffic with impunity.
4. Evading file-based scanning
A VM’s virtual hard disk or ISO image are a black box to detection and vulnerability scanners on the host. Any file scanning performed against the physical operating system will only see the unmounted drive or image file, not its enumerated file contents.
5. Breaking audit trails
Most event logs, application logs, and EDR telemetry do not capture what happens in virtualized environments unless the VM itself has an EDR agent installed or is configured to send logs externally. VMs could need to be individually configured to forward any such log and event data elsewhere, something else an attacker probably isn’t going to want to do.
In short, attackers use virtualization to transform the endpoint into a black box.
With even minimal access, they can deploy a private sandbox that security tools cannot reach.
Real-world examples of virtualization abuse
Besides the attack detailed above, attackers have increasingly weaponized VMs in these other real-world scenarios:
1. VMs used for covert red-team persistence
Red-team operations have reported creating covert VMs on compromised endpoints to maintain persistent access even after defenders clean the host of malicious payloads. The VMs themselves do not appear malicious and, on computers expected to act as a VM host, may be hard to notice among throngs of other, legitimate VMs. Even after powering the host off and on, VMs are often configured to restart automatically, affording attackers a persistent backdoor.
2. ISO-based VM loaders in ransomware operations
Several ransomware groups ship malicious ISOs that auto-deploy into a VM environment where it may run out of sight of detection tools. Files on the host are encrypted while detection tools remain oblivious, only ever observing file hash digests suddenly changing, with no way to stop the process.
3. Cloud-synchronized VM images
Attackers upload premade VMs with full malicious toolsets to OneDrive, Dropbox, or Google Drive. Once attackers have made their way inside a target environment, they simply browse to their cloud storage account, download their tools, and run them.
These incidents demonstrate a clear trend: Virtual machines are no longer admin conveniences; they are attacker hideouts.
How Zero Trust makes VM-based attacks preventable
Stopping VM-based attacks does not require developing or constantly updating new detection heuristics and behavior patterns for detection and scanning agents to use.
It requires a commitment to denying application executions by default, especially against hypervisors.
This is where the ThreatLocker Zero Trust model becomes essential.
Zero Trust countermeasure 1: Block Hyper-V by default
Hyper-V is not required on most workstations.
ThreatLocker denies Hyper-V execution by default because:
- It often introduces unnecessary risk.
- It can be activated silently through PowerShell.
- It becomes an execution gateway for attacker-controlled VMs.
If a threat actor attempts to enable Hyper-V, ThreatLocker Allowlisting policies stop the hypervisor before it starts.
Zero Trust countermeasure 2: Block all other virtualization tools unless explicitly approved
Hyper-V is not the only risk.
Attackers regularly abuse other hypervisors and virtualization technologies, such as:
- VMware Workstation
- VMware Player
- VirtualBox
- QEMU
- Parallels
ThreatLocker Application Allowlisting prevents execution of any hypervisor, installer, or Windows process that has not been intentionally approved.
This means:
- No user can install a VM tool on their own
- No attacker who has already gained access to a host can sideload a hypervisor
- No VM can ever launch on the host.
In Zero Trust environments, hypervisors, along with every other application, are prevented from launching unless they are explicitly permitted to do so.
Learn more about how ThreatLocker controls application execution
System hardening beyond hypervisors
If business operations demand that hypervisors must be allowed on certain endpoints, network and security administrators can take proactive steps to harden system components and controls against VM-based attacks.
A hardened environment should defend against:
1. Virtual disk images (VHDX, VHD, and ISO files)
Without restricting storage to secure locations, attackers may:
- Mount malicious virtual hard disks
- Load VM snapshots containing preloaded hacking tools
- Bootstrap portable Linux environments
ThreatLocker Storage Control blocks unauthorized mounting or manipulation of these file types. ThreatLocker Ringfencing may be added to Allowlisting policies to restrict hypervisors to specific files and file paths, ensuring only legitimate virtual hard disks are accessible and mountable.
2. Offline disk access and hypervisor tampering
BitLocker encryption on hypervisor hosts prevents:
- Offline mounting
- Cold-boot theft
- Direct disk manipulation
- Accessing sensitive files without authentication
3. PowerShell as a virtualization enabler
Attackers rely on PowerShell commands to programmatically open applications and launch system tools and processes without a graphical interface, or even human interaction. With PowerShell, attackers can:
- Enable and launch Hyper-V
- Deploy new VMs
- Mount virtual hard disks
- Configure networking between other VMs, the host operating system, and the internet
Ringfencing prevents PowerShell from accessing sensitive resources or launching other applications. Likewise, Ringfencing may restrict applications permitted through Allowlisting policies from launching PowerShell.
Check how ThreatLocker RIngfencing helps block these high-risk behaviors
Managing misconfiguration: The hidden attack surface
When attackers cannot directly execute hypervisors, they exploit misconfigurations in security settings and other unhardened resources, like:
- Unmonitored local administrative accounts
- Forgotten and unused developer tools
- Group policy objects that enable Hyper-V features
- Local file folders synced to a cloud storage provider that store VM images
ThreatLocker Defense Against Configurations (DAC) addresses this by running ongoing checks to identify weak or overly permissive settings and gaps in Windows configurations that increase risk. In a hardened environment, these details often determine whether an attacker can progress.
Security teams also consistently recommend removing local administrative rights wherever practical. Without admin access, attackers have a much harder time modifying registry settings, disabling protections, or re-enabling previously disabled system settings.
When Zero Trust principles are applied consistently, virtualization is controlled rather than merely assumed to be safe. Blocking unapproved hypervisors and hardening supporting components reduces the options available to attackers and limits their ability to operate out of sight of the physical operating system.
Learn more about how DAC help closing missconfigurations
Managing local admins
Most enterprise environments’ identity and access management ecosystems will at least require a logged-in user to open a hypervisor or launch a VM with administrative privileges. Properly managing and securing admin rights and user credentials cuts off one of the most common initial vectors for modern cyberattacks, not just VM-based ones.
ThreatLocker Elevation Control provides:
- Temporary, audited, just-in-time elevation
- An instantaneous elevation approval workflow required privileged applications, like hypervisors
- Denial of privilege escalation attempts from untrusted processes or users
Even if a user accidentally opens or executes a malicious file, Elevation Control ensures it cannot run with elevated privilgesr.
Reduce the risks of virtualization with consistently applied Zero Trust controls
ThreatLocker hardening checklist
Protect against VM-based attacks, and all other attacks, with the following ThreatLocker products:
1. Application Control
- Deny applications, including hypervisors, by default everywhere in a network, across every endpoint.
- Explicitly approve only required software and virtualization tools.
- Automatically baseline every piece of legitimate software installed on every endpoint, including their dependencies.
2. Ringfencing
- Prevent PowerShell and other administrative tools and processes from interacting with hypervisor or virtual hard disks.
- Block inter-process communication between applications that don’t need to be integrated.
- Restrict outbound network access for any explicitly allowed hypervisors.
3. Storage Control
- Block unauthorized virtual hard disks, ISOs, and accessing file paths containing legitimate VM images.
- Enforce encryption on removable drives and devices.
- Apply read-only rules to critical file shares and paths.
4. Elevation Control
- Enforce just-in-time elevation on all application executions.
- Deny privilege escalation from untrusted users and processes.
- Review all elevation attempts, approvals, and denials in an integrated log viewer.
5. Monitoring and response
- Filter and search audit logs for hypervisor executions and VM-specific system processes.
- Forward ThreatLocker logs to another SIEM with built-in integrations
Frequently Asked Questions
Why are virtual machines used in cyberattacks?
Attackers use virtual machines because they create an isolated environment where malicious tools can run without detection by host-based EDR or antivirus tools.
How does Zero Trust stop VM based attacks?
Zero Trust blocks software hypervisors, the layer of technology between a physically installed operating system and the virtual machines it hosts. If hypervisors like Hyper-V, VMware, or VirtualBox cannot execute, the attacker cannot deploy a hidden VM.
Can Hyper-V be abused by attackers?
Yes. Threat actors can enable Hyper-V through PowerShell and launch a VM to run malicious tools encapsulated from network and endpoint defenses. If attackers intending to launch a malicious VM are able to penetrate a network, blocking Hyper-V prevents the rest of their attack chain.
What tools does ThreatLocker use to block virtualization abuse?
ThreatLocker uses Application Allowlisting, Ringfencing, Storage Control, Elevation Control, and Network Control to block unapproved hypervisors and restrict VM deployment.
Do organizations need virtual machines on all endpoints?
No. Most users do not require hypervisors. Blocking VM tools everywhere except approved development environments or dedicated hypervisor servers dramatically reduces attack surface.
