Solved

ransomware attack datastore


Userlevel 2

Hi, 

greeting from newbie

 

last month, our neighboring company was attacked by ransomware,

it become worst because their datastore is encrypted too, they still use vmware 5.5

 

from investigation, they analyze that one server made network drives directly to the datastore,

that's why ransomware is able to attack and encrypted the datastore.

 

i want to know if it is possible to create a network drive directly?

 

if attack the datastore is possible, I think veeam replicated server will be useless.

icon

Best answer by MicoolPaul 18 February 2021, 08:08

View original

14 comments

Userlevel 6
Badge +1

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 

Userlevel 7
Badge +20

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.

Userlevel 7
Badge +13

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.

Userlevel 7
Badge +11

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.

Userlevel 7
Badge +13

 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.

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:

 

Userlevel 2

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.

Userlevel 7
Badge +13

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

Userlevel 7
Badge +20

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...

Userlevel 7
Badge +13

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).

Userlevel 2

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...

 

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

Userlevel 7
Badge +20

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...

 

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

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 😊

Userlevel 7
Badge +13

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...

 

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


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

Userlevel 7
Badge +11

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...

 

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

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 😊

This anwser was awesome!

Excelent logical reasoning @MicoolPaul.

Userlevel 4
Badge

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.

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/

Comment