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.

Can Ransomware Affect an ESXi host

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.

  1. Don’t use Active Directory accounts for vSphere administrator-level access
  2. Segment your vSphere management network from guest virtual machine networks
  3. 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.
Using the vCenter Server firewall to block traffic from hosts and networks
  • 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.
If integrating with Active Directory use vSphere identity federation

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
Using vSphere Trust Authority to ensure ESXi integrity


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?

Subscribe to VirtualizationHowto via Email 🔔

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Brandon Lee

Brandon Lee is the Senior Writer, Engineer and owner at and has over two decades of experience in Information Technology. Having worked for numerous Fortune 500 companies as well as in various industries, Brandon has extensive experience in various IT segments and is a strong advocate for open source technologies. Brandon holds many industry certifications, loves the outdoors and spending time with family.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.