CTI Roundup: ESXiArgs Ransomware Attacks Target VMware

This week, CTI breaks down the rapidly developing ESXiArgs ransomware campaign encrypting thousands of ESXi servers. Next, we explore an upward trend involving threat actors distributing malware via OneNote files — a once-uncommon delivery method. Finally, we wrap things up with a more strategically oriented intelligence story focused on President Biden’s recent remarks, given during his second State of the Union address, on the nation’s urgent need for a comprehensive federal data privacy law.

1. Massive ESXiArgs ransomware attack targets VMware ESXi servers worldwide

According to a bulletin from France’s CERT-FR, attackers are actively targeting VMware ESXi servers – allegedly focusing on servers which remain unpatched and vulnerable to CVE-2021-21974 (a two-year-old remote code execution vulnerability) in a widespread campaign featuring the relatively unknown ESXiArgs ransomware.

At the time of reporting, tracking from Censys had put the number of compromised servers (located in Canada, France, Finland, Germany, and the U.S.) at 3,200 and rising. Researchers note that the victim count is likely higher due to internet search engines only delivering a snapshot, or point-in-time scan, and devices are regularly being taken offline for remediation between scans.

New ESXiArgs ransomware

According to a post published by Recorded Future’s TheRecord blog, the ransomware featured in the campaign is being referred to as ESXiArgs because the malware creates an additional file with the extension .args following the document’s encryption. This file contains information on how to decrypt the victim document.

The strain of ransomware involved in the campaign initially appeared to be linked to the Nevada ransomware family — a theory propagated in a blog post published by French cloud hosting provider OVHcloud (a firm whose customers are counted among the victims impacted by this campaign). However, this hypothesis was eventually debunked. Similarities between ESXiArgs and Babuk ransomware have also been noted, as they both make use of the same encryption cipher (Sosemanuk), but differences in the malware’s code structure have cast doubt on this probability as well.

Arctic Wolf says that based on the ransom note, the campaign is likely the work of a single threat actor or group. This assumption is due to the untargeted nature of the campaign, its likely lack of pre-operation reconnaissance on victims, and the attackers’ relatively low extortion demand of two Bitcoin. Each note also has an identical Tox ID, which is used by victims to engage with the threat actor in communication. A Tox ID is used to add people to contact lists within the Tox Chat messaging platform.

Attribution aside, OVHcloud was able to provide the following behavioral characteristics drawn from customers’ ESXiArgs-related incidents:

• The compromission vector is confirmed to use a OpenSLP vulnerability that might be CVE-2021-21974 (still to be confirmed). The logs indicate the user dcui is involved in the compromission process.
• Encryption uses a public key deployed by the malware in /tmp/public.pem.
• The encryption process is specifically targeting virtual machines files (.vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, and .vmem).
• The malware tries to shut down virtual machines by killing the VMX process to unlock the files. This function is not systematically working as expected, resulting in files remaining locked.
• The malware creates argsfile to store arguments passed to the encrypted binary (number of MB to skip, number of MB in encryption block, file size).
• No data exfiltration occurred.

ID Ransomware’s Michael Gillespie reportedly analyzed a copy of the ESXiArgs encryptor, telling BleepingComputer that, unfortunately, it is a secure encryptor with no cryptography bugs that could potentially enable decryption.

Propagation

Researchers believe that ESXiArgs is spreading via the exploitation of CVE-2021-21974, a two-year-old security flaw relating to a heap overflow issue in the OpenSLP service, which essentially renders unpatched ESXi hypervisors vulnerable to unauthenticated threat actors in low-complexity attacks.

No zero-day involved

On February 6, 2023, VMware issued an advisory urging administrators to patch ESXi servers and disable the OpenSLP service, the company made a point of confirming that the attackers were not exploiting a zero-day vulnerability to spread ESXiArgs ransomware.

Essentially, VMware verified that the large-scale campaign was in fact the result of ransomware actors targeting internet-exposed, unpatched ESXi servers. VMware noted that this service is disabled by default in ESXi software releases issued since 2021.

What’s being impacted?

VMWare describes ESXi as a “bare-metal hypervisor … with direct access to and control of underlying resources” — offering access to critical files and allowing the attackers to disrupt an enormous range of the user’s resources.

BleepingComputer reports that CVE-2021-21974 affects the following systems:

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

A patch was issued for CVE-2021-21974 in February of 2021. Government agencies and security researchers are currently encouraging network administrators to update any unpatched servers immediately.

Second wave of ESXiArgs ransomware attacks; initial access vector questioned

In the latest update, what appears to be a second wave of ESXiArgs ransomware attacks features a revised version of the malware and encrypts more extensive amounts of data, ultimately making it much more difficult — if not impossible — for responders to recover encrypted VMware ESXi virtual machines.

