Hi,

If they have regular backups hopefully from a trusted backup solution like Veeam, then they can just restore the VMs. They just need to delete the existing encrypted datastore and start restoring to a new datastore. The loss will be as per RPO.

There are various products/solution that protects VMware environment against ransonware 

There’s been speculation of ransomware on ESXi but it appeared to be nothing more than an unsecured host that was connected to and someone executing a payload.

Replicas and Backups are different and protect from different events. But in both scenarios, good security policies are an excellent line of defence.

Going back to your original point of connecting directly to the datastore, whilst I’m speculating here it’s likely it was an NFS datastore that wasn’t sufficiently secured to be accessed by specific devices only.

I do not know of any attack up to now - which does not mean, they do not exist - ransomware was able to use ESXi as an entry-point to encrypt datastores. As @MicoolPaul said, most likely it was a unsecured host.

But there is a interesting point in backup configuration, that could enable ransomware to destroy VMFS-datastores. When you enable (direct) SAN transport mode, your storage volumes are presented to your physical proxy as well. Here software would be able to initialize and format these volumes. This would cause all VM data to be destroyed. Luckily, ransomware does normally not want to kill your current data-set.

If datastore was encrypted, possibly SSH was enable on host. Just to remember, SSH never been enabled on host. You can enable it for some troubleshoot and disable it again after solve problem.

This would is probably the easiest way to destroy the VMFS datastores. In some environments where we use storage snapshots we don't publish the original datatores to the backup server and let only Veeam self-publish the storage snapshots during backup.

@nashr85
Veeam replication is only a part of the solution, it can offer additional protection but not 100% assurance. Even if ransomware wasn't able to encrypt VMs/datastores, there's always the possibility of an insider attack; either from an user/admin or a Hacker who was able to catch credentials. Such an attacker could always wipe your environment (backup, production data, SAN, tapes,...). This is why you need an offsite and offline backup; look at the following topic:

Hi All, thanks for respond

I already confirmed with IT from attacked by ransomware,

they use vmware version 5.5, SSH are disabled, and datastore was connected to host directly (SAN storage), and they inform us that there are a bug to vmware lower than version 7

i also attached an announcement from our governent organization about CVE-2020-3992, but sorry in Indonesian Language.

Thanks for sharing!

Here is the official VMware Security Advisory about this:

https://www.vmware.com/security/advisories/VMSA-2020-0023.html

Thanks for sharing @vNote42 so it sounds like it’s patched in all supported versions of VMware. And thanks @nashr85 for following up to give us all more information. Sounds like an urgent upgrade from VMware 5.5 is in order for you then...

This sounds quite serious, thanks for sharing @nashr85@vNote42

Looks like this attack was rather special and, as it happened from the inside, there was probably also another attack vector. However it's still a good example on why to stay current on updates (and Releases; 5.5 and 6.0 are EOL).

The problem is our hardware only compatible with VMware 6.0 that already EOS also 

Sorry to hear! Let’s be honest, you need a way forward from this and I won’t talk about trying to secure these old hypervisors as eventually you’ll hit an exploit that to block would break something fundamental. Best way forward is to move your infrastructure as you can’t rely on it anymore and you don’t want to be checking for ransomware and associated downtime daily!

Thankfully with Veeam you’ve got flexibility of platform. You could get new vSphere infra and replicate straight over to it, trusting nothing between old and new. If your hypervisor supports a still current version of Windows Server and you’ve got the skills you could look at Hyper-V. Alternatively you could look at using Veeam to restore your VMs into a public cloud such as AWS/Azure. Now you’ve just got to choose a path forwards

Is it not compatible or officially not compatible? I wouldn’t say that it’s a good idea to run vSphere on hardware which isn’t supported by the HCL, but security issues are probably as bad.

At all: Looks like we need to start patching again as there are some new (very) critical issues. The mentioned issue with OpenSLP  is also back again:

https://www.vmware.com/security/advisories/VMSA-2021-0002.html

This anwser was awesome!

Excelent logical reasoning @MicoolPaul.

It’s just a matter of time. Here is a new article describing ESXi attacks. https://www.crowdstrike.com/blog/carbon-spider-sprite-spider-target-esxi-servers-with-ransomware/