GhostFrame ESXi Implant Linked to Settra Ransomware

Summary

GhostFrame is a newly identified post-exploitation framework built specifically for compromised VMware ESXi hypervisors. It enables attackers with root access to control virtual machines, harvest credentials from guest Windows systems, and pivot across internal networks. The framework is linked to threat group TAG-218 and associated with Settra ransomware operations.

Investigation

Insikt Group discovered GhostFrame while monitoring TAG-218 infrastructure and identified overlaps with Settra ransomware activity. The investigation uncovered a web-based C2 panel and an ESXi implant that establishes persistence by modifying boot scripts and disabling security controls. Analysis also showed the framework using a distinctive multi-port TCP connection pattern for C2 communication.

Mitigation

Organizations should tightly restrict and monitor privileged access to ESXi hosts to reduce the risk of root-level compromise. Defenders should watch for unauthorized changes to /etc/rc.local.d/local.sh and attempts to disable the ESXi firewall or execInstalledOnly settings. Network monitoring should also flag simultaneous TCP SYN activity across ports 53, 2222, 3389, 4444, 8443, and 9443.

Response

When malicious activity is detected, administrators should investigate the source of unauthorized privileged access rather than simply restoring disabled security settings. Perform forensic analysis of the ESXi host for the vmhostd-core implant and modified boot scripts. Isolate the compromised hypervisor and initiate incident response procedures for all virtual machines hosted on the affected system.

Simulation Execution

• Attack Narrative & Commands: The adversary, having gained persistence via valid credentials, seeks to establish a long-term backdoor. To avoid detection by sysadmins monitoring the ESXi environment, they deploy a custom implant. The adversary creates a directory /opt/ (if not existing), moves their malicious payload to /opt/vmhostd-core, and executes it with the process name vmhostd. This specific combination of path and name is intended to trigger the rule but is designed to mimic the vmware-hostd service used by legitimate VMware operations.

• Regression Test Script:

  #!/bin/bash
  # GhostFrame Simulation Script
  # This script mimics the GhostFrame implant setup to trigger the detection rule.
  
  # 1. Create the target directory
  sudo mkdir -p /opt/
  
  # 2. Create a "malicious" dummy binary
  echo -e '#!/bin/bashnwhile true; do sleep 60; done' | sudo tee /opt/vmhostd-core > /dev/null
  sudo chmod +x /opt/vmhostd-core
  
  # 3. Execute the binary with the specific name/path required by the rule
  # We use 'exec -a' to set the process name to 'vmhostd' as required by the detection logic
  echo "[+] Simulating GhostFrame implant execution..."
  sudo exec -a vmhostd /opt/vmhostd-core &
  
  SIM_PID=$!
  echo "[+] Implant running with PID: $SIM_PID"
  sleep 5
  kill $SIM_PID
  echo "[+] Simulation complete."

• Cleanup Commands:

  # Remove the simulated implant files and directories
  sudo rm -f /opt/vmhostd-core
  # Note: We do not remove /opt/ itself as it is a standard Linux directory.