Cybersecurity blog BleepingComputer claims to have first learned of the second wave of attacks after an admin posted in the blog’s EXSiArgs Support forum topic.

Security professionals are now also questioning the validity of the widely accepted assertion that the campaign’s initial infection vector is in fact the exploitation of VMware ESXi servers which remain unpatched and vulnerable to CVE-2021-21974.

New ESXiArgs version

After analyzing samples of the new ransomware variant, BleepingComputer reportedly found that, while ESXiArg’s encryptor had not changed, the portion of the encryption routine’s code that dictated the amount of data encrypted had been altered — essentially causing the encryptor to alternate between encrypting between 1MB of data and skipping 1MB of data. This means that all files more than 128MB now have 50% of their data encrypted, rendering them virtually unrecoverable.

The alterations also prevent the recovery tools issued by the Cybersecurity and Infrastructure Security Agency (CISA) via its GitHub page in response to the initial wave of attacks from successfully recovering encrypted systems, as too much data will have been encrypted to be usable.

What’s more, the ransom note no longer includes a Bitcoin address. This was likely an attempt by ESXiArg’s operators to keep ransom payments from being tracked by security researchers.

Is CVE-2021-21974 the true culprit?

According to a recent article posted to Greynoise’s blog, security researchers may be a bit premature in their conclusions linking the ESXiArgs ransomware campaign to the exploitation of CVE-2021-21974.

From the post:

The relationship between CVE-2021-21974 and the ransomware campaign may be blown out of proportion. We do not currently know what the initial access vector is, and it is possible it could be any of the vulnerabilities related to ESXi’s OpenSLP service.

The Security Community seems to be focusing on a single vulnerability. GreyNoise believes that CVE-2021-21974 makes sense as an initial access vector, but are not aware of any 1st party sources confirming that to be the case. We encourage defenders to remain vigilant and not accept every vendor at their word (including us).

This statement is bolstered by the fact that several victims have reportedly claimed OpenSLP was disabled on their devices and were breached and encrypted regardless. Still, the question remains: How did the security community arrive at the attribution of the ESXiArgs campaign to a specific CVE in the first place?

An October 2022 blog post published by Juniper Networks introduced the potential for abuse of the various OpenSLP vulnerabilities which exist in different versions of ESXi. While the post stopped short of attributing a specific vulnerability to an instance of successful exploitation, it did provide details on the backdoor that was installed post-exploitation in observed incidents.

In sum, there are many different OpenSLP vulnerabilities across multiple versions of ESXi, including CVE-2021-21974, CVE-2020-3992, and CVE-2019-5544. Several of these have most likely been exploited in the past to install a malicious backdoor, and as reported by Greynoise, and, while “No CVE is being concretely attributed as the initial access vector for the ESXiArgs campaign by first-party sources,” security researchers seem to have agreed that these facts stand well enough on their own — enabling them to make the leap to fingering CVE-2021-21974 as the mysterious ESXiArgs ransomware’s initial access vector.

A recently updated deep-dive into ESXiArgs published by Censys points out the following, casting further doubt on OpenSLP being the attackers’ avenue of attack:

“As we reported yesterday, OpenSLP does not appear to be the method of attack, given that multiple compromised hosts did not have SLP running.”

Analyst comments from Tanium’s Cyber Threat Intelligence Team

“This latest development underscores for both security professionals and cyber threat intelligence analysts the value of refraining from jumping to premature conclusions — particularly when such claims aren’t based on first-hand accounts or the affected vendors. Doing so only serves to inject an already serious situation with fear, uncertainty, and doubt. The truth always has a way of surfacing. It’s usually just a matter of time.” 

“The fact that the new ESXiArgs variant can render impacted systems virtually unrecoverable should serve to highlight the importance of identifying exposed and/or vulnerable systems and securing them immediately. Whether or not CVE-2021-21974 is the method of entry for the actors behind this campaign, the presence of a two-year-old RCE vulnerability in unpatched ESXi virtual machines is an unnecessary risk.”

2. New QakNote attacks push QBot malware via Microsoft OneNote files

Sophos has observed a new large-scale attack, dubbed QakNote, pushing QBot malware via Microsoft OneNote files.

Rising trend: Using OneNote files to deliver malware

Security firms have been tracking the growth of malware being delivered via .one OneNote files for some time. Until recently, this tactic was rarely employed by cybercriminals. However, in January 2023, Proofpoint observed over 50 OneNote campaigns delivering various malware payloads including AsyncRAT, Redline, AgentTesla, and Doubleback. Of particular interest is the use of OneNote documents to deliver QBot by initial access broker TA577 at the end of January 2023.

Why the sudden increase in the number of campaigns leveraging OneNote to deliver malware? While it’s hard to point to a definitive answer, it’s believed that threat actors are pivoting to OneNote because of Microsoft’s decision to block macros by default in documents originating from the internet. This decision has led threat actors to experiment with various TTPs to bypass detection solutions.

