VMware ESXi Servers Encrypted by Lightning-Fast Python Script

Опубликовано: 14 Февраль 2026
на канале: CSI digital
394
9

VMware ESXi Servers Encrypted by Lightning-Fast Python Script

Original article: https://threatpost.com/vmware-esxi-en...


So what did we learn?
Again we see the dangers of remote control software like ssh, RDP and teamviewer among others. These services are NOT meant ot be on 24/7 or accessible by the entire world. We as IT professionals need ot implement better security for these services including a “mostly OFF” based usage principle. This is not that easy for cloud based systems but combining firewall lockdown IP rules along with creative solutions can ensure we have the best security possible.
In the coming weeks I will share a 100% proven method for securing these services so make sure you subscribe to my channel and smash the bell to be alerted when I upload new episodes. Specifically the “Securing remote control software” episode.

What else did we learn. Secure passwords . This hack, as reported, was enabled by one of the Admins NOT using Multi-form factoring Authentication. For critical services this is an absolute must. This story is a prime example that shows how imporant it is. With implementing just 2 security policies (Mosly off prinicple for remote control softwarte) and MFA this entire ransomware attack would not even be possible.






Researchers have discovered a new Python ransomware from an unnamed gang that’s striking ESXi servers and virtual machines (VMs) with what they called “sniper-like” speed.
Sophos said on Tuesday that the ransomware is being used to compromise and encrypt VMs hosted on an ESXi hypervisor in operations that, soup-to-nuts, are taking less than three hours to complete from initial breach to encryption.
“This is one of the fastest ransomware attacks Sophos has ever investigated, and it appeared to precision-target the ESXi platform,” Andrew Brandt, principal researcher at Sophos, was quoted as saying in a press release that accompanied his in-depth report.

Targeting ESXi Is a No-Brainer
While the choice of Python for the ransomware is fairly distinctive, going after ESXi servers is anything but. Attackers love VMware’s ESXi (formerly known as ESX), which is a bare-metal hypervisor that installs easily onto servers and partitions them into multiple VMs.
While that makes it easy for multiple VMs to share the same hard-drive storage, it sets systems up to be one-stop shopping spots for attacks, since attackers can encrypt the centralized virtual hard drives used to store data from across VMs. In other words, one hit locks up scads of VMs.
That’s how AT&T Cybersecurity’s Alien Labs explained it in July, shortly after the REvil ransomware threat actors came up with a Linux variant that likewise targeted VMware ESXi, as well as its network-attached storage (NAS) devices.
Later that month, HelloKitty joined the growing list of ransomware bigwigs going after the juicy target. DarkSide has also targeted ESXi servers: In June, AT&T Alien Labs analyzed the Linux version of the DarkSide ransomware, which it called one of the most active ransomwares in the previous quarter.
In short, everybody in ransomware-land craves ESXi pwnage: It’s like hitting the jackpot at the slots.


This Baby Python Has Sharp Fangs
Weighing in at 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,” Brandt wrote. 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.

It turned out that the attackers executed the script once for each ESXi datastore they wanted to encrypt. Each time it executed, the script generated a unique key pair to use in encrypting files. In the case that Sophos investigated, the attackers targeted three datastores, each time with individual executions of the script, “so the script created three unique key pairs, one for each datastore,” according to the writeup.
Those keys weren’t going anywhere, though, given that the script had no ability to transmit them anywhere. But the attackers obviously didn’t want to leave them sitting around where victims could use them to decrypt their locked files without paying a dime in ransom, so the script wrote out a copy of the secret key, then encrypts it, using the embedded, hardcoded public key.