{
	"id": "5e31c192-7f80-4188-8247-58f19c218069",
	"created_at": "2026-04-06T00:08:08.50989Z",
	"updated_at": "2026-04-10T03:24:18.035569Z",
	"deleted_at": null,
	"sha1_hash": "ad6a75c66b13ba9b3bf0b3ee2e286d66fe8aa1b4",
	"title": "Analysis of Files Used in ESXiArgs Ransomware Attack Against VMware ESXi Servers",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1265392,
	"plain_text": "Analysis of Files Used in ESXiArgs Ransomware Attack Against\r\nVMware ESXi Servers\r\nBy Mehardeep Singh Sawhney\r\nPublished: 2025-08-21 · Archived: 2026-04-05 15:36:21 UTC\r\nExecutive Summary\r\nThreat\r\nThreat actors attack VMware ESXi servers using a custom  Ransomware script.\r\nThe ransomware exploits an old RCE vulnerability (CVE-2021-21974) in ESXi versions:7.0 before\r\nESXi70U1c-173255516.7 before ESXi670-202102401-SG6.5 before ESXi650-202102101-SG\r\nImpact\r\nThe ransomware encrypts files stored on the servers using RSA and Sosemanuk stream cipher.\r\nThis can lead to loss of data, business continuity, and revenue.\r\nMitigation\r\nUpdate servers to the latest versions and install the necessary patches.\r\nRegularly back-up all data stored on the servers.\r\nAnalysis and Attribution\r\nOn 03 February 2023, there was a surge in attacks targeting VMware ESXi servers. Threat actors were leveraging\r\nan old vulnerability (CVE-2021-21974) in order to gain RCE (Remote Code Execution) and launch ransomware\r\nattacks. \r\nThe OpenSLP version used in ESXi versions 7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-\r\nSG, and 6.5 before ESXi650-202102101-SG are vulnerable to a heap-overflow attack, which allowed attackers to\r\nperform Remote Code Execution.\r\nOn 03 February 2023, a member on the Bleeping Computer forum thread, with access to a targeted server, shared\r\na script and an executable, found on their ESXi servers. These files were reportedly used to encrypt the contents of\r\ntheir ESXi servers.\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 1 of 12\n\nFiles related to the attack shared by a member\r\nOverview of the files\r\nencrypt.sh (The script)\r\nThe script is used to prepare the target for encryption, and load the ransomware payload that is used to\r\nencrypt the server.\r\nThe script looks for specific file extensions (.vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, and\r\n.vmem) on the server, calculates their sizes, and starts encryption.\r\nIt is also responsible for editing the configuration of the server, and renaming important files. This is done\r\nin order to make it difficult to restore the system.\r\nOnce all operations are done, the script performs a cleanup and leaves a ransom note on the victim server.\r\nencrypt binary (Ransomware Payload)\r\nBinary used by the script to encrypt the target files on the server.\r\nUses an RSA public key and the SOSEMANUK stream cipher to encrypt files.\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 2 of 12\n\nTechnical Analysis (encrypt.sh)\r\nThe script is written in Bash. It is responsible for preparing the system, and calling the Ransomware payload in\r\norder to encrypt files. Once done, it performs a cleanup on the system.\r\nPre-Encryption Operations\r\nThe script starts by setting its working directory as /tmp/. Files that it uses for the attack are stored here. After this,\r\nit uses the command esxcli vm process list | grep \"Config File\" | awk '{print $3}' to find the configuration files\r\nassociated with virtual machines on the server. \r\nIt then replaces the filenames of the disk image and swap file in all config files with 1.vmdk and 1.vswp. This is\r\ndone to make it difficult for victims to recover and reconfigure the virtual machines, since identifying the disk\r\nimages and swap files will be nearly impossible.\r\nSetting working directory, and renaming disk image and swap files associated with VMs on the\r\nserver\r\nAfter this, the script kills the running VM processes using the kill command. The script is now ready to start\r\nencryption of all files on the server.\r\nKilling running VM processes\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 3 of 12\n\nEncryption\r\nThe script starts its encryption operations by making the encrypt binary executable for all users and groups, using\r\nthe command chmod +x. Then, it iterates over the filesystem contents, looking for all files with the extensions\r\n.vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, and .vmem. All these file extensions are used by virtual\r\nmachines, for example, disk images, configuration files, swap files, etc.\r\nLooking for files with the target file extensions\r\nThe script then calculates the sizes of the files that have the target extensions, and gives the target filename\r\nextensions and sizes as arguments to the encrypt binary, along with a .pem key file. \r\nUpon investigating the usage of the binary, it is found that the .pem file is an RSA public key which is used in the\r\nencryption process.\r\nArguments taken by the binary\r\nThis commences the encryption process. Note that there is a .args file created for every file that is encrypted,\r\ncontaining metadata about the file. This could be needed for the decryption process.\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 4 of 12\n\nEncrypting files\r\nPost-Encryption Operations and Clean-Up\r\nOnce the files are encrypted, the script first replaces the Message of The Day (.motd) file with the ransom note. It\r\nthen deletes all log files in order to cover its tracks. It makes sure that the encryption process is over before it\r\nproceeds to do so.\r\nChanging message of the day to the ransom note and deleting all logs\r\nIt then deletes the file /sbin/hostd-probe, which is a file used by the hostd daemon to manage virtual machines. In\r\nthe event that a backup of this file exists, it modifies the timestamp of the file, to hide any changes made to the\r\nfile.\r\nDeletion and alteration of the hostd-probe and hostd-probe.bak files\r\nDepending on the VMware build, the script executes different operations. If the VMware build version is not 7.0 it\r\nexecutes the following steps to hide any cron jobs run by the root user:\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 5 of 12\n\nThe script modifies the contents of the /var/spool/cron/crontabs/root file. It deletes the first 8 lines of the\r\nfile.\r\nRenames the new file to the name of the original file.\r\nDeletes the original file.\r\nChanges the timestamp of the new file.\r\nDeleting and recreating the root crontabs file\r\nFor VMware build version 7.0:\r\n It removes the first line of the /sbin/hostd-probe file and overwrites the original file.\r\nDeleting and recreating the root crontabs file\r\nLastly, the script conducts its clean-up operations. The clean-up operations are as follows:\r\nDeleting the file /store/packages/vmtools.py. Note that this filename is associated with a backdoor created\r\nfor ESXi servers in the past.\r\nDeleting the last line of the file /etc/vmware/rhttpproxy/endpoints.conf, and modifying the timestamp.\r\nClear the contents of the /etc/rc.local.d/local.sh file and modify the timestamp.\r\nModify the timestamp of the /bin/hostd-probe.sh file.\r\nDelete all the files used in the attack, which are stored in the working directory.\r\nClean-up operations\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 6 of 12\n\nAfter the clean-up operations, the script starts the SSH service, possibly in the event that the threat actor wants to\r\nreturn to the server.\r\nTechnical Analysis (encrypt binary)\r\nThe ransomware payload used by the script is a GCC compiled ELF 64-bit binary, which goes by the name\r\nencrypt. The arguments that the binary takes are shown below:\r\nArguments taken by the binary\r\nPre-Encryption Operations\r\nIt first initializes the libssl library using the init_libssl function. This library contains functions that are used\r\nin encryption. \r\nIt then proceeds to get information about the previously supplied RSA public key, and creates an RSA\r\nobject, in order to RSA encrypt the files. This is done using the get_pk_data and create_rsa_obj function.\r\nAfter this, it calls the encrypt_file function\r\nPre-Encryption Operations\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 7 of 12\n\nEncryption\r\nThere are two layers of encryption applied:\r\nUsing the RSA public key earlier, the files are first RSA encrypted. This is done using the rsa_encrypt\r\nfunction.\r\nThen, the files are further encrypted using the Sosemanuk library. Sosemanuk is a stream cipher, which\r\naims for great efficiency on low-cost hardware. This is done using the sosemauk_encrypt function, which is\r\ncalled by the encrypt_simple function.\r\nThe two functions on the left, and the sosemanuk_encrypt function being called inside the\r\nencrypt_simple function on the right\r\nOSINT Analysis\r\nOSINT analysis revealed that 3200+ organizations were infected, even though it is tough to ascertain the number\r\nof vulnerable servers. However, Shodan and Censys can be used to check for infected organizations.\r\nA sample query to check on shodan: \r\nhtml:\"We hacked your company successfully\" title:\"How to Restore Your Files\"\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 8 of 12\n\nA similar query can be run on Censys to get infected organizations as well:\r\nRansom BTC Addresses\r\nThe group demands the ransom amount via the following BTC addresses:\r\n1PAFdD9fwqRWG4VcCGuY27VTW8xPZmuF1D \r\n1GequkXF8tEYrfPhpY79TrV7xRTMargC92\r\nHowever, there are no transactions on the addresses yet.\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 9 of 12\n\nRansom Note\r\nThe ransom note displayed to the victims contains the ransom amount in Bitcoin, and a TOX ID, which the\r\nvictims are told to reach in order to decrypt their files. Reportedly, the amount of Bitcoin and the TOX ID differ\r\nfrom victim to victim.\r\nAn example of the ransom note displayed to victims\r\nDetecting in the Wild\r\nResearchers at CloudSEK’s Threat Intelligence team have written YARA detection rules for both the files used in\r\nthis attack. Refer to Appendix.\r\nIndicators of Compromise (IoCs)\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 10 of 12\n\nFiles Obtained\r\nencrypt.sh\r\nencrypt\r\nSHA256\r\n10C3B6B03A9BF105D264A8E7F30DCAB0A6C59A414529B0AF0A6BD9F1D2984459\r\n11B1B2375D9D840912CFD1F0D0D04D93ED0CDDB0AE4DDB550A5B62CD044D6B66\r\nAppendix\r\nYARA Rule for detecting the script\r\nrule esxiargs_script\r\n{\r\n meta:\r\n Version = \"1.0\"\r\n author = \"MalwareIntel_TRIAD_CloudSEK\"\r\n Date = \"07/02/23\"\r\n Description = \"YARA rule to identify script used in ESXiArgs Ransomware attack\"\r\n strings:\r\n $a1 = \"START ENCRYPT: $file_e SIZE: $size_kb STEP SIZE: $size_step\" fullword nocase\r\n $a2 = \"nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem \" fullword nocase\r\n $a3 = \"/bin/ps | /bin/grep encrypt | /bin/grep -v grep | /bin/wc -l\" fullword nocase\r\n \r\n condition:\r\n all of ($a*)\r\n}\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 11 of 12\n\nYARA Rule for detecting the binary\r\nimport \"pe\"\r\nrule esxiargs_binary\r\n{\r\n meta:\r\n Version = \"1.0\"\r\n author = \"MalwareIntel_TRIAD_CloudSEK\"\r\n Date = \"07/02/23\"\r\n Description = \"YARA rule to identify Ransomware used in ESXiArgs Ransomware attack\"\r\n strings:\r\n $a1 = \"usage: encrypt [] [] []\" fullword nocase\r\n $a2 = \"enc_step - number of MB to skip while encryption\" fullword nocase\r\n $a3 = \"enc_size - number of MB in encryption block\" fullword nocase\r\n $a4 = \"file_size - file size in bytes (for sparse files)\" fullword nocase\r\n \r\n condition:\r\n uint32(0) == 0x464C457F and all of ($a*)\r\n}\r\nSource: https://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nhttps://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.cloudsek.com/blog/analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers"
	],
	"report_names": [
		"analysis-of-files-used-in-esxiargs-ransomware-attack-against-vmware-esxi-servers"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"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": 1775434088,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ad6a75c66b13ba9b3bf0b3ee2e286d66fe8aa1b4.pdf",
		"text": "https://archive.orkl.eu/ad6a75c66b13ba9b3bf0b3ee2e286d66fe8aa1b4.txt",
		"img": "https://archive.orkl.eu/ad6a75c66b13ba9b3bf0b3ee2e286d66fe8aa1b4.jpg"
	}
}