Skip to content
Researchers have discovered a new Python ransomware from an unnamed gang that is striking ESXi servers & virtual machines (VMs) with what they called “sniper-like” speed.
The little snippet of Python code strikes fast & nasty, taking less than 3 hours to complete a ransomware attack from initial breach to encryption.
Sophos said on Tues. that the ransomware is being used to compromise & encrypt VMs hosted on an ESXi hypervisor in operations that, soup-to-nuts, are taking less than 3 hours to complete from initial breach to encryption.
Precision-Target
“This is one of the fastest ransomware attacks Sophos has ever investigated, & 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.
Brandt noted that it is rare to see the Python coding language used for ransomware. But its use makes sense, he explained, given that Python comes pre-installed on Linux-based systems such as ESXi, & thus makes Python-based attacks possible on these systems.
Targeting ESXi
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 & 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 1-stop shopping spots for attacks, since attackers can encrypt the centralised virtual hard drives used to store data from across VMs. In other words, one hit locks up scads of VMs.
Linux Variant
That’s how AT&T Cybersecurity’s Alien Labs explained it in July, shortly after the REvil ransomware threat players 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 ‘biggies’ going after the target. DarkSide has also targeted ESXi servers: In June, AT&T Alien Labs analysed the Linux version of the DarkSide ransomware, which it called 1 of the most active ransomwares in the previous quarter.
Attractive Target
Everybody in ransomware-land craves ESXi pwnage: It is like hitting the jackpot!
“ESXi servers represent an attractive target for ransomware threat actors because they can attack multiple VMs at once, where each of the VMs could be running business-critical applications or services,” Brandt explained.
“Attacks on hypervisors can be both fast & highly disruptive.”
Attack Timeline
Sophos was investigating a ransomware attack when it came across the new, extremely fast Python script. The attack started in the wee hours – 12:30 a.m. – on a Sun. morning, when the ransomware operators broke into a TeamViewer account belonging to a user who had admin access but who did not have multi-factor authentication (MFA) enabled. Here is a timeline of what followed:
12:40 a.m.
10 minutes in, the attackers were looking for network targets, using the Advanced IP Scanner tool for reconnaissance. Sophos’s investigators believe that the network’s ESXi server was vulnerable because it had an active shell that an IT team was using for commands & updates.
According to Sophos’ report, ESXi servers have a built-in SSH service called the ESXi Shell that administrators can enable, but which is typically disabled by default.
Failed to Disable
“This organisation’s IT staff was accustomed to using the ESXi Shell to manage the server & had enabled & disabled the shell multiple times in the month prior to the attack,” according to Brandt’s report.
“However, the last time they enabled the shell, they failed to disable it afterwards. The criminals took advantage of this fortuitous situation when they found the shell was active.”
2:00 a.m.
The attackers downloaded an SSH client called Bitvise & used it to log into a VMware ESXi server they identified using Advanced IP Scanner.
3:30 a.m.
3 hours after the attackers scanned the network, they used the pilfered admin credentials to log into the ESXi Shell. Then they copied a file named “fcker.py” to the ESXi datastore, which houses the virtual disk images used by the VMs that run on the hypervisor, Brandt explained.
The Python script uses the vim-cmd command functions of the ESXi Shell to produce a list of the names of all VMs installed on the server, then shuts them all down, he stated. Only after the VMs are all powered off will the script begin encrypting the datastore volumes.
VM Settings Files
Then, the Python script ‘slithers’ through, picking off VMs one after another, Brandt recounted: “one by one, the attackers executed the Python script, passing the path to datastore disk volumes as an argument to the script. Each individual volume contained the virtual disk and VM settings files for multiple virtual machines.”
The ransomware snippet uses just a single instruction for each file it encrypts, invoking the open-source tool OpenSSL to encrypt the files with this command:
openssl rsautil -encrypt -inkey pubkey.txt -pubin -out [filename].txt
Python Script
Sophos investigators managed to find a copy of the Python script, despite the attackers having apparently overwritten it with other data before deleting the file. The “other data” meaning, specifically, the curse word “fxxx.”
“Finally, it deletes the files that contain the directory listings, the names of the VMs & itself by overwriting those files before deleting them,” Brandt wrote.
Sharp Fangs
Weighing in at only 6KB, it is a ‘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, & where they can customise 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), & email addresses (mail, mail2) to be used to contact the attacker for payment of the ransom.
Encryption Keys-R-Us
Whilst checking the code, Sophos investigators noted multiple, hardcoded encryption keys, as well as a routine for generating even more encryption key pairs. They found that odd, Brandt stated.
“Normally, an attacker would only need to embed the ‘public key’ that the attacker generated on their own machine & would be used to encrypt files on the targeted computers,” he noted. “But this ransomware appears to create a unique key every time it is run.”
Unique Key Pair
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 3 unique key pairs, 1 for each datastore,” according to the writeup.
Those keys were not going anywhere, though, given that the script had no ability to transmit them anywhere.
But the attackers obviously did not want to leave them where victims could use them to decrypt their locked files without paying anything in ransom, so the script wrote out a copy of the secret key, then encrypts it, using the embedded, hardcoded public key.
Lists all the Files
“The script runs a routine that lists all the files in the path that’s provided to the script during execution,” the report continued.
“For each file, the script generates a unique, 32-byte random code it calls the aeskey, & then encrypts the file using the aeskey as a salt into the /tmp path.
Finally, it prepends the aeskey value to the encrypted file & appends a new file suffix to the name, overwrites the contents of the original file with the word fxxx, then deletes the original file, & moves the encrypted version from /tmp to the datastore location where the original file was stored.”
Endpoint Protection Lacking
While Linux variants of malware that can be used to target systems such as ESXi are still “relatively uncommon,” endpoint protection on these kinds of servers is even rarer, Brandt stated.
He passed on advice for hardening ESXi or other hypervisors, including standard security best practices such as:
- Avoiding password reuse
- Using complex, difficult to brute-force passwords of adequate length.
- Enabling the use of MFA wherever possible, & enforcing it for accounts with high permissions, such as those of domain administrators.
- Shutting off Shell when it is not in use.
List of Best Practices
“In the case of ESXi, use of the ESXi Shell is something that can be toggled on or off from either a physical console at the machine itself, or through the normal management tools provided by VMware,” Brandt advised.
“Administrators should only allow the Shell to be active during use by staff & should disable it as soon as maintenance (such as the installation of patches) is complete.”
VMware has also published a list of best practices for administrators of their ESXi hypervisors on how to secure them & limit the attack surface on the hypervisor itself.
