Can Ransomware Affect an ESXi host?
A particular Reddit thread caught my attention that was posted to Twitter as of last night. The title of the thread is “Witnessed my first ESXi ransomware. Crypts VMs at datastore level“. It basically describes a nightmare scenario involving a vSphere environment where an attacker got into an environment and performed the worst-case scenario attack – not only stealing credentials, but using those credentials to take over your vSphere environment.
While this isn’t a zero-day attack that is taking advantage of a vulnerability in ESXi or vCenter Server, it is a rude awakening for all vSphere admins out there to just how easy it is without the right safeguards in place and credential hygiene to have your vSphere environment totally owned by an attacker and have all VMs along with files on your datastore encrypted. This is a scary thought indeed.
If there is a positive aspect to these types of incidents, it is that it helps us to reevaluate our own environments and those of our customers to ensure security best practices are being followed. Additionally, it helps to think about basic things such as network segmentation and permission levels inside your vSphere environment. Let’s take a look at the topic/question, can ransomware affect an ESXi host? Also, what security practices can help prevent a ransomware attack that affects your vSphere environment?
ESXi Ransomware – Is it Real?
When we think about ransomware, we generally think about Windows client or Windows Server operating systems. However, we must consider all types of systems and infrastructure, including vSphere, when it comes to implementing good security practices in the environment.
Are we talking about some new ransomware strain that can automatically target and infect ESXi the same as a Windows client or Windows Server? No. There is no current vulnerability or known bug that would allow someone to simply start encrypting your datastores. VMware vSphere remains arguably the most secure hypervisor on the planet.
However, our sigh of relief probably needs to stop there. Can an attacker infect your ESXi environment and encrypt VM files on an ESXi datastore? Apparently so. What is needed for this to happen? Well, really two things:
- A high-level vSphere account
- Network connectivity to your vSphere management environment
Take a look at one of the comments in the Reddit thread from Significant_Parking, working incident response, who has mentioned seeing an uptick in these types of attacks in the past few months.
“I work in Incident Response and recovery and I have witnessed this more and more in the last 6 months. The way this works is, the attacker gets domain level rights, checks the network to see how much they can encrypt and also try the same domain admin creds in vCenter. If they can, the will enable SSH and will return later. They will then encrypt all virtual windows guest systems, shut them down, then move to VMware and encrypt the datastores effectively encrypting the environment twice. It isn’t fun, but our new recommendations are to have separate (non-domain) credentials for vCenter and Veeam (if applicable).”
If an attacker compromises a Windows machine in the LAN they will attempt to move laterally in the environment. What if they compromise a high-level Windows account? If your vCenter Server is on the same network as the compromised Windows machine, they will of course attempt to use the same credentials to login to vCenter. As we all know, most often, a domain admin may also have vSphere administrator access as well in many environments.
How can an attacker encrypt files on a datastore? With vSphere administrator access, a simple Python script can be used to run against the datastore, encrypting and renaming files.
So, there is really a lot of food for thought when thinking about this type of scenario which may become increasingly common as attackers will certainly target virtualized infrastructure in the environment if possible.
To think about vSphere security in the right way, you need to think about your environment like an attacker is already on the inside and has already compromised a high-level Windows account. When you design your vSphere security for that scenario you are much better off.
Let’s talk about some high-level best practices and design considerations that vSphere administrators need to think about.
Protect your vSphere environment from Ransomware
I would like to talk about a few concepts and ideas that are important thinking about an attacker on the inside who already has a high-level Windows account.
- Don’t use Active Directory accounts for vSphere administrator-level access
- Segment your vSphere management network from guest virtual machine networks
- Protect your backup servers, use local accounts
Let’s take a look at these points individually and see why these are important.
1. Don’t use Active Directory accounts for vSphere administrator-level access
Keep your vSphere administrator level accounts separate from Active Directory. You can have vCenter integrated with Active Directory authentication, however, users from Active Directory such as domain admins should not be assigned the Administrator vSphere role or a role that has the capability to interact with and administer vSphere storage.
Keep administrator permissions local to vSphere and apart from the Windows environment. The security benefit to this model is that even if a high-level account such as a domain administrator is compromised, this account does not have high-levels of vSphere access, particularly are not a vSphere administrator.
Don’t ever consider Windows accounts with vSphere administrator access unless you have effectively implemented two-factor authentication with vSphere. We will mention this below.
2. Segment your vSphere management network from guest virtual machine networks
Segmenting your vSphere management network from guest virtual machine networks goes a long way in helping to protect your vSphere environment from a security breach or all-out ransomware attack on your vSphere datastores. This goes back to simple network security 101.
It is not a good thing to have workloads running on the same subnet as the management of your vSphere environment. When you think about the possibility of an attacker who has infiltrated the network now being on the same network as your vSphere environment, the possibility is much, much greater that the vSphere environment can and will be attacked and/or compromised.
All too often in environments, large, flat networks are used for everything, including workloads and management. This is a recipe for security disaster. If the network isn’t segmented, you can use built-in VMware solutions to help restrict access. We will consider these below.
3. Protect your backup servers, use local accounts
Cybercriminals today have gotten much more clever in their efforts to lock up environments with ransomware. They know that if you have good backups of all your data that can easily be restored, they are much less likely to see payment of the ransom demand.
However, if they can also compromise your backup environment and backup data, they are much more likely to be successful in forcing the payment of the ransom.
If you are using a backup solution that is heavily based on Windows, such as Veeam Backup & Replication, consider dropping these boxes out of the domain. Veeam does not require you have your Veeam servers joined to the domain of the VMs that you will be backing up. This is also the case with most other backup solutions. Joining the domain and using domain credentials is generally done simply for ease of management by domain administrators who do not want to have to use different credentials to login.
Veeam allows passing domain credentials for backup jobs, even if the Veeam server itself is not joined to the domain. Having your Veeam servers as simple standalone boxes with local accounts using very strong passwords will go a long way in protecting your backups. When all else fails, you certainly want to be able to restore your data and not have your backups as part of the collateral damage of a ransomware attack.
VMware vSphere solutions you can leverage to bolster security
What are some VMware vSphere solutions that you can leverage to help bolster security for your vSphere environment? Let’s talk about just a few tools and solutions that are built into vSphere that can help improve the security of your environment. Some, you may have forgotten about.
Problem – vCenter and ESXi management interfaces are on the same ;network as workloads
- A simple but effective solution is to make use of the vCenter Server firewall as well as the ESXi local firewall to restrict access to vCenter as well as ESXi SSH and web interfaces. Restrict management access to only a handful of trusted management workstation IP addresses that also have two-factor authentication enabled for accessing them.
- Also worth mentioning, a new feature with vCenter Server 7.0, you can now effectively add multiple network adapters that, in conjunction with the vCenter firewall, can help to scope traffic flow and restrict access as needed from various networks
Problem – using Windows accounts in vSphere environment for management
- As mentioned, considering new and emerging threats to your environment, don’t integrate high-levels of access to vSphere from Active Directory unless you are using multi-factor authentication. New with vSphere 7.0 is Identity Federation that allows providing effective MFA access for vSphere.
Problem – Making sure your ESXi environment has not been tampered with
- New with vSphere 7.0 is the vSphere Trust Authority (vTA) which helps to ensure the integrity of your ESXi environment and that it has not been tampered with
Thoughts
Can Ransomware Affect an ESXi host? Not in the traditional sense, but with compromised credentials, yes. Reports of incidents involving ransomware and vSphere environments should serve as a wakeup call for all vSphere administrators to always have our security “hats” on. As soon as we cut corners or get lazy with administrator credential hygiene, an attacker can capitalize on these and totally own an environment. Generally speaking, a few simple changes in an environment can go a long way in making this scenario far less likely. Also, making use of built-in tools provided from VMware can greatly help.
Please let me know your thoughts in the comments. Hopefully this post will spur on greater community security awareness. Have you experienced a similar attack on vSphere before? What other recommendations would you make?
