Open-source reporting indicates that malicious actors are exploiting known vulnerabilities in VMware ESXi software to gain access to servers and deploy ESXiArgs ransomware. The actors are likely targeting end-of-life ESXi servers or ESXi servers that do not have the available ESXi software patches applied.[1] 

ESXiArgs ransomware encrypts certain configuration files on ESXi servers, potentially rendering VMs unusable. Specifically, the ransomware encrypts configuration files associated with the VMs; it does not encrypt flat files. As a result, it is possible, in some cases, for victims to reconstruct the encrypted configuration files based on the unencrypted flat file. The recovery script documented below automates the process of recreating configuration files. The full list of file extensions encrypted by the malware is: vmdk, vmx, vmxf, vmsd, vmsn, vswp, vmss, nvram, vmem.

Recovery Guidance

CISA and FBI do not encourage paying the ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, CISA and FBI urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at cisa.gov/report. 

CISA is providing these steps to enable organizations to attempt recovery of their VMs. CISA’s GitHub ESXiArgs recovery script, which also outlines these steps, is available at github.com/cisagov/ESXiArgs-Recover. CISA is aware that some organizations have reported success in recovering files without paying ransoms. CISA’s script is based on findings published by third-party researchers.[2] 

Any organization seeking to use CISA’s ESXiArgs recovery script should carefully review the script to determine if it is appropriate for their environment before deploying it. This script does not seek to delete the encrypted configuration files, but instead seeks to create new configuration files that enable access to the VMs. While CISA works to ensure that scripts like this one are safe and effective, this script is delivered without warranty, either implicit or explicit. Do not use this script without understanding how it may affect your system. CISA does not assume liability for damage caused by this script. Note: Organizations that run into problems with the script can create a GitHub issue at https://github.com/cisagov/ESXiArgs-Recover/issues; CISA will do our best to resolve concerns.

1. Quarantine or take affected hosts offline to ensure that repeat infection does not occur.
2. Download CISA’s recovery script and save it as /tmp/recover.sh.
   For example, with wget: wget -O /tmp/recover.sh https://raw.githubusercontent.com/cisagov/ESXiArgs-Recover/main/recover.sh.
3. Give the script execute permissions: chmod +x /tmp/recover.sh
4. Navigate to the folder of a VM you would like to recover and run ls to view the files.
   • Note: You may browse these folders by running ls /vmfs/volumes/datastore1. For instance, if the folder is called example, run cd /vmfs/volumes/datastore1/example.
5. View files by running ls. Note the name of the VM (via naming convention: [name].vmdk).
6. Run the recovery script with /tmp/recover.sh [name], where [name] is the name of the VM determined previously. 
   • If the VM is a thin format, run /tmp/recover.sh [name] thin.
   • If successful, the recovery script will output that it has successfully run. If unsuccessful, it may not be possible for the recovery script to recover your VMs; consider engaging external incident response help.
7. If the script succeeded, re-register the VM.
   1. If the ESXi web interface is inaccessible, remove the ransom note and restore access via the following steps. (Note: Taking the steps below moves the ransom note to the file ransom.html. Consider archiving this file for future incident review.)
      • Run cd /usr/lib/vmware/hostd/docroot/ui/ && mv index.html ransom.html && mv index1.html index.html.
      • Run cd /usr/lib/vmware/hostd/docroot && mv index.html ransom.html && rm index.html && mv index1.html index.html.
      • Reboot the ESXi server (e.g., with the reboot command). After a few minutes, you should be able to navigate to the web interface.
      • In the ESXi web interface, navigate to the Virtual Machines page.
      • If the VM you restored already exists, right click on the VM and select Unregister (see figure 1).

Figure 1: Unregistering the virtual machine.

• Select Create / Register VM (see figure 2).
• Select Register an existing virtual machine (see figure 2).

Figure 2: Registering the virtual machine, selecting machine to register.

Click Select one or more virtual machines, a datastore or a directory to navigate to the folder of the VM you restored. Select the vmx file in the folder (see figure 3).

Figure 3: Registering the virtual machine, finalizing registration.

Select Next and Finish. You should now be able to use the VM as normal.

