Hyper-V’s Guest/Host Attack Surface: A Quick Look

Shielded VMs, Guarded Fabric, and Host Guardian Services

In order to try and address the threat scenario where the host is malicious or the host’s admin has been compromised, Microsoft invented an optional flow to isolate VMs from their hosts. VMs are “shielded” when they run on “guarded fabric” by means of a “host guardian service”. Shielded VMs are VMs that are encrypted at-rest and are decrypted via calling a service called the Host Guardian Service (HGS). This service can (and should) exist separately from the VM host (the “fabric”), and details of communications between the HGS and the shielded VM can’t be observed by the host (due to asymmetric encryption). Since the guest is encrypted and the host doesn’t have the decryption key, an evil admin can’t meaningfully tamper with the data or machine state. Incidentally, shielded VMs also automatically do not run various helper services such as PowerShell Direct, which adds even better hardening.

Security Concerns

Built-in Hyper-V Services

Hyper-V guests have several pre-installed services that sit waiting for an external trigger and then start up. We will only focus on one, PowerShell Direct. Note that there are some interesting threats in that if you can convince a real bare-metal install that it’s a VM, it will helpfully start up a service that allows you to PowerShell into it via VMBus. The services appear to have registered in a common DLL “icsvc.dll”.

PowerShell Direct: Host-to-Guest Attack

PowerShell allows remote users to connect and open interactive shells, called PowerShell Remoting. There are restrictions on this service, such as requiring administrative access on the target and permitting a custom ACL; the service can even be disabled organization wide. PowerShell Directis pretty much the same idea (and has similar commands) but without the overhead of firewalls, functioning NICs, or even admin privileges on the target guest machine . If an attacker compromises a Hyper-V Administrative account and has valid credentials (e.g. any domain user), they are free to pass that along to allVMs and pop PowerShells on all them. This works regardless of the firewall configuration or valid IP address. The user only needs to be a member of the Hyper-V Administrator group on the host machine.

PowerShell Direct: Malicious Guest Attack

The service runs as LocalSystem and listens on a Hyper-V Socket for a connection. New connections receive plaintext domain+user+password information and verify it using a normal SSP (SSPLogonUser probably). If the credentials are valid, a new token is created for that user and “powershell.exe” is executed with this token (CreateProcessAsUserW). There are several issues here: running as LocalSystem is obviously not ideal, but also the connection doesn’t support any sort of safer credential exchange such as challenge/response or Kerberos. Windows appears to perform basic signature checking, since the relevant DLL is cryptographically signed by a Microsoft catalog entry but may still be bypassable (e.g. Windows only checks that the service is some valid signed file, not that it is the expected DLL in particular). In this case, a malicious local administrator on the guest can replace the DLL with a service that will log all incoming PowerShell Direct credentials for later use.