Preventing Hyperjacking in a Virtual Environment

Originally published by Entrust.

Written by Iain Beveridge and Dave Stevens, Entrust.

In the rapidly evolving world of information security, attack vectors, and cyberattacks, there is a regular cadence of new industry terms to grapple with. Hyperjacking is a term you may not have come across. It is a blend of hypervisor and hijacking. Hijacking is self-explanatory. A hypervisor is software installed on a physical host server that can virtually share its memory and processing resources for use by multiple virtual machines, as shown in Figure 1.

Figure 1: Hypervisor-based virtualization

Hyperjacking involves an attacker taking control of the hypervisor, thereby taking command and control of the virtual machines, as depicted in Figure 2. For many years this type of attack wasn’t on the radar of hackers – perhaps there was easier money to be made through more traditional malware methods? However, recently a hyperjacking attack has been identified by threat intelligence vendor Mandiant. The attack targets VMware’s ESXi hypervisor, Virtual Center appliance, and Windows virtual machines. As reported by Mandiant, the threat actor was able to take the following actions:

• Maintain persistent administrative access to the hypervisor
• Send commands to the hypervisor that can be routed to the guest VM for execution
• Transfer files between the ESXi hypervisor and guest machines running on it
• Tamper with logging services on the hypervisor
• Execute arbitrary commands from one guest VM to another guest VM running on the same hypervisor

Mandiant shared their findings with VMware, who reported, “…a new variant of malware targeting vSphere was discovered in an environment where threat actors may have used operational security weaknesses to compromise a mutual customer.” Further, “Mandiant found no evidence that a vulnerability in a VMware product was exploited to gain access to ESXi during their investigations.”

Authentication and Authorization

The statement, “threat actors may have used operational security weaknesses to compromise a mutual customer,” can likely be interpreted as the attacker acquired administrator-level privileges to the ESXi hypervisor to allow them to deploy the malware payload. This attack most likely could have been prevented by applying basic defense-in-depth security principles and adopting a least privilege model. Many organizations often overlook establishing the proper access controls when deploying their virtual infrastructure. System admins often have unfettered root access to large virtual machine estates, which can leave an organization wide open to this type of attack from external actors and malicious insiders.

As part of a least-privilege model, a strong password policy and the use of multi-factor authentication can help mitigate against these attacks. Entrust identity and access management solutions can be implemented to stop attackers in their tracks. Protecting the identities of workers, consumers, and citizens is key to preventing uncontrolled access, data breaches, and fraudulent transactions.

Figure 2: Malware payload being deployed by hacker or rogue insider

Role-Based Access Controls

Continuing with the least-privilege model, a well-defined role-based access control policy should be implemented prior to deployment to protect against the threat Mandiant has detailed in their report. By defining detailed, granular role-based access controls, the principle of least privileged access is exercised to limit the ability of those who can perform specific, sometimes sensitive operations. These roles allow you to determine who can access what in the virtual environment.

Configuration Hardening

Mandiant mentioned that a malicious vSphere Installation Bundle (VIB) was installed into the affected environment. A VIB can be considered a bundle of files packaged up for easy distribution and deployment to an ESXi host. A VMware trusted authority must sign all VMware and partner supported VIBs, which helps ensure the VIB’s security by preventing any unauthorized tampering of its contents. However, it is possible to remove the signing requirement. This is referred to as a community-supported VIB.

Secondary Approval

Secondary approval is another approach, which enforces additional approval before users can perform sensitive, disruptive operations on a resource. Refer to Figure 3. For example, you can require secondary approval before deleting or powering off a virtual machine, editing a firewall, or creating an edge gateway service. Additionally, users cannot approve their own requests, even if they are in the approval group. A different user must authorize the request mitigating against rogue administrators who want to bring down a VM estate.

Secondary approval can be used to prevent a user from maliciously or accidentally changing the VIB acceptance level on one or more ESXi hosts. This could have prevented the attacker from changing the VIB acceptance level to customer-supported from partner-supported.

Figure 3: Least privilege, second approval, and role-based access control

Host Attestation

Lastly, host attestation is another tool in the defense-in-depth security “toolbelt,” which a virtual administrator can use to help thwart a threat actor in this scenario. Host attestation ensures that during the host boot cycle, a “fingerprint,” or a set of unique host measurements, can be utilized to determine the host’s trust status.

Summary

Hopefully you’ll now be familiar with the term hyperjacking. The report and findings from Mandiant and the response from VMware illustrate that the malevolent hacking community continue to seek sophisticated ways to infiltrate an organization’s IT infrastructure and the VM space is not immune to these attacks. Fortunately, this hyperjacking attack vector can be easily remedied by adopting robust defense-in-depth measures, applying diligence when establishing access controls and least privileged roles in an organization.