What is new with QBot malware?

QBot, also known as QakBot (hence the campaign name of QakNote), is historically known as a banking trojan – though, like many of its peers, it has since evolved into a multi-faceted info-stealing malware – and has been active for years.

QBot steals sensitive data and works to self-propagate to other systems on the network. QBot has evolved to provide remote code execution (RCE) capabilities, allowing threat actors to perform manual attacks to achieve secondary objectives.

Research from Sophos involving malicious .one files led to the discovery of QBot malware being pushed via this threat vector. QBot appears to have begun leveraging .one documents in attacks towards the end of January. In one observed campaign, the malicious email contained a link, prompting the victim to download a malicious .one file. In this campaign, the email message was rather impersonal.

Another observed instance followed tactics more commonly known to QBot where the malicious email is injected into the middle of an existing conversation. This thread included the .one file directly as an attachment.

Regardless of whether the user clicks on a link leading them to the OneNote document or opens the attachment directly, they are led to a OneNote page which states, “This document contains attachments from the cloud, to receive them, double click [sic] ‘open.’” The “open” button embedded in the document leads to a .hta file.

Clicking the “open” button will execute the .hta file which retrieves a sample of QBot from a remote server and executes it. The script code of the .hta file passes a hardcoded URL to the curl[.]exe application, which retrieves the file at the other end. The samples observed on the servers exhibited image-format file extensions, such as .png or .gif, but in reality were DLLs. In this instance, the QBot malware payload injected itself into AtBroker[.]exe – the Windows Assistive Technology Manager utility.

A unique characteristic was observed in some of the malicious OneNote notebooks. If you right-click and save the graphic elements in the notebook, the dialog box will pre-populate with the filename that was assigned to the image when it was initially embedded in the document. The filename in this case was
“bezymyanny risunok,” which is Russian for “anonymous drawing.”

Analyst comments from Tanium’s Cyber Threat Intelligence Team

“OneNote notebooks allow threat actors to embed almost any file type from VBS attachments to LNK files. What is interesting about threat actors using OneNote is the added social engineering step. Yes, social engineering already comes into play when the victim receives a phishing email containing the OneNote link or attachment. However, an additional social engineering aspect occurs when the user lands on the OneNote notebook and is convinced to click on the embedded attachment via some call to action.”

3. Biden’s State of the Union speech makes it clear: data privacy is a must

In his second State of the Union address, U.S. President Joe Biden devoted more attention than ever to the country’s immediate need for a measure similar in nature to the European Union’s (EU) General Data Protection Regulation (GDPR).

While the EU’s regulation — enacted in 2018 — is by no means flawless, its mere existence casts a long shadow on the U.S.’s complete lack of comprehensive federal data privacy laws. President Biden took considerable time out of his address to call attention to this gap in the nation’s cybersecurity doctrine.

Why the current political landscape may be ripe for new regulation

As control of the U.S. Congress is currently divided between parties, President Biden made the point that such circumstances could potentially aid in facilitating bipartisan support for a comprehensive federal data privacy law.

The concept of such a law or set of federal regulations has certainly gained traction and garnered its fair share of supporters in recent years — particularly in the wake of high-profile cyberattacks, including those targeting critical infrastructure, such as the ransomware attack on Colonial Pipeline in May of 2021) and those federal or local government agencies.

A new precedent?

In the eyes of media pundits and security experts alike, the mere mention of the potential enactment of a federal data privacy law in President Biden’s State of the Union address sets a precedent “that the topic should be of real concern to US presidents and the public,” as WIRED put it.

Previous presidents have typically steered clear of any talk regarding data privacy in addresses of this magnitude and with such high degrees of visibility. Of the two previous presidents, only one mentioned the topic — and only once. President Biden has raised the issue in both of his State of the Union addresses.

In his first address, which took place in 2022, President Biden mentioned data privacy in the context of protecting children and preventing big tech firms from collecting personal data. This year’s address took things further.

The next level

By expanding upon the concept he first introduced in that 2022 address and providing further insight into the cyber threats currently faced by the nation in more technical terms, President Biden — whether purposely or not — indicated that the U.S. government holds the public’s understanding of data privacy and the urgency with which the nation must improve its protection in high regard.

Analyst comments from Tanium’s Cyber Threat Intelligence Team

“The U.S. still lacks a truly comprehensive and inclusive federal data privacy law and accompanying regulatory framework. The worst-case scenario here is that we simply continue to have a national vacuum when it comes to national data privacy law. At the very least, President Biden’s statements apply enough pressure on both sides of his administration to get the ball rolling with lawmakers.”

For further reading, catch up on our recent cyber threat intelligence roundups.