The little snippet of Python code strikes fast and nasty, taking less than three hours to complete a ransomware attack from initial breach to encryption.
Not until now, the researchers knew that a python code could be used to execute a ransomware attack. The new script striking Esxi servers and virtual machines (VMs) with what they called “sniper-like” speed.
Sophos said on 6/10/21 that the ransomware is being used to compromise and encrypt VMs hosted on an ESXi hypervisor in operations that, soup – to – nuts, the code takes less than 3 hours to complete from initial breach to encryption.
Sophos investigators reported that it is one of the fastest cyberattacks they have ever seen. It seems to target the ESXi platform. It is extremely rare to see the python language used for ransomware. But its use make sense because ESXi is a Linux-based system, python is inbuilt to it and thus makes the python-based attacks possible.
Why attacking ESXi is not a big deal?
Targeting ESXi servers is fairly distinct, but the attackers love going after VMware’s ESXi (FOrmerly known as ESX), which is a bare-metal hypervisor that installs easily onto servers and partitions them into multiple VMs.
That makes it easy for multiple VMs to share the same hard-drive storage, this makes VMware a one-stop shopping store for attackers because attackers can encrypt the central virtual drives used to store data from across VMs.Just one hit can trap the entire VMs.
Before a few months back REvil ransomware threat actors came up with a Linux variant that likewise targeted VMware ESXi, as well as it’s network-attached storage(NAS) devices.
Hello Kitty the growing list of ransomware bigwigs going after the juicy target. Darkside has also targeted ESXi servers in June 2021, it was analyzed by AT&T Alien Labs analyzed the Linux version of the DarkSide ransomware, which is called one of the most active ransomware in the previous quarter.
As ESXi servers carry multiple VMs at once, where each of the VMs could be running business-critical applications or services. Attacks based on hypervisors can be both fast and highly disruptive.
The baby python has sharp fangs
Weighing only 6KB, It’s an itty-bitty thing that can do a whole lot of damage.
The script contains variables that the attacker can configure with multiple encryption keys, email addresses, and where they can customize the file suffix that gets appended to encrypted files. Specifically, the Python script embeds, as variables, the file suffix it appends to encrypted files (ext), and email addresses (mail, mail2) to be used to contact the attacker for payment of the ransom.
It also embeds the ransom note text shown below
When the Sophos investigators inspected the code it was noted that the code creates random encryption keys each time it is executed.
Normally, an attacker would only need to embed the ‘public key’ that the attacker generated on their own machine and would be used to encrypt files on the targeted computers. But this ransomware is totally different, it creates a unique key every time it is run.
It’s seen that the attackers executed the script once for each ESXi datastore they wanted to attack. Each time the code is executed, the script generated a unique key pair to use in encryption files. In the case that Sophos investigated, the attackers targeted three datastores, each time with individual execution of the script.
Why ESXi servers became the target?
Linux variants of malware that can be used to target systems such as ESXi are still “Relatively uncommon”. As a result, the endpoint protection on ESXi servers is lacking.
There are some security practices that can be used to harden the security
- Avoiding password reuse
- Using complex, difficult to brute-force passwords of adequate length
- Enabling the use of MFA wherever possible, and enforcing it for accounts with high permissions,such as those of domain administrators.
- Shutting off shell when it’s not in use.
One of the main reasons for such attacks is that the administrator forgets to toggle off the ESXi Shell. The administrator should only allow the shell to be active during use by staff and should disable it as soon as the maintenance is complete.