Figure 3: Registering the virtual machine, finalizing registration.

Select Next and Finish. You should now be able to use the VM as normal.

8. Update servers to the latest software version, disable the Service Location Protocol (SLP) service, and ensure the ESXi hypervisor is not configured to be exposed to the public internet before putting systems back online. 

Additional Incident Response

The above script only serves as a method to recover essential services. Although CISA and FBI have not seen any evidence that the actors have established persistence, we recommend organizations take the following additional incident response actions after applying the script:

1. Review network logging to and from ESXi hosts and the guest VMs for unusual scanning activity.
2. Review traffic from network segments occupied by the ESXi hosts and guests. Consider restricting non-essential traffic to and from these segments.

If you detect activity from the above, implement your incident response plan. CISA and FBI urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at cisa.gov/report.

Organizations should also collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.

See the joint CSA from the cybersecurity authorities of Australia, Canada, New Zealand, the United Kingdom, and the United States on Technical Approaches to Uncovering and Remediating Malicious Activity for additional guidance on hunting or investigating a network, and for common mistakes in incident handling. CISA also encourages government network administrators to see CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. Although tailored to federal civilian branch agencies, these playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail steps for both incident and vulnerability response.  

Additional resources for recovering .vmdk files can be found on a third-party researcher’s website.[2]

Looking over some of our honeypot logs today, I noticed one IP address, 60.223.74.99, scanning for several older Confluence vulnerabilities.

Confluence is the collaboration component of Atlassian's suite of developer tools [1]. Attacks against developers, and the tools they are using, are on the rise in general, and this is yet another "piece to the puzzle." A quick search using NIST's NVD shows 18 vulnerabilities in Confluence [2].

The scans use a known PoC exploit for CVE-2021-26084, an OGNL injection vulnerability[3].

Here are two sample requests sent by the attacker:

POST /users/user-dark-features HTTP/1.1
Host: [redacted]:8090
User-Agent: Mozilla/5.0 (X11; Gentoo; rv:82.1) Gecko/20100101 Firefox/82.1
Accept-Encoding: gzip, deflate
Accept: **
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 58

queryString=aaaa%5Cu0027%2B%7B3304%2A9626%7D%2B%5Cu0027bbb

All endpoints hit by the attacker:

/confluence/pages/createpage-entervariables.action
/confluence/pages/createpage-entervariables.action?SpaceKey=x
/pages/createpage.action?spaceKey=myproj
/pages/createpage-entervariables.action
/pages/createpage-entervariables.action?SpaceKey=x
/pages/doenterpagevariables.action
/pages/templates2/viewpagetemplate.action
/template/custom/content-editor
/templates/editor-preload-container
/users/user-dark-features
/wiki/pages/createpage-entervariables.action
/wiki/pages/createpage-entervariables.action?SpaceKey=x

The payload string decodes to:

aaaa'{506*5210}'bbb

The likely goal is to have the system return the result of the math problem to see if it is vulnerable to this attack.

No scans were seen from that source IP until today. It appears to be an otherwise unremarkable IP address allocated to what looks like a China Unicom consumer. It may be a CGNAT address used by China Unicom.

[1] https://www.atlassian.com/software/confluence
[2] https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=cpe%3A2.3%3Aa%3Aatlassian%3Aconfluence_data_center&search_type=all&isCpeNameSearch=false
[3] https://github.com/alt3kx/CVE-2021-26084_PoC

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Login here to join the discussion.

As we have done for prior DDoS Attack Trends reports, we recently analyzed attack data from the F5 Distributed Cloud DDoS Mitigation service to get a look at the DDoS traffic they handled for their customers in 2022. We continued our analysis by comparing 2022 data to that of 2021 and 2020. Some interesting trends emerged.

Executive Summary

• Application layer attacks up by 165%
• The Technology sector takes the top spot as most attacked over 2021
• Overall observed events are down by -9.7%
• Peak Bandwidth up 216% from 2020
• All verticals should expect to see more Application and Multi-vector DDoS

A Note on the Analysis

