The Mounted Guest EDR Bypass is a tactic used in cyber attacks to evade Endpoint Detection and Response (EDR) protections. This method involves removing EDR program files from a defenseless guest system on a hypervisor, enabling the deployment of ransomware without detection.
Summary
Stroz Friedberg Incident Response Services ("Stroz Friedberg") recently discovered a previously undocumented method used in the wild to bypass Endpoint Detection and Response ("EDR") products and eventually deploy ransomware. This method does not exploit any flaws in the EDR itself, but rather the inherent host-guest relationship of hypervisor servers and the virtual machines that they host. The technique involves mounting a virtual machine’s hard disk file on the host hypervisor server and deleting the EDR program files from the mounted volume. After the virtual machine is rebooted, the EDR is no longer present, leaving the virtual machine unprotected against malicious programs. This method is a simple yet effective way for threat actors to disable EDR from virtual machines hosted on a hypervisor.
Background
In the incident observed by Stroz Friedberg, threat actors escalated privileges and moved laterally to access a Windows 2012 Hyper-V server. At the time of the incident, an EDR solution was installed both on the Hyper-V server and its guest virtual machines. Even though the threat actor had administrative access to the network, the EDR in place likely acted as an obstacle to executing the ransomware binary.
Hyper-V is a virtualization technology, debuted on Windows Server 2008, that allows users to create and manage virtual machines within the Windows operating system. The host machine, or hypervisor, can host one or more virtual machines of various operating systems. The guest machine’s data is stored in a virtual hard disk file (.vhd or .vhdx). This setup requires less physical hardware and reduces operational costs, making it popular in many corporate networks.
CyberCX previously documented1 an EDR bypass technique that involved abusing administrative access to a hypervisor to create a new virtual machine without EDR installed. Malware was then deployed from this new, clean virtual machine. In the incident observed by Stroz Friedberg, the threat actor faced the same obstacle of EDR on hypervisor guest systems but used a different technique to circumvent it.
EDR Bypass
After logging into the hypervisor with administrative access, the threat actor turned off one of the guest virtual machines and mounted the associated vhdx file, attaching the guest virtual machine’s operating system drive as the data drive (H:) on the hypervisor. Subsequently, the threat actor recursively deleted the H:\Program Files\{EDR TOOL} folder from the virtual disk. If a user attempted to delete that folder from within the virtual machine when it was powered on, the operation would have failed due to the protections offered by the EDR and the operating system. Since the virtual machine was off, and there was no running operating system or EDR protecting those EDR program files, the folder deletion operation was successful. After removing the files, the virtual machine was restarted and booted without any EDR program files, allowing the threat actor to regain the same network access as before, but now without any EDR protection to mitigate potential threats.
In this instance, the threat actor logged into this virtual machine and executed a ransomware executable from this host, targeting every other host on the network for remote encryption. This is an example of how just one host on a network without EDR can compromise other systems that do have EDR. To execute this type of ransomware, the threat actor needed a system with SMB access to the network where they could run their malicious code. The EDR on the target systems alerted that a ransom event was occurring but did not prevent the encryption from happening.
Although the incident described above occurred in a Hyper-V environment, the technique is not exclusive to Hyper-V or the Windows operating system. The primary requirement for this method is the ability to mount virtual disk files on a hypervisor, which can be accomplished through many ways across hypervisors.
Incident Detection and Prevention
Once a threat actor has administrative access to a hypervisor, protecting the hosted virtual machines becomes a challenge. It is critical to take preventative measures to restrict unauthorized access. Consider the following methods to harden access to the hypervisor in your environment:
Implement Principle of Least Privilege (PoLP) for Access Control:
- Restrict Administrative Access: Limit hypervisor access to only the necessary subset of administrators, following the principle of least privilege. Avoid granting hypervisor access to all domain administrators, and consider creating separate, hypervisor-specific administrative accounts.
- Use Role-Based Access Control (RBAC): Implement RBAC policies to ensure that only specific roles have access to critical hypervisor management functions. This can further reduce the risk of unauthorized actions.
Isolate the Hypervisor Management Network:
- Segregate Network Traffic: Place the hypervisor management network in a separate, isolated VLAN. Only allow access from designated IP ranges or machines and ensure that these connections are highly restricted and monitored.
Use Dedicated Systems for Hypervisor Management Access:
- Restrict Access Points: Ensure that only dedicated, hardened systems can access the hypervisor management interface. These systems should be isolated from general-purpose workstations to reduce the risk of lateral movement from compromised endpoints.
For additional Hyper-V specific security recommendations, please refer to Microsoft's official guidance on hypervisor hardening and best practices.
Additionally, organizations can make efforts to detect this EDR bypass technique by alerting on or implementing an automated response when one of the following events is detected.
Non-C Drive mounting events on the hypervisor:
- Microsoft-Windows-Ntfs/Operational: Event ID 142
- An NTFS-formatted drive was attached to the system. Monitor for unusual mounting events, particularly those that are non-C drives, as these could indicate an attempt to mount virtual disks.
Errors related to EDR not being able to run on guest machine startup:
- System: Event ID 7000
- The {EDR Tool} service failed to start due to the following error: The system cannot find the file specified.
Shutdown of a virtual machine or an unresponsive host in the EDR console:
- Hyper-V server
- Microsoft-Windows-Hyper-V-Worker-Admin: Event ID 18502
- A virtual machine was turned off.
- Guest system
- System: Event ID 6006
- The event log service was stopped, potentially indicating a clean shutdown by the guest machine. If the machine is turned off from the hypervisor, then this event may not be generated.
The fidelity of these indicators can vary depending on the baseline activity within an environment. Fine-tuning thresholds, excluding known maintenance periods, and aligning alerts with typical activity can help reduce false positives.
Contact
If you suspect you are compromised or need assistance in assessing compromise, please call our Incident Response hotline. If you are from a Law Enforcement Agency or Endpoint Detection and Response vendor and wish for more details, please contact Stroz Friedberg Cyber Solutions.
1 https://cybercx.com/blog/akira-ransomware
