Ransomware as a Service – Nevada Ransomware campaign targeting VMWare ESXi servers

Security Advisory Leave a comment

Written by Michal Nowakowski of the Kudelski Security Threat Detection & Research Team

UPDATE – February 14th 2023

After the first wave of ESXiArgs ransomware campaign took place on February 3rd, two main elements of the ransom have been addressed by the security community in different publications. These are malware’s initial access vector and the malware’s variations.

First publications were highlighting the exploitation of CVE-2021-21974, a heap-overflow vulnerability in ESXi’s OpenSLP service, as the malware’s initial access vector. Nevertheless, the latest reports are mentioning that not every compromised server was running the service. Therefore, it is likely that the attackers behind these campaigns may be using several known ESXi’s vulnerabilities, investigations are still on-going. And as a countermeasure to this ongoing situation, it is important to ensure that ESXi servers are up to date with VMWare’s provided patches for already know vulnerabilities. This information can be found in WMWare’s Security Advisories section: https://www.vmware.com/security/advisories/VMSA-2021-0002.html.

Compared with the first observed cases of ESXiArgs where data was sometimes recoverable, the new variant is encrypting a larger amount of data, making the recovering process advised by organizations such as CISA more challenging. An additional change is that the bitcoin wallet is not trackable anymore as the information was removed from the ransom request.

Summary

As of Friday February 3rd, 2023, VMware ESXi servers exposed to the Internet have become targets of the widespread Nevada ransomware campaign.

Nevada is a new and growing Ransomware-as-a-Service (RaaS) with an established affiliate network that invites both Russian and English-speaking entities.

Most likely, an OpenSLP vulnerability known as CVE-2021-21974 is used to perform the attack. Once the system is infected, the files are encrypted and the “.NEVADA” extension is added to their names. Additionally, a “readme.txt” ransom note is left in every directory containing encrypted files.

The ransom note explains that the attacker has stolen and encrypted the victim’s files and gives them two options: pay the ransom to maintain privacy, or risk losing precious time waiting for a miracle. The memo threatens publication of victim data on Tor if the victim does not contact the attacker within three days.

In addition, the note warns against attempting to recover files from backups as this does not mitigate the threat of publication and instructs victims not to delete or rename encrypted files or use public decryption tools, as they may contain viruses. Instead, victims are instructed to install Tor Browser and follow the provided link to reach the attackers.

The Nevada locker is written in Rust and nearly 3,000 exposed ESXi servers have already been encrypted, according to a list of Bitcoin addresses compiled by CISA advisors.

Affected Systems and/or Applications

Nevada currently targets ESXi Hypervisors from version 6.x to version 6.7. However, according to the fact that CVE-2021-21974 is used to perform the attack, the following systems may be affected as well:

  1. ESXi versions 7.x prior to ESXi70U1c-17325551
  2. ESXi versions 6.7.x prior to ESXi670-202102401-SG
  3. ESXi versions 6.5.x prior to ESXi650-202102101-SG

Please find additional and updated information on VMware’s site: https://www.vmware.com/security/advisories/VMSA-2021-0002.html

Technical Details / Attack Overview

Technical analysis of Nevada is ongoing. So far, the following characteristics can be confirmed:

  • An OpenSLP vulnerability (port 427) known as CVE-2021-21974 was used as the attack vector.
  • Encryption uses the public key implemented by the malware in /tmp/public.pem
  • The encryption process specifically affects virtual machine files of the following extensions (.vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, *.vmem)
  • The malware creates an argsfile to store the arguments passed to the encrypted binary file (number of MBs to be skipped, number of MBs in the encryption block, file size)

In addition to this, the following functions were noted in the RaaS partner portal. The locker is run through the console with the appropriate flags, the functions of which are described below:

  • Windows Version
    • file – encrypt selected file
    • rez – encrypt selected directory
    • sd – delete on its own after everything is finished
    • sc – delete background copies
    • left – load hidden disks
    • nd – find and encrypt network shares
    • sm – encrypt in safe mode
  • Linux Version
    • help – helpdaemon – creation and launch of a service “nevada”file – encrypt particular filedir – encrypt particular folder
    • esxi – disable all virtual machines