Distributed Denial of Service (DDoS) has been an issue for a very long time, and while our defenses have come a long way since the earliest days, such attacks can still be devastating. Attackers continue to use these techniques to annoy, harass, and extort vulnerable targets, so tracking DDoS trends remains an important function of threat intelligence writ large. There are, however, a few things to keep in mind when reading any analysis of DDoS trends and events. Bringing a critical frame of mind to any data to determine relevance to your specific situation is key to being able to turn observations into action. Any dataset relating to DDoS traffic will only show what the collection point was able to observe, and this will be only a fraction of the total DDoS that occurred across the internet.

While the observations may be a small subset of the total landscape of DDoS, we nevertheless feel the trends observed in this data may be broadly comparable to the entire situation, as F5 Silverline protects a diverse group of customers, ranging from small to large enterprises, and from many different industry verticals.

Terms Used in This Report

If you’re new to denial of service attacks and would benefit from a detailed look at the types and method of DoS attacks, and the motivations of the many threat actors who use them, take a look at our Learning Center article What is a Distributed Denial-of-Service Attack?

Peak Bandwidth

Nearly all DDoS attacks will have a ramp up and a ramp down period in terms of the bandwidth they use. The peak bandwidth is defined here as the maximum observed bandwidth in a single point in time during the attack. It does not indicate how long the total attack lasted, but does give some indication as to the resources the attacker put towards creating it, and to some extent, its intensity.

Attack Type Classifications

Because there is a large number of specific DDoS attack types, we’ve broken them out into the following categories. Our classification scheme roughly overlaps with the DDoS terms used by the MITRE ATT&CK framework.

Volumetric

Volumetric attacks use a variety of techniques to attempt to overwhelm the available bandwidth at the target. Such techniques include UDP floods, ICMP floods, and reflection attacks leveraging protocols such as NTP, Memcached, and DNS to amplify the amount of traffic received by the target.

Protocol

Protocol attacks are those that specifically target the ability of network infrastructure to track and handle traffic. Examples include TCP Syn and TCP Ack flooding. These are also known as ‘computational’ attacks, since they often overload the compute capacity of network devices, such as routers and firewalls.

Application

Application attacks are those that target higher level protocols, the most frequently observed being HTTP GET floods, TLS renegotiation, and DNS queries. We make the distinction here between DNS reflection, whose aim is to flood the targets internet connection with query response traffic, and DNS queries, which are made directly to the target’s DNS infrastructure, with the aim of denying legitimate requests the ability to resolve domain names.

Multiple Vector

We use the term “multiple-vector” for attacks which leverage more than one of the above methods. More details on the specific combinations observed are mentioned in passing in the rest of the report. While many DDoS attacks use a single vector, these multiple-vector methods are becoming increasingly common.

2022 DDoS Insights

In 2022, we saw the overall number of attacks trend down a small amount, and saw a sharp rise in the number of Application layer attacks.

Trend 1: Overall DDoS Attacks Were Slightly Down

In 2022, we note a slight reduction (-9.7%) in the overall events observed from that of 2021, continuing a similar reduction in overall events between 2020 and 2021 (-3.5%). The number of events observed per quarter does not vary much. Q1 2022 was significantly less than the same quarter in the year before, with a 50.7% reduction (Figure 1).

This is perhaps attributable to the beginning of the Russian invasion of Ukraine. At that time, it was noted by several threat research firms that there was significant turmoil among various cybercriminal organizations, as they determined what their approach would be regarding the conflict, and which side, if any, they would align with. Resources were redirected, at least briefly, to support one side or the other of the conflict, and several large-scale DDoS attacks against both Russian and Ukrainian targets made the news. This may account for the drop in Q1 events we observed, but we can’t be sure. The overall drop from Q4 2021 to Q1 2022 was -25%.

Politically motivated attacks are ongoing – as this report was being written, widespread DDoS attacks against hospitals were being reported, and attributed to Killnet, a Russian-aligned group which has launched such attacks against several verticals since the war began.¹ Please see the section “Is Killnet a Sign of Things to Come?” below for more details.

The level of attacks ramped back up to approximately normal levels in the following quarters, increasing an average of 30% quarter to quarter, and although the overall yearly totals were down, Q4 2022 showed the highest observed number of events in a single quarter across all three years. See Figure 1.