Ransomware targeting VMware hosts is rapidly on the rise, and Black Basta is one of the latest jumping on the bandwagon.
Like most ransomware, this relative newcomer first targeted Windows systems, but the Uptycs Threat Research team recently discovered a fresh Linux variant a few months later, developed by the same authors, which specifically targets VMware ESXi servers.
As I mentioned in my previous article on Cheerscrypt, Linux ransomware is on the rise and ESXi servers are a particularly hot target, given their popularity within many enterprise organizations. Virtual machine (VM) ransomware requires less effort to spread because it targets the host server, and a compromised host means many simultaneously compromised guest VMs. The attack need only encrypt the host’s drive to encrypt the files of all VMs sharing it.
Upon execution, Black Basta searches the host’s /vmfs/volumes directory for any contents, which, as the subdirectory name implies, contains the volumes of the various guest VMs configured on the server.
To ensure it will have full, unrestricted access to all files, Black Basta executes Linux’s command line chmod tool to grant itself full (i.e., read/write/execute) permissions to its targets, as indicated by the following line (trimmed for the purpose of this example) embedded within one of its if logic loops:
write( 10</vmfs/volumes/ff.doc>, // multiple lines of encryption data follow
Now wielding unrestricted access, it next employs the relatively swift ChaCha20 algorithm to encrypt any unfortunate victims found in this directory. Worse yet, the attack’s function EncryptionThread runs multithreaded (executing across multiple cores), further speeding encryption and making the attack more difficult to detect. It can be found within the malware’s code as follows:
puVar8 = EncryptionThread;
Finally, it appends the extension .basta to all encrypted files inside /vmfs/volumes and creates a .txt format ransom note within the same subdirectory.
The ransom note includes a link to the attacker’s chat support panel (see Figure 1), which is the tell-tale sign the original authors are behind the new attack.
As I’ve written about previously, Linux ransomware often takes its threat a step further than its Windows cousins via double extortion. The attacker threatens the victim with the assurance that if the ransom isn’t paid within the timeline demanded, they will not only hold on to the decryption key (rendering the victim’s files encrypted forever), but they will leak the victim’s data across the dark web as well (see Figure 2).
Second, Black Basta will call out to the following .onion address:
If the attack has slipped past your defenses, a solid disaster recovery strategy is key to any incident response plan. Unfortunately, most organizations rely on a single backup repository for all ESXi guest images. Though it’s a great convenience for VMware admins, if ransomware sabotages the repository, all guest image backups are lost at once.
This is why you need a Ransomware Backup Strategy built on redundancy, ideally adhering to the 3-2-1 backup method. Ransomware.org has a page on disaster recovery that discusses the particulars about ESXi servers. You should also have a solid passive defense strategy and be aware of all the current ransomware prevention tools. In addition, consider downloading our How to Prevent Ransomware cheat sheet. For a deeper dive, read the book "Ransomware: Understand. Prevent. Recover."