VMWare user? Worried about “ESXi ransomware”? Check your patches now!

Cybersecurity news, in Europe at least, is currently dominated by stories about “VMWare ESXi ransomware” that is doing the rounds, literally and (in a cryptographic sense at least) figuratively.

CERT-FR, the French government’s computer emergency response team, kicked off what quickly turned into a mini-panic at the tail end of last week, with a bulletin entitled simply: Campagne d’exploitation d’une vulnérabilité affectant VMware ESXi (Cyberattack exploiting a VMWare ESXi vulnerability).

Although the headline focuses directly on the high-level danger, namely that any remotely exploitable vulnerability typically gives attackers a path into your network to do something, or perhaps even anything, that they like…

…the first line of the report gives the glum news that the something the crooks are doing in this case is what the French call rançongiciel.

You probably don’t need to know that logiciel is the French word for “software” to guess that the word stem ranço- came into both modern French (rançon) and English (ransom) from the Old French word ransoun, and thus that the word translates directly into English as ransomware.

Back in the Middle Ages, one occupational hazard for monarchs in time of war was getting captured by the enemy and held for a ransoun, typically under punitive terms that effectively settled the conflict in favour of the captors.

These days, of course, it’s your data that gets “captured” – though, perversely, the crooks don’t actually need to go to the trouble of carrying it off and holding it in a secure prison on their side of the border while they blackmail you.

They can simply encrypt it “at rest”, and offer to give you the decrpytion key in return for their punitive ransoun.

Ironically, you end up acting as your own jailer, with the crooks needing to hold onto just a few secret bytes (32 bytes, in this case) to keep your data locked up in your very own IT estate for as long as they like.

Good news and bad news

Here’s the good news: the current burst of attacks seem to be the work of a boutique gang of cybercriminals who are relying on two specific VMWare ESXi vulnerabilities that were documented by VMware and patched about two years ago.

In other words, most sysadmins would expect to have been ahead of these attackers since early 2021 at the latest, so this is very definitely not a zero-day situation.

Here’s the bad news: if you haven’t applied the needed patches in the extended time since they came out, you’re not only at risk of this specific ransomware attack, but also at risk of cybercrimes of almost any sort – data stealing, cryptomining, keylogging, database poisoning, point-of-sale malware and spam-sending spring immediately to mind.

Here’s some more bad news: the ransomware used in this attack, which you’ll see referred to variously as ESXi ransomware and ESXiArgs ransomware, seems to be a general-purpose pair of malware files, one being a shell script, and the other a Linux program (also known as a binary or executable file).

In other words, although you absolutely need to patch against these old-school VMWare bugs if you haven’t already, there’s nothing about this malware that inextricably locks it to attacking only via VMWare vulnerabilities, or to attacking only VMWare-related data files.

In fact, we’ll just refer to the ransomware by the name Args in this article, to avoid giving the impression that it is either specifically caused by, or can only be used against, VMWare ESXi systems and files.

How it works

According to CERT-FR. the two vulnerabilities that you need to look out for right away are:

• CVE-2021-21974 from VMSA-2021-0002. ESXi OpenSLP heap-overflow vulnerability. A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger [a] heap-overflow issue in [the] OpenSLP service resulting in remote code execution.
• CVE-2020-3992 from VMSA-2020-0023. ESXi OpenSLP remote code execution vulnerability. A malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution.

In both cases, VMWare’s official advice was to patch if possible, or, if you needed to put off patching for a while, to disable the affected SLP (service location protocol) service.

VMWare has a page with long-standing guidance for working around SLP security problems, including script code for turning SLP off temporarily, and back on again once you’re patched.

The damage in this attack

In this Args attack, the warhead that the crooks are apparently unleashing, once they’ve got access to your ESXi ecosystem, includes the sequence of commands below.

We’ve picked the critical ones to keep this description short:

• Kill off running virtual machines. The crooks don’t do this gracefully, but by simply sending every vmx process a SIGKILL (kill -9) to crash the program as soon as possible. We assume this is a quick-and-dirty way of ensuring all the VMWare files they want to scramble are unlocked and can therefore be re-opened in read/write mode.
• Export an ESXi filesystem volume list. The crooks use the esxcli storage filesystem list command to get a list of ESXi volumes to go after.
• Find important VMWare files for each volume. The crooks use the find command on each volume in your /vmfs/volumes/ directory to locate files from this list of extensions: .vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram and .vmem.
• Call a general-purpose file scrambling tool for each file found. A program called encrypt, uploaded by the crooks, is used to scramble each file individually in a separate process. The encryptions therefore happen in parallel, in the background, instead of the script waiting for each file to be scrambled in turn.

