{
	"id": "a324f77d-fd12-4591-961e-c8d77617346e",
	"created_at": "2026-04-06T00:13:35.584758Z",
	"updated_at": "2026-04-10T13:11:26.84667Z",
	"deleted_at": null,
	"sha1_hash": "d073f67b311d0474039b2a5897f2c54e4c6c75da",
	"title": "Analysis of ESXiArgs Ransomware | SECUINFRA",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 478270,
	"plain_text": "Analysis of ESXiArgs Ransomware | SECUINFRA\r\nPublished: 2023-04-13 · Archived: 2026-04-05 21:47:43 UTC\r\nContent\r\nAttack Vectors\r\nAnalysis of ESXiArgs Ransomware\r\nRecovery Options\r\nSteps to protect your Hypervisor\r\nYara rules\r\nIndicators of Compromise\r\nMITRE ATT\u0026CK Mapping\r\nIn this blog post we will be analyzing the recent “ESXiArgs” Ransomware variant, which spread to a large\r\nnumber of outdated, internet-exposed ESXi Servers around the world.\r\nAttack Vectors\r\nIn the past Ransomware targeting ESXi Hypervisors was largely human-operated as a later stage of general\r\nRansomware attack, where other Assets (Clients, Servers) are encrypted first. Accessing these virtualization\r\nsystems usually involves acquiring credentials first and changing configuration options to allow for remote access\r\nto the Hypervisor, where the ransomware is executed by the attacker through a “hands-on-keyboard” attack.\r\nThis changed in late 2022 when Juniper Threat Labs first discovered a novel Backdoor targeting ESXi\r\nHypervisors. A few weeks later this Backdoor script would be the first post-exploitation component of an\r\nautomated Ransomware campaign named “ESXiArgs” (after the targeted systems and the file extension .args).\r\nThe spread of ESXiArgs Ransomware surged starting on February 2nd 2023 when automated exploitation of the\r\nVulnerability CVE-2021-21974 hit many internet-facing ESXi deployments hosted with e.g. OVH, Hetzner and\r\nother Hosters around the world. The OpenSLP (Service Location Protocol) on Port 427/tcp is exploited through a\r\nHeap-Overflow leading to Remote Code Execution on the ESXi system. Public exploitation tools have been\r\navailable since June 2021. According to the warning issued by CERT-FR the vulnerability affects unpatched\r\nsystems running the following ESXi versions:\r\nESXi versions 7.x before ESXi70U1c-17325551\r\nESXi versions 6.7.x before ESXi670-202102401-SG\r\nESXi versions 6.5.x before ESXi650-202102101-SG\r\nAt the time of writing there are nearly 2500 ESXi systems exposed to the Internet that are affected by ESXiArgs\r\nRansomware as found by the search engine Censys (based on the Ransomnote being present on the ESXi Web\r\nInterface).\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 1 of 9\n\nFigure 1: Censys Search for ESXiArg victims\r\nFigure 2: Ransomnote displayed on the ESXi Webinterface of a compromised system\r\nAfter the initial exploitation of CVE-2021-21974 the threat actors persist the “vmtools.py” Backdoor script that\r\nwas previously analyzed by Juniper Threat Labs. The Web Shell consists of a HTTP Server on Port 8008 that\r\naccepts post requests with a specified command structure. Requests with the action “local” run commands on the\r\nHypervisor system and output to the web shell. Using the “remote” action the attackers can open a reverse shell to\r\nthe specified host IP and port.\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 2 of 9\n\nFigure 3: vmtools.py Script – used for a Web Shell\r\nOnce persistence on the Hypervisor is achieved the threat actors transfer the Ransomware components to the\r\nsystem through an archive file called “archieve.zip”, which contains the Ransomnotes for the Web Interface and\r\nSSH Message of the Day as well as a Bash script and an ELF binary for the file encryption.\r\nESXiArgs Ransomware is implemented in the Bash script while the supplied ELF binary is only used for the\r\nencryption process. Let’s look at the script first:\r\nFirst ESXiArgs collects a list of disk and swap files for the configured VMs on the Hypervisor and renames them.\r\nIn contrast to many other ESXi Ransomware implementations ESXiArgs does not use utilities like “esxcli”,\r\n“vmware-cmd” or “vim-cmd” to power down running VMs to be able to encrypt them, but rather it just terminates\r\nthe vmx process. This action could potentially lead to errors or corruption of VM data.\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 3 of 9\n\nFigure 4: Information Gathering and killing vmx\r\nWhen encrypting VM data ESXiArgs iterates through a list of volumes and tries to encrypt VM storage and\r\nconfiguration files using intermitted encryption blocks. The information which file to encrypt is passed as\r\narguments to the “encrypt” binary which we will analyze shortly.\r\nFigure 5: File Encryption Routine\r\nAfter encrypting the VM files the Ransomware drops two Ransomnotes: The first one will overwrite the vSphere\r\nWeb Interface (see Figure 2) and the second one will overwrite the SSH Message of the Day to be displayed on\r\nLogin.\r\nTo cover their tracks and make following investigations more difficult ESXiArgs deletes Log-Files from the\r\nsystem.\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 4 of 9\n\nFigure 6: Dropping the Ransomnote and deleting Log files\r\nLastly ESXiArgs will remove it’s persistence (e.g. via /etc/rc.local.d/local.sh) and delete all artifacts used for the\r\nencryption process to act as an Anti-Analysis measure.\r\nFigure 7: Deletion of artifacts and persistence\r\nThe ESXiArgs “encrypt” binary is a 64bit LSB ELF file with the debug information still intact. Still it only\r\nhandles the actual file encryption it is relatively small with a file size of 48KB.\r\nFigure 8: Information on the “encrypt” binary\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 5 of 9\n\nThe binary features a usage dialog and requires the RSA Public Key, the file path and values for the intermitted\r\nencryption to be passed as arguments.\r\nFigure 9: Help menu for the “encrypt” binary\r\nThe file encryption is done through a combination of asymmetric RSA and symmetric Sosemanuk algorithms.\r\nSosemanuk is part of the eSTREAM portfolio and a relatively rare sight in Ransomware. From the debug\r\ninformation contained in the binary we suspect that the threat actors may have based their implementation on this\r\nGithub repository.\r\nFigure 10: Sosemanuk and RSA encryption routines\r\nRecovery Options\r\nBefore any recovery of virtual machines in attempted the ESXi Hypervisor should be secured and backed up. In\r\nsome cases, the encryption may have failed to encrypt the VM data correctly and therefore some can be recovered.\r\nEnes Sonmez \u0026 Ahmet Aykac from YoreGroup Tech Team have documented a recovery workflow here, which\r\nmight help victims to restore their VMs in a timely manner. It seems that this process only applies to VM with\r\n“thin provisioned” storage though.\r\nUpdate (2023-02-08): CISA released a recovery script for affected Hypervisors, you can find it on GitHub.\r\nSteps to protect your Hypervisor\r\n1 – Keep your Hypervisor up-to-date: Affected ESXi versions should be upgraded to the latest patch\r\nimmediately. Versions that reached the End-of-Life in terms of vendor support should be decommissioned and\r\nmigrated to a more recent version.\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 6 of 9\n\n2 – Do not expose your Hypervisor to the public Internet: This includes all management interfaces (LAN,\r\nIPMI) but also protocols and features such as SSH, OpenSLP, SNMP and vSphere (which should all be disabled\r\nby default). Network access to the Hypervisor should be restricted through a firewall.\r\n3 – Back up your Hypervisor: As with any other system affected by Ransomware, keeping Backups is a key step\r\nin restoring the service in a timely manner. This includes Virtual Harddisk files as well as VMware configuration\r\ndata for the VMs.\r\n4 – Use Syslog to retain Logs: ESXiArgs and many other Hypervisor-specific Ransomware target Log files on\r\nthe system for deletion to prevent further investigation, so it is important to export and store these logs safely.\r\n5 – Disable the execution of unsigned software: The configuration option execInstalledOnly restricts the ESXi to\r\nonly execute so-called vSphere Installable Bundles (VIB) which refers to ESXi software components or VMware-approved third party applications. Any unsigned Ransomware binaries could therefore not be run on the system. It\r\nis important to understand that this configuration option should be persisted through UEFI SecureBoot (which\r\nrequires a supported Hardware TPM) to defend against human-operated Ransomware. More information about\r\nthis feature can be found here.\r\n6 – Review user authentication: User authentication should not be done through Active Directory to prevent\r\nLateral Movement to the Hypervisor in case of a Domain Controller compromise. Local user accounts should be\r\nrestricted to a Password Policy, limited authentication attempts and temporary lockouts if they fail to authenticate.\r\nYara rules\r\nYara rules for the Python, Bash and Binary files utilized by ESXiArgs Ransomware can be found in our Github\r\nrepository.\r\nIndicators of Compromise\r\nSamples\r\nThe Ransomware samples were procured through an affected victim on the BleepingComputer Forum.\r\n11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66  encrypt\r\n10c3b6b03a9bf105d264a8e7f30dcab0a6c59a414529b0af0a6bd9f1d2984459  encrypt.sh\r\n773d147a031d8ef06ee8ec20b614a4fd9733668efeb2b05aa03e36baaf082878  vmtools.py\r\nFilenames\r\nvmtools.py\r\nencrypt\r\n/tmp/tmpy_8th_nb\r\nnohup.out\r\npublic.pem\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 7 of 9\n\narchieve.zip\r\nmotd\r\nMITRE ATT\u0026CK Mapping\r\nTactic Technique Description Observable\r\nReconnaissance\r\nActive Scanning:\r\nVulnerability Scanning\r\n(T1595.002)\r\nThreat Actors behind\r\nESXiArgs are actively\r\nscanning for vulnerable ESXi\r\nServers\r\nCVE-2021-21974 artifacts\r\nInitial Access\r\nExploit Public-Facing\r\nApplication\r\n(T1190)\r\nExplotation of OpenSLP CVE-2021-21974 artifacts\r\nExecution\r\nCommand and\r\nScripting Interpreter:\r\nPython (T1059.006)\r\nBackdoor/Web Shell\r\nimplemented in Python\r\nvmtools.py\r\nPersistence\r\nBoot or Logon\r\nInitialization Scripts:\r\nRC Scripts\r\n(T1037.004)\r\nPersisting the Python\r\nbackdoor\r\n/etc/rc.local.d/local.sh\r\nCommand and\r\nControl\r\nNon-Standard Port\r\n(T1571)\r\nWeb Shell implemented in\r\nvmtools.py\r\nHTTP Post Server on Port\r\n8008\r\nCommand and\r\nControl\r\nNon-Standard Port\r\n(T1571)\r\nReverse Shell implemented in\r\nvmtools.py\r\nReverse Shell via specified\r\nport; default fallback: 427\r\nExecution\r\nCommand and\r\nScripting Interpreter:\r\nUnix Shell\r\n(T1059.004)\r\nRansomware functionality is\r\nimplemented in Bash\r\nencrypt.sh\r\nImpact\r\nData Encrypted for\r\nImpact (T1486)\r\nVM data is encrypted via\r\nRSA+Sosemanuk\r\nencrypt binary\r\nImpact Service Stop (T1489)\r\nEnding a process to power\r\ndown VMs\r\nKilling the vmx process in\r\nencrypt.sh\r\nImpact\r\nDefacement: External\r\nDefacement\r\n(T1491.002)\r\nDefacement of the vSphere\r\nWeb Interface\r\nOverwriting index.html\r\nwith the Ransomnote\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 8 of 9\n\nImpact\r\nDefacement: Internal\r\nDefacement\r\n(T1491.001)\r\nDefacement of the SSH\r\nMOTD\r\nOverwriting motd with the\r\nRansomnote\r\nDefense Evasion\r\nIndicator Removal:\r\nClear Linux or Mac\r\nSystem Logs\r\n(T1070.002)\r\nLog file deletion Deleting all .log files\r\nSource: https://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nhttps://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.secuinfra.com/en/techtalk/hide-your-hypervisor-analysis-of-esxiargs-ransomware/"
	],
	"report_names": [
		"hide-your-hypervisor-analysis-of-esxiargs-ransomware"
	],
	"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
		}
	],
	"ts_created_at": 1775434415,
	"ts_updated_at": 1775826686,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d073f67b311d0474039b2a5897f2c54e4c6c75da.pdf",
		"text": "https://archive.orkl.eu/d073f67b311d0474039b2a5897f2c54e4c6c75da.txt",
		"img": "https://archive.orkl.eu/d073f67b311d0474039b2a5897f2c54e4c6c75da.jpg"
	}
}