{
	"id": "7bef98f8-9b56-4383-be24-ca44ef789d8f",
	"created_at": "2026-04-06T00:15:23.49662Z",
	"updated_at": "2026-04-10T03:24:17.914149Z",
	"deleted_at": null,
	"sha1_hash": "f141dc4d8d8f32ab0dfeb6857666b1a1f0767f17",
	"title": "Massive ESXiArgs ransomware attack targets VMware ESXi servers worldwide",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2089055,
	"plain_text": "Massive ESXiArgs ransomware attack targets VMware ESXi servers\r\nworldwide\r\nBy Sergiu Gatlan\r\nPublished: 2023-02-03 · Archived: 2026-04-05 20:41:59 UTC\r\nArticle updated on 2/6/23 with additional information and updated statistics.\r\nAdmins, hosting providers, and the French Computer Emergency Response Team (CERT-FR) warn that attackers actively\r\ntarget VMware ESXi servers unpatched against a two-year-old remote code execution vulnerability to deploy a new\r\nESXiArgs ransomware.\r\nTracked as CVE-2021-21974, the security flaw is caused by a heap overflow issue in the OpenSLP service that can be\r\nexploited by unauthenticated threat actors in low-complexity attacks.\r\nhttps://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nPage 1 of 8\n\n0:00\r\nhttps://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nPage 2 of 8\n\nVisit Advertiser websiteGO TO PAGE\r\n\"As current investigations, these attack campaigns appear to be exploiting the vulnerability CVE-2021-21974, for which a\r\npatch has been available since 23 February 2021,\" CERT-FR said.\r\n\"The systems currently targeted would be ESXi hypervisors in version 6.x and prior to 6.7.\"\r\nTo block incoming attacks, admins have to disable the vulnerable Service Location Protocol (SLP) service on ESXi\r\nhypervisors that haven't yet been updated.\r\nCERT-FR strongly recommends applying the patch as soon as possible but adds that systems left unpatched should also be\r\nscanned to look for signs of compromise.\r\nCVE-2021-21974 affects the following systems:\r\nESXi versions 7.x prior to ESXi70U1c-17325551\r\nESXi versions 6.7.x prior to ESXi670-202102401-SG\r\nESXi versions 6.5.x prior to ESXi650-202102101-SG\r\nFrench cloud provider OVHcloud first published a report linking this massive wave of attacks targeting VMware ESXi\r\nservers with the Nevada ransomware operation. \r\n\"According to experts from the ecosystem as well as autorities, they might be related to Nevada ransomware and are using\r\nCVE-2021-21974 as compromission vector. Investigation are still ongoing to confirm those assumptions,\" OVHcloud CISO\r\nJulien Levrard said.\r\n\"The attack is primarily targetting ESXi servers in version before 7.0 U3i, apparently through the OpenSLP port (427).\"\r\nHowever, the company backtracked soon after our story was released, saying they attributed it to the wrong ransomware\r\noperation.\r\nAt the end of the first day of attacks, approximately 120 ESXi servers were encrypted.\r\nHowever, the numbers quickly grew over the weekend, with 2,400 VMware ESXi devices worldwide currently detected as\r\ncompromised in the ransomware campaign, according to a Censys search.\r\nIn an advisory published on February 6th, VMware confirmed that this attack exploits older ESXi flaws and not a zero-day\r\nvulnerability.\r\nThe company advises admins to install the latest updates for ESXi servers and disable the OpenSLP service, which has been\r\ndisabled by default since 2021.\r\nSome admins breached in this attack said they did not have SLP enabled [1, 2], adding further confusion as to how servers\r\nwere breached.\r\nhttps://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nPage 3 of 8\n\nOverall, the ransomware campaign has not seen much success considering the large number of encrypted devices, with\r\nthe Ransomwhere ransom payment tracking service reporting only four ransom payments for a total of $88,000.\r\nThe lack of ransom payments is likely due to a VMware ESXi recovery guide created by security researcher Enes Sonmez,\r\nallowing many admins to rebuild their virtual machines and recover their data for free.\r\nNew ESXiArgs ransomware\r\nHowever, from the ransom notes seen in this attack, they do not appear to be related to the Nevada Ransomware, and\r\nappear to be from a new ransomware family.\r\nStarting roughly four hours ago, victims impacted by this campaign have also begun reporting the attacks\r\non BleepingComputer's forum, asking for help and more information on how to recover their data.\r\nThe ransomware encrypts files with the .vmxf, .vmx, .vmdk, .vmsd, and .nvram extensions on compromised ESXi servers\r\nand creates a .args file for each encrypted document with metadata (likely needed for decryption).\r\nWhile the threat actors behind this attack claim to have stolen data, one victim reported in the BleepingComputer forums\r\nthat it was not the case in their incident.\r\n\"Our investigation has determined that data has not been infiltrated. In our case, the attacked machine had over 500 GB of\r\ndata but typical daily usage of only 2 Mbps. We reviewed traffic stats for the last 90 days and found no evidence of\r\noutbound data transfer,\" the admin said.\r\nVictims have also found ransom notes named \"ransom.html\" and \"How to Restore Your Files.html\" on locked systems.\r\nOthers said that their notes are plaintext files.\r\nESXiArgs ransom note (BleepingComputer)\r\nID Ransomware's Michael Gillespie is currently tracking the ransomware under the name 'ESXiArgs,' but told\r\nBleepingComputer that until we can find a sample, there is no way to determine if it has any weaknesses in the encryption.\r\nBleepingComputer has a dedicated ESXiArgs support topic where people are reporting their experiences with this attack and\r\nreceiving help recovering machines.\r\nESXiArgs technical details\r\nhttps://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nPage 4 of 8\n\nLast night, an admin retrieved a copy of the ESXiArgs encryptor and associated shell script and shared it in the\r\nBleepingComputer support topic.\r\nAnalyzing the script and the encryptor has allowed us to understand better how these attacks were conducted.\r\nWhen the server is breached, the following files are stored in the /tmp folder:\r\nencrypt - The encryptor ELF executable.\r\nencrypt.sh - A shell script that acts as the logic for the attack, performing various tasks before executing the\r\nencryptor, as described below.\r\npublic.pem - A public RSA key used to encrypt the key that encrypts a file.\r\nmotd - The ransom note in text form that will be copied to /etc/motd so it is shown on login. The server's original file\r\nwill be copied to /etc/motd1.\r\nindex.html - The ransom note in HTML form that will replace VMware ESXi's home page. The server's original file\r\nwill be copied to index1.html in the same folder.\r\nID Ransomware's Michael Gillespie analyzed the encryptor and told BleepingComputer the encryption is, unfortunately,\r\nsecure, meaning no cryptography bugs allow decryption.\r\n\"The public.pem it expects is a public RSA key (my guess is RSA-2048 based on looking at encrypted files, but the code\r\ntechnically accepts any valid PEM).,\" Gillespie posted in the forum support topic.\r\n\"For the file to encrypt, it generates 32 bytes using OpenSSL's secure CPRNG RAND_pseudo_bytes, and this key is then\r\nused to encrypt the file using Sosemanuk, a secure stream cipher. The file key is encrypted with RSA\r\n(OpenSSL's RSA_public_encrypt), and appended to the end of the file.\"\r\n\"The use of the Sosemanuk algorithm is rather unique, and is usually only used in ransomware derived from the Babuk\r\n(ESXi variant) source code. This may perhaps be the case, but they modified it to use RSA instead of Babuk's Curve25519\r\nimplementation.\"\r\nThis analysis indicates that ESXiArgs is likely based on leaked Babuk source code, which has been previously used by other\r\nESXi ransomware campaigns, such as CheersCrypt and the Quantum/Dagon group's PrideLocker encryptor.\r\nWhile the ransom note for ESXiArgs and Cheerscrypt are very similar, the encryption method is different, making it unclear\r\nif this is a new variant or just a shared Babuk codebase.\r\nFurthermore, this does not appear to be related to the Nevada ransomware, as previously mentioned by OVHcloud.\r\nThe encryptor is executed by a shell script file that launches it with various command line arguments, including the public\r\nRSA key file, the file to encrypt, the chunks of data that will not be encrypted, the size of an encryption block, and the file\r\nsize.\r\nusage: encrypt \u003cpublic_key\u003e \u003cfile_to_encrypt\u003e [\u003cenc_step\u003e] [\u003cenc_size\u003e] [\u003cfile_size\u003e]\r\n enc_step - number of MB to skip while encryption\r\n enc_size - number of MB in encryption block\r\n file_size - file size in bytes (for sparse files)\r\nThis encryptor is launched using the encrypt.sh shell script that acts as the logic behind the attack, which we will briefly\r\ndescribe below.\r\nWhen launched, the script will execute the following command to modify the ESXi virtual machine's configuration files\r\n(.vmx) so that the strings '.vmdk' and '.vswp' are changed to '1.vmdk' and '1.vswp'.\r\nhttps://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nPage 5 of 8\n\nModifying VMX files\r\nSource: BleepingComputer\r\nThe script then terminates all running virtual machines by force-terminating (kill -9) all processes containing the string 'vmx'\r\nin a similar way to this VMware support article.\r\nThe script will then use the ' esxcli storage filesystem list | grep \"/vmfs/volumes/\" | awk -F' ' '{print $2} ''\r\ncommand to get a list of ESXi volumes.\r\nThe script will search these volumes for file's matching the following extensions:\r\n.vmdk\r\n.vmx\r\n.vmxf\r\n.vmsd\r\n.vmsn\r\n.vswp\r\n.vmss\r\n.nvram\r\n.vmem\r\nFor each found file, the script will create a [file_name].args file in the same folder, which contains the computed size step\r\n(shown below), '1', and the size of the file.\r\nFor example, server.vmx will have an associated server.vmx.args file.\r\nThe script will then use the 'encrypt' executable to encrypt the files based on the computed parameters, as shown in the\r\nscreenshot below.\r\nRoutine to create .args files and encrypt files\r\nSource: BleepingComputer\r\nAfter the encryption, the script will replace the ESXi index.html file and the server's motd file with the ransom notes, as\r\ndescribed above.\r\nFinally, the script performs some cleanup by deleting logs, removing a Python backdoor installed\r\nat /store/packages/vmtools.py [VirusTotal], and deleting various lines from the following files:\r\n/var/spool/cron/crontabs/root\r\n/bin/hostd-probe.sh\r\n/etc/vmware/rhttpproxy/endpoints.conf\r\n/etc/rc.local.d/local.sh\r\nhttps://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nPage 6 of 8\n\nCleanup of various Linux configuration files and potential backdoor\r\nSource: BleepingComputer\r\nThe /store/packages/vmtools.py file is the same custom Python backdoor for VMware ESXi server discovered by Juniper in\r\nDecember 2022, allowing the threat actors to remotely access the device.\r\nAll admins should check for the existence of this vmtools.py file to make sure it was removed. If found, the file should be\r\nremoved immediately.\r\nFinally, the script executes the /sbin/auto-backup.sh to update the configuration saved in the /bootbank/state.tgz file and\r\nstarts SSH.\r\nThis is a developing story and will be updated with new info as it becomes available ...\r\nUpdate 2/4/23: Added technical details about the attack. - Lawrence Abrams\r\nUpdate 2/5/23: Updated with new number of encrypted ESXi servers and method to recover virtual machines.\r\nUpdate 2/6/23: Added info from VMware and known ransom payments.\r\nhttps://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nPage 7 of 8\n\nAutomated Pentesting Covers Only 1 of 6 Surfaces.\r\nAutomated pentesting proves the path exists. BAS proves whether your controls stop it. Most teams run one without the\r\nother.\r\nThis whitepaper maps six validation surfaces, shows where coverage ends, and provides practitioners with three diagnostic\r\nquestions for any tool evaluation.\r\nSource: https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nhttps://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/"
	],
	"report_names": [
		"massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434523,
	"ts_updated_at": 1775791457,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f141dc4d8d8f32ab0dfeb6857666b1a1f0767f17.pdf",
		"text": "https://archive.orkl.eu/f141dc4d8d8f32ab0dfeb6857666b1a1f0767f17.txt",
		"img": "https://archive.orkl.eu/f141dc4d8d8f32ab0dfeb6857666b1a1f0767f17.jpg"
	}
}