Once the background encryption tasks have kicked off, the the malware script changes some system files to make sure you know what to do next.

We don’t have our own copies of any actual ransom notes that the Args crooks have used, but we can tell you where to look for them if you haven’t seen them yourself, because the script:

• Replaces your /etc/motd file with a ransom note. The name motd is short for message of the day, and your original version is moved to /etc/motd1, so you could use the presence of a file with that name as a crude indicator of compromise (IoC).
• Replaces any index.html files in the /usr/lib/vmware tree with a ransom note. Again, the original files are renamed, this time to index1.html. Files called index.html are the home pages for any VMWare web portals you might openm in your browser.

From what we’ve heard, the ransoms demanded are in Bitcoin, but vary both in the exact amount and the wallet ID they’re to be paid into, perhaps to avoid creating obvious payment patterns in the BTC blockchain.

However, it seems that the blackmail payment is typically set at about BTC 2, currently just under US$50,000.

LEARN MORE: PAYMENT PATTERNS IN THE BLOCKCHAIN

The encryptor in brief

The encrypt program is, effectively, a standalone, one-file-at-a-time scrambling tool.

Given how it works, however, there is no conceivable legitimate purpose for this file.

Presumably to save time while encrypting, given that virtual machine images are typically many gigabytes, or even terabytes, in size, the program can be given parameters that tell it to scramble some chunks of the file, while leaving the rest alone.

Loosely speaking, the Args malware does its dirty work with a function called encrypt_simple() (in fact, it’s not simple at all, because it encrypts in a complicated way that no genuine security program would ever use), which goes something like this.

The values of FILENAME, PEMFILE, M and N below can be specified at runtime on the command line.

Note that the malware contains its own implementation of the Sosemanuk cipher algorithm, though it relies on OpenSSL for the random numbers it uses, and for the RSA public-key processing it does:

1. Generate PUBKEY, an RSA public key, by reading in PEMFILE.
2. Generate RNDKEY, a random, 32-byte symmetric encryption key.
3. Go to the beginning of FILENAME
4. Read in M megabytes from FILENAME.
5. Scramble that data using the Sosemanuk stream cipher with RNDKEY.
6. Overwrite those same M megabytes in the file with the encrypted data.
7. Jump forwards N megabytes in the file.
8. GOTO 4 if there is any data left to sramble.
9. Jump to the end of FILENAME.
10. Use RSA public key encyption to scramble RNDKEY, using PUBKEY.
11. Append the scrambled decryption key to FILENAME.

In the script file we looked at, where the attackers invoke the encrypt program, they seem to have chosen M to be 1MByte, and N to be 99Mbytes, so that they only actually scramble 1% of any files larger than 100MBytes.

This means they get to inflict their damage quickly, but almost certainly leave your VMs unusable, and very likely unrecoverable.

Overwriting the first 1MByte typically makes an image unbootable, which is bad enough, and scrambling 1% of the rest of the image, with the damage distributed throughout the file, represents a huge amount of corruption.

That degree of corruption might leave some original data that you could extract from the ruins of the file, but probably not much, so we don’t advise relying on the fact that 99% of the file is “still OK” as any sort of precaution, because any data you recover this way should be considered good luck, and not good planning.

If the crooks keep the private-key counterpart to the public key in their PEMFILE secret, there’s little chance that you could ever decrypt RNDKEY, which means you can’t recover the scrambled parts of the file yourself.

Thus the ransomware demand.

What to do?

Very simply:

• Check you have the needed patches. Even if you “know” you applied them right back when they first came out, check again to make sure. You often only need to leave one hole to give attackers a beachhead to get in.
• Revisit your backup processes. Make sure that you have a reliable and effective way to recover lost data in a reasonable time if disaster should strike, whether from ransomware or not. Don’t wait until after a ransomware attack to discover that you are stuck with the dilemma of paying up anyway because you haven’t practised restoring and can’t do it efficiently enough.
• If you aren’t sure or don’t have time, ask for help. Companies such as Sophos provide both XDR (extended detection and response) and MDR (managed detection and response) that can help you go beyond simply waiting for signs of trouble to pop up on your dashboard. It’s not a copout to ask for help from someone else, especially if the alternative is simply never having time to catch up on your own.