If the encryption program is run with the “-nd” flag, then it will start collecting information about network shares using the “MPR.dll” file. A recursive algorithm is implemented in the code to collect this information. Then the information about the shared directories will be stored in a queue for further encryption.

Below are the modules loaded by the encryption program:

In addition, the encryption program can display all disks, including hidden ones, if it is run with the “-lhd” argument, assigns them a corresponding letter and then the file information on any hidden disk will be written to the queue for further encryption.

If, on the other hand, the encryption program is run with the “-sm” argument, then the Windows system will be restarted and will boot into emergency mode with network functions. Directories are encrypted with “-dir” argument.

What we also know is that the ransomware is using encryption algorithm known as “Salsa20” with the constant variable “expand 32-byte k”. That is, like Petya Ransomware, it is a stream cipher, which additionally prevents access to the attacked drive.

Nevada encrypts files with “stripes” – which, combined with Salsa20, is an advantage that increases the speed of encryption. Files smaller than 524288 bytes (512KB) – will be fully encrypted, which seems to be the exception. 

Interestingly, the Linux version of the Nevada locker does not encrypt files between 512KB and 1.25MB, possibly due to a bug. These files remain the same, but with an added extension .NEVADA and an additional 38 bytes at the end of the file, which may make recovery of these files possible.

At the end of the binary file, a public key and “Nevada” signature will be added.

Solution

Apply VMWare ESXi provided updates:

Since the CVE-2021-21974 vulnerability is not new, VMware recommends applying provided updates:

Block OpenSLP port 427 on internet-exposed ESXi Servers:

The CFC recommends blocking OpenSLP port 427 on ESXi servers accessible from the internet. In a situation where port 427 absolutely must be open, restrict access to trusted points of origin.

https://kb.vmware.com/s/article/76372

General Ransomware Recommendations:

  1. Back your data up and store it in a place inaccessible to ransomware actors.
  2. Review and harden any security policy applicable to any internet-exposed asset.
  3. Re-evaluate whether an asset in question must absolutely be accessible from the internet.
  4. Apply proper monitoring for your most critical assets.
  5. Apply the principle of least privilege: minimize users with unnecessary permissions.

Temporary Workarounds and Mitigations

Since research is ongoing and some attack vectors still need to be confirmed, it may be the case that undiscovered vulnerabilities play a role in this attack. The CFC is monitoring the situation and will update this document as events warrant.

Recovery

The U.S. Cyber Security and Infrastructure Agency (CISA) has released a script called ESXiArgs-Recover, used to recover VMware ESXi servers encrypted by the type of ransomware attack described above.

Although the script should not cause any problems, it is recommended to create backups before running the script of the recovery attempt.

The whole procedure is described in the following link: https://github.com/cisagov/ESXiArgs-Recover

Detection Guidance

Identify Vulnerable ESXi Servers

To find an ESXi server’s version, please refer to your vCenter server or VMWare partner interface. 

Enable Endpoint Threat Detection and Response

As described above, ransomware techniques are not novel in nature and have an increased possibility of detection by EDR technologies. If EDR is disabled or not present on ESXi servers and/or their guest VMs, enable or install it.

Indicators of Compromise (IOCs)

URL (Tor/onion): 

  • nevcorps5cvivjf6i2gm4uia7cxng5ploqny2rgrinctazjlnqr2yiyd[.]onion/{victim ID} 

MD5: 

  • 99549bcea63af5f81b01decf427519af (Windows) 
  • fb5dcf0b880b57b10a2093f164f2ed27 (Windows) 
  • 709ba88e758454f097959c3e62997000 (Windows) 
  • f1f569c6e4f961007f7411fca131bbe0 (Linux) 
  • 1396ab93e9104faaf138ac64211471ba (Linux)

What the Cyber Fusion Center is Doing

The CFC is preparing a threat hunt campaign which will include the regularly updated IOCs linked to the exploitation of the ESXi vulnerability, the Nevada locker, and behavioural queries crafted from internal incident response engagements for similar activity. You will be able to see the full details within your customer portal soon.

Updates

The information published in this document will be updated in accordance with ongoing research of the described vulnerability and ransomware campaign.

Sources

Leave a Reply