Rogue VM in VMware vSphere Tied to Muddled Libra Reveals Clear TTPs for Detecting Hypervisor Attacks


During a September 2025 incident response engagement, investigators found a rogue virtual machine inside a VMware vSphere environment that Unit 42 attributes with high confidence to the group known as Muddled Libra. The VM served as a quiet staging host. From there the attackers reconned the network, pulled stolen certificates, forged tickets, powered down domain controllers, mounted VMDKs, and copied Active Directory data off the system. Palo Alto Networks confirms these findings in a new writeup.

What happened

A threat actor created a new VM inside a vSphere console roughly two hours after initial access and used it as a beachhead. The attackers used the VM to deploy an SSH tunnel, steal certificates, mount powered-down domain controller disks, extract NTDS.dit and SYSTEM hives, run Active Directory enumeration, and query cloud data platforms. Unit 42 observed the activity and attributes it to Muddled Libra.

What Unit 42 found

Unit 42’s report begins with this summary: “During a September 2025 incident response investigation, Unit 42 discovered a rogue virtual machine (VM) which we believe with high confidence to be used by the cybercrime group Muddled Libra (aka Scattered Spider, UNC3944).” — Unit 42, Palo Alto Networks.

Unit 42 lays out the key activities observed from the rogue VM: reconnaissance, tool downloads, persistence via a C2 channel, use of stolen certificates and forged tickets, copying files from DC VMDKs, and interaction with Snowflake.

Unit 42 lays out the key activities observed from the rogue VM: reconnaissance, tool downloads, persistence via a C2 channel, use of stolen certificates and forged tickets, copying files from DC VMDKs, and interaction with Snowflake. Snowflake

The attack, step by step

Investigators reconstructed a tight timeline of activity inside the victim’s vSphere estate:

  • About two hours after initial access, attackers logged into vSphere and created a VM named “New Virtual Machine.”
  • They downloaded stolen certificates and used them to forge Kerberos tickets.
  • Within three minutes they established an SSH tunnel using the tool Chisel delivered in a ZIP named goon.zip. Unit 42 observed an attacker-controlled HTTPS-like connection over TCP 443 that lasted about 15 hours.
  • Roughly 15 minutes after VM creation, they powered down two virtualized domain controllers, mounted their VMDKs, and copied NTDS.dit and the SYSTEM hive onto the rogue VM’s Administrator desktop.
  • They ran AD enumeration toolsets such as ADRecon to capture domain topology and password policy details.
  • They also queried Snowflake and later made attempts to move mailbox PSTs and other files off-network to cloud storage.

Unit 42 explicitly notes the speed and simplicity of this workflow, which leaned on built-in virtualization features rather than heavy custom malware.

“Approximately two hours after gaining initial access to the target’s environment, we observed the attackers accessing the target’s vSphere portal and creating a new VM named ‘New Virtual Machine.’” Unit 42.
“Within three minutes, attackers established additional persistence in the target’s environment using an SSH tunnel through the Chisel tool.” Unit 42

Why this matters

This incident highlights a repeating pattern:

  1. Attackers target identity and virtualization controls because they yield broad access when abused.
  2. A single rogue VM can act as an effective pivot and storage point for sensitive artifacts.
  3. Using built-in virtualization features such as powering down VMs and mounting VMDKs makes detection harder for endpoint agents focused on guest OS telemetry.
  4. Long-running SSL/TLS-looking traffic to attacker infrastructure hides C2 tunnels inside normal ports like 443.

Defenders who only monitor endpoints or rely on signature-based detection may miss these living-off-the-land techniques.

TTPs (Tactics, Techniques, Procedures)

StageObserved activityDefensive signal to watch
Initial vSphere accessLogin to vSphere portal; create VMUnusual vSphere admin logins; new VM names like “New Virtual Machine”
PersistenceChisel SSH tunnel over TCP 443 (goon.zip)Long-lived outbound 443 from newly created VMs; unexpected binaries (chisel.exe)
Credential theftDownload stolen certs; forge Kerberos ticketsSudden ticket forging; abnormal Kerberos ticket lifetimes
DC compromisePower off DC VMs; mount VMDKs; copy NTDS.dit, SYSTEMVM power-off events for DCs; VMDK attach events; file copies to non-standard desktops
Post-exfiltrationADRecon, Snowflake queries, PST exfilAD enumeration artifacts; unusual Snowflake queries; outbound uploads to S3 or file stores

Detection and mitigation checklist

  • Monitor vCenter and ESXi logs for new admin accounts, unexpected vSphere console sessions, and new VM creations.
  • Alert on VM power-off events for tier-0 machines such as domain controllers.
  • Track VMDK mount and detach operations and require operator justification for such events.
  • Flag long-lived outbound connections on TCP 443 from VMs created within a short window of administrative activity.
  • Hunt for chisel.exe, goon.zip, and similar tunneling artifacts in uploaded files and storage logs.
  • Enforce least privilege for vSphere and vCenter roles; separate admin roles for virtualization and directory management.
  • Rotate and protect certificates used for service accounts. Use hardware-backed keys where possible.
  • Treat unusual Snowflake activity as high priority and require multi-person review for elevated queries and large exports.

Indicators of Compromise

  • New local user named gooner or similar immediately after VM creation.
  • Download URL patterns pointing to attacker-controlled S3 buckets with archives such as goon.zip.
  • Presence of chisel.exe or persistent tunnels using chisel.
  • result and result.kerb files or unexpected NTDS.dit / SYSTEM copies on non-DC hosts.
  • ADRecon output artifacts and unexpected PowerShell scripts in VM desktop folders.
  • Long sessions to single external IPs over TCP 443 from newly provisioned VMs.

Timeline

  • T+0: Initial foothold achieved via social engineering or help-desk compromise.
  • T+2 hours: vSphere accessed; new VM named “New Virtual Machine” created.
  • T+2 hours + 3 minutes: Chisel SSH tunnel established from rogue VM; outbound connection observed on TCP 443.
  • T+15 minutes after VM creation: Virtualized DCs powered down, VMDKs mounted, NTDS.dit and SYSTEM copied.
  • T+30 minutes: ADRecon executed; domain topology enumerated.
  • T+hours: Snowflake queries and staged exfiltration of PST or other artifacts attempted.

FAQ

Q: Who is Muddled Libra?

A: Muddled Libra is the Unit 42 label for the actor also tracked as Scattered Spider and UNC3944. The group is known for social engineering, SIM swap, and living-off-the-land intrusion methods. Muddled Libra

Q: Did attackers touch industrial control systems?

A: No. Unit 42 found impacts limited to corporate IT and virtualization management. Operational pipeline for critical systems remained segregated in the investigated case.

Q: Why create a rogue VM instead of using existing hosts?

A: Creating a VM lets attackers run tools and store artifacts where endpoint detection may be weaker. It also allows them to leverage vSphere features for disk access and movement without exposing a persistent footprint on production hosts.

Q: How long did the C2 stay active?

A: Unit 42 observed the chisel-based tunnel connection persist for roughly 15 hours to an attacker-controlled IP over TCP 443. Unit 42

Q: What immediate steps should defenders take?

A: Review vSphere admin logs, watch for VM power-off of DCs, hunt for VMDK mount events, scan for chisel and related tools, and tighten vSphere role separation and certificate protections.

Readers help support VPNCentral. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more

User forum

0 messages