My thoughts and observations as I followed this incident and watched it unfold across the internet at the beginning of February. There’s not much that hasn’t already been said by various infosec resources (some links I found useful are shared throughout this post), but here’s my take all the same.

What’s Special About It?

This particular incident caught my attention because it was a rare opportunity to track ransom payments associated with all victims for a specific ransomware variant/attack campaign. While there are projects that attempt to track ransomware payment statistics publicly (https://ransomwhe.re/), and the FBI tracks ransom payments for any victims that submit IC3 reports, it isn’t a complete list due to so many victims that don’t share the information (for a variety of reasons). With the first version of the ransomware that began spreading around 2/2/23-2/3/23 an encrypted server would publicly display the ransom amount and bitcoin wallet to send payment to:

Now imagine being able to collect all of these bitcoin wallet addresses and then tracking those wallets to see how many paid, and what they ended up paying! What a unique opportunity to understand the financial impacts of such an attack.

Where Did I Start?

The first step was to find all the impacted pages. Shodan was the first place I turned as my go-to for scraping webpages. I just needed to find all the pages that contained some indicators tying to this incident like “How to Restore Your Files” or “TOX_ID”

I cross checked my results across different scraping services and found that the results were different, depending on where you looked. I spent a lot of time trying to identify all the victims across multiple sites. My results were as follows:

• Shodan – 646 Results
• BinaryEdge – 410 Results
• Censys – 2,559 Results

I was surprised to see such a disparity of results between services, and some of the results did increase as time went on and more victim sites were scraped. Ultimately I used a mix of results from each service, combining and deduplicated the IPs.

To get the Bitcoin wallet addresses, I could extract them from the Shodan results, but I could not get that information with my free Censys API access. I ended up scraping the HTML from each site and then extracting the wallet address and combining and deduplicating from my Shodan list and shared my results on Github. https://github.com/n2x4/Feb2023-CVE-2021-21974-OSINT

Of course, by the time I finished this, Ransomwhere shared a Github collection of all v1 victims and their bitcoin wallets with assistance from Censys: https://gist.github.com/cablej/bdc2ee2c84915d0b68eec9d4d4747e19

This list ended up containing 3805 total addresses, which was more than I had been able to extract by almost double. I attribute that to the fact that I could only scrape wallet addresses from victims that were still online at the time of my scan. Oh well. I abandoned my list and continued working from this one.

Tracking Transactions

Once I had a full list of wallet addresses, I wrote a python script to query the blockstream.info API and return results for any wallets that listed a transaction in the blockchain. That script is available on my Github linked previously.

After searching the blockchain, The total transactions observed in this incident are as follows:

Wallet	AMT	Date
bc1q46zs36ey53lem5qv2pryumtmdtmtr352fdk4pj	1.08	2022-11-07
19dCNXkarAedQhhF3SJsHRAMP7T6bVdKBs	2.18	2023-02-03
1FJ4xoPrBzZh7QsVcQqESZSMpPmCuKv3cC	2.02	2023-02-06
1NGaBgyQCyNHfeYAtGumzz5HDZpqL39o2M	0.50	2023-02-06

You can look up the transactions manually here: https://blockstream.info. Note that the first transaction dates back to November (more on this later). The other transactions likely indicate 2 victims paid full price, and a third victim likely negotiated ransom down to only 25% of the original ask. Of almost 4K unique wallet addresses, only 4 transactions were carried out.

But Wait, There’s More!

By the time this all happened, the incident had picked up considerable attention. BleepingComputer had an active discussion with recovery tips: https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension . Attention even came from CISA who shared remediation guidance and wrote a script to recover systems. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-039a

Interestingly, ESXArgs had made a big mistake that was picked up on quickly – large files (such as the virtual disks of a VM) were only partially encrypted to speed up the encryption process. This partial encryption was roughly only 1mb at the beginning of the file and as a result many of the victims only experienced partial encryption and data could be recovered with a little effort.

Once the threat actors realized their mistake roughly a week later, they began reencrypting the victims with more extensive disk encryption and altered their ransom note to no longer list bitcoin wallet addresses and only including a TOX chat ID to communicate for ransom payments. https://www.bleepingcomputer.com/news/security/new-esxiargs-ransomware-version-prevents-vmware-esxi-recovery/

Final Thoughts

My journey into this incident ended when the second round of encryption hit. With only a TOX ID for victims to reach out to the threat actors with, there wasn’t much to be observed and payments for the second round could not be tracked. The Bleeping Computer thread was still active and victims were sharing their experiences with this new variant and the communications with the threat actors. This seems to end the way that most ransomware incidents do. Some people started over, some could recover from backups, some paid; and of those that paid some could decrypt and recover their data, some could not and never heard from the threat actors again. It’s also unknown if any of the victims that paid were ever reencrypted.

It’s always interesting to try and attribute the attack. While we don’t know who is responsible, the geographic distribution of victims might tell us a story:

Looking at the map, you can see most attacks were in Europe (OVH hosted lots of vulnerable servers in France), followed by servers in the USA. No victims in:

• Russia
• China
• Africa
• South America

This is interesting because there were vulnerable servers in these countries (see here), they just happened to be excluded. It seems likely that this was targeted, but I’ll leave final attribution up to the reader. There’s also the interesting detail of when this all started. It’s difficult to see, but the following chart shows that there are non-zero results of websites with encryption notes back as far as “3 months ago”, putting the first observation back around November 2022 (and some indications that it’s been observed even earlier). This lines up with the first wallet transaction I listed earlier. Is that first payment a victim, or just the threat actors “testing” their encryptor and payments?

A scrape of one of these early sites shows a slightly different ransom note that included an email address and a TOR page. I attempted to look further into this, however the TOR page no longer exists. I also spent some time trying to track the wallets and associated transactions, but nothing stood out as insightful.

So we end with the following questions that will go unanswered – where were the attackers from? Why did they decide to wait to launch their attack? How many victims paid the ransom the second time around?

Final Link Share

Blackberry had a great analysis on their blog: https://blogs.blackberry.com/en/2023/02/esxiargs-ransomware-knocking-out-unpatched-vmware-esxi-linux-servers-worldwide

A sample of the v1 encryptor was shared to Virustotal: https://www.virustotal.com/gui/file/10c3b6b03a9bf105d264a8e7f30dcab0a6c59a414529b0af0a6bd9f1d2984459/detection

A sample was also shared to pastebin: https://pastebin.com/y6wS2BXh

Bitcoin addresses used in this attack have been flagged on ChainAbuse: https://www.chainabuse.com/address/1NGaBgyQCyNHfeYAtGumzz5HDZpqL39o2M?chain=BTC