Oracle Launches First-of-its-Kind Defense Ecosystem to Redefine National Security Innovation

June 18, 2025

GerriScary Hacking the Supply Chain of Popular Google Products

June 23, 2025

How Falcon Next-Gen SIEM Protects Enterprises from VMware vCenter Attacks

CrowdStrike has created a new parser, rule templates, and dashboards for Falcon Next-Gen SIEM to better protect organizations from attacks targeting vCenter.

Internet-facing assets are targeted for many reasons, such as to establish persistence, evade defensive capabilities, and access sensitive networks. According to the search engine Shodan, approximately 1,600 VMware vSphere instances are directly accessible via the internet, representing a significant attack surface. Defending them is critical: A compromised vCenter instance can lead to full control over an organization's virtual infrastructure, potentially impacting business continuity, data confidentiality, and overall security posture.

Past events underscore the urgency of securing vCenter instances. In January 2024, VMware confirmed that a critical vCenter Server remote code execution vulnerability (CVE-2023-34048), patched in October 2023, was under active exploitation. This vulnerability allowed attackers to remotely execute code without authentication, potentially giving them full control over an organization's virtual infrastructure.

With CrowdStrike Falcon® Next-Gen SIEM, CrowdStrike gives defenders the ability to quickly detect and respond to threats targeting vCenter. We’ve created a new parser and numerous rule templates and dashboards for Falcon Next-Gen SIEM to better protect organizations from these attacks. In this blog, we detail in-the-wild attacks targeting vCenter, the corresponding rule templates that may be used to detect these threats, and how customers can ingest vCenter logs into Falcon Next-Gen SIEM.

Attacks Seen in the Wild

The following sections will cover a handful of threats against vCenter instances. They are accompanied by the rule templates created by CrowdStrike that can be used to detect the described attacks.

Bring Your Own (BYO) ISO Persistence

In this attack scenario, the adversary attempts to establish persistence by downloading an unmanaged ISO file to a compromised system. Once downloaded, the ISO is uploaded to vCenter from the foothold system. Alternatively, the adversary could simply use an ISO already present within vCenter, such as a base Windows image that was left by administrators.

Either way, the adversary uses this ISO to create a virtual machine they use for continued operations within the environment. This enables persistence for the adversary, as the unmanaged operating system now runs from vCenter and is accessible to and wholly owned by the threat actor, with limited visibility of the new host to the organization being compromised.

Detecting BYO ISOs

To detect BYO ISO persistence, first we must break down the attack path into individual stages. This attack contains four stages, which is a good recipe for correlation, as outlined below.

Upload the ISO into a vCenter datastore.
Create an unmanaged virtual machine (VM) appliance on the vCenter server.
Attach the newly uploaded ISO to the newly created VM.
Start the VM.

One challenge of correlating all of the attack stages together is the events for uploading an ISO are not associated with a VM, so a key component of detecting the attack chain is to first collect all of the VM-related activities (create, attach ISO, start) with the ISO upload events. To facilitate detection of this technique, we can leverage CQL to identify these VM-related activities, in addition to the ISO upload events, as shown in the query below.

#Vendor="vmware" #event.module="vcenter" (#event.dataset="vcenter.vpxd" OR #event.dataset="vcenter.vpxd-main")
    | #event.kind="event"    
    // Select and categorize events based on the stage of the  attack
    | case {
        #event.dataset="vcenter.vpxd" Vendor.message=/File\s+?upload\s+?to\s+?path/ Vendor.message=/completed\s+?with\s+?status\s+?'True'/ Vendor.message=/\.iso/i 
        | attack_stage := "upload_iso";        
        #event.dataset="vcenter.vpxd" Vendor.message=/vim\.event\.VmCreatedEvent/ 
        | attack_stage := "create_vm";
        #event.dataset="vcenter.vpxd" Vendor.message=/vim\.event\.VmStartingEvent/ 
        | attack_stage := "start_vm";
        #event.dataset="vcenter.vpxd-main" Vendor.message=/vim\.vm\.ConfigSpec/ Vendor.fileName=/\.iso/i Vendor.summary=/ISO/
        | attack_stage := "attach_iso";
    }
    | splitString(field=Vendor.fileName, by="\\/",index=-1, as=file_name)
    | vm_name := coalesce([Vendor.folder_name,Vendor.vm_name])
    | groupBy(field=[host.name,vm_name], function=collect([#Vendor,#event.module,event.category[0],attack_stage,file_name]))
    | case{
        // Look for VMs that exhibit 3 stages
        attack_stage=/create_vm/m attack_stage=/start_vm/m attack_stage=/attach_iso/m;
        // All ISO uploads. Note: ISO uploads are not connected to the VM.
        attack_stage=/upload_iso/m; 
    } 

    // Create individual events for each file name to assess the stages for each individual ISO file.
    | regex(field=file_name, regex="^(?<file_name>.+?)(\n|$)", repeat=true)    
    // Remove folder name of where the ISO was stored.
    | case {
        attack_stage=/upload_iso/m 
        | vm_name := "";
        *
    }
    // Group events based on iso file name
    | groupBy([host.name,file_name], function=collect([#Vendor,#type,event.category[0],attack_stage,vm_name]))
    | replace(regex="\\n",field=vm_name, replacement="", as=vm_name)
    // Look for ISO files that are present in all four stages of the attack
    | attack_stage=/create_vm/mi attack_stage=/start_vm/mi attack_stage=/attach_iso/mi attack_stage=/upload_iso/mi
    | summary := format(format="A potential rogue VM (%s) was identified on vCenter Server (%s). It was created with recently uploaded ISO %s.",field=[vm_name,host.name,file_name])

VirtualGHOST: Rogue Virtual Machines

The rogue VM (VirtualGHOST) creation method involves an adversary deploying their own VMs directly on the hypervisor, which bypasses standard VM creation and registration methods. Any user that can SSH to ESXi, such as root or the vCenter service account vpxuser, can be used to deploy these VMs. The goal of this tactic is to bypass standard VMware logging and monitoring capabilities in order to maintain persistence within the environment. Spinning up rogue VMs allows an adversary to deploy a backdoor to the VM to establish command and control (C2) within the target environments.

Validation of rogue VMs often requires access to the virtual machine file system (VMFS) datastore the VMs are hosted on. To make matters worse, standard vCenter or ESXI inventories will not indicate the presence or status of these rogue VMs.

To execute this attack, the adversary would perform the following actions:

Access an ESXi host via SFTP
Create a directory on the VM datastore to house their VirtualGHOST
Upload their VM files including the VMX definition file and VMDKs (virtual disks) to their VM directory
Access the ESXi host via SSH
Start the rogue VM on ESXi using /bin/vmx -x {VMX_PATH} 2>/dev/null 0>/dev/null &
Optionally, the adversary creates persistence by modifying the RC boot script at /etc/rc.local.d/local.sh to add the VM start command /bin/vm -x {VMX_PATH} 2>/dev/null 0>/dev/null &

Figure 1 shows an example of a rogue VM being started on a compromised ESXi host.

Figure 1. An adversary starting the rogue VM from inside the ESXi host (click to open in new window)

Detecting VirtualGHOST

While a VirtualGHOST might not be visible in the vCenter inventories, there are several forensic artifacts that are left behind when executing the attack chain described above. Once again, we break down the attack by its individual stages.

Stage 1: Create a directory via SFTP

An example of a raw log denoting a created directory originating from the ESXi host may be seen below.

Figure 2. New directory operation shown within a raw ESXi log (click to open in new window)

#Vendor="vmware" #event.module="esxi"  #event.dataset="esxi.sftp-server" message=/mkdir/

Stage 2: Upload Individual VM files to this directory

Figure 3 shows an example of a raw log denoting multiple VM files being uploaded to a specific directory.

Figure 3. Raw logs of multiple VM files being uploaded to a directory (click to open in new window)

#Vendor="vmware" #event.module="esxi"   #event.dataset="esxi.sftp-server" message=/open/ message=/\.(vmdk|vmx|nvram)/ message=/WRITE/

Stage 3: SSH into the ESXi server

Figure 4 shows an example of a raw log showing a new SSH session opening within the ESXi server.

Figure 4. Raw log of a new SSH session being opened (click to open in new window)

We may identify this newly spawned session using this query:

#Vendor="vmware" #event.module="esxi"   #event.dataset="esxi.sftp-server" message=/open/ message=/\.(vmdk|vmx|nvram)/ message=/WRITE/

Stage 4: Rogue VM started via vmx command

Finally, in this fourth stage, we may observe a rogue VM being started, as shown in Figure 5.

Figure 5. Raw log of a rogue VM being started (click to open in new window)

Using similar techniques as before, we can capture this activity through the following query:

#Vendor="vmware" #event.module="esxi"   #event.dataset="esxi.shell" message=/vmx\s+?-x/

Finally, using all of these separate queries and techniques, we are able to put everything together and create a detection for the full attack path as shown in the rule logic below:

#Vendor="vmware" #event.module="esxi" 
| case {
    // Create VM Directory
    #event.dataset="esxi.sftp-server" message=/mkdir/
    | attack_stage := "create_directory";
    
    // Add VM Files to Directory
    #event.dataset="esxi.sftp-server" message=/open/ message=/\.(vmdk|vmx|nvram)/ message=/WRITE/
    | attack_stage := "upload_vm_files_via_sftp";
    
    //SSH Into ESXi Host
    #event.dataset="esxi.sshd" message=/pam_unix/ message=/sshd:session/ message=/session\s+?opened\s+?for\s+user/ 
    | attack_stage := "ssh_into_esxi_host";
    
    //Start the VM
    #event.dataset="esxi.shell" message=/vmx\s+?-x/ 
    | attack_stage := "start_rogue_vm";   
}
| initiating_user := coalesce([user.name,ssh_user])
| groupby(field=[host.name,folder_name], function=collect([attack_stage,initiating_user,folder_name,vm_file_name_root]))
| case {
    attack_stage=/create_directory/m attack_stage=/upload_vm_files_via_sftp/m attack_stage=/start_rogue_vm/m 
    | activity_cluster := "vm_actions";
    attack_stage=/ssh_into_esxi_host/m 
    | activity_cluster := "logon_actions" ;
}
| groupBy([host.name,initiating_user], function=collect([activity_cluster,attack_stage,folder_name,vm_file_name_root]))
| activity_cluster=/logon_actions/m activity_cluster=/vm_actions/m

Figure 6. A correlation rule detecting rogue VM creation within an organization (click to open in new window)

Domain Controller Hijacking

With elevated access to vCenter, adversaries will try not only to persist within the environment but also to achieve objectives such as credential access or data exfiltration against critical infrastructure. With more critical systems — such as Active Directory domain controllers (DCs), databases, file servers, and more — becoming virtualized, adversaries can target these sensitive systems through the VM virtual disks within their vCenter access.

A common attack target is a DC's NTDS.dit database, containing the domain NTLM hashes and other sensitive data. To access the NTDS.dit of a virtual DC, adversaries will generally create a VM prior and use the VM to mount the virtual disk of the DC. The adversary could then use tools like Impacket to dump the credentials stored therein.

In order to create a VM, an adversary would likely have elevated access to vCenter. After this VM is created, the adversary could use the UI search functionality to find a virtual DC by looking for common naming schemes such as "DC." The adversary would subsequently shut down the target DC, then reconfigure their VM to attack the DC VMDK. With the attached VMDK, the adversary could use tools like secretsdump.py to dump the credentials from the DC.

An example of these operations within a vCenter environment can be seen in Figures 7 and 8.

Figure 7. An adversary using vCenter GUI to steal the hard-disk image of the targeted DC (click to open in new window)

Figure 8. An adversary taking the DC’s VMDK file and assigning it to a rogue VM so the adversary can steal secrets from the DC’s NTDS.dit database (click to open in new window)

Detecting DC Hijacking

To detect domain controller hijacking, we again break the attack into stages. First, it’s crucial to have a list, or pattern of DC VM names, to successfully detect the activity. Naming patterns are unique to an organization, so customization is required for this.

Stage 1: A DC VM is shut down

Figure 9 shows raw logs within vCenter, indicating when a DC VM is shut down.

Figure 9. Raw logs of VMs being shut down (click to open in new window)

This activity can be observed using the following query, which will target these specific logs using various regular expressions:

#Vendor="vmware" #event.module="vcenter" 
| #event.kind="event"
#event.dataset="vcenter.vpxd" Vendor.message=/vim\.event\.VmPoweredOffEvent/
// Add Domain Controller naming patterns below
| Vendor.vm_name=/dc/i

Stage 2: The VMDK file for the DC is attached to a different VM

In the second stage of the attack, we may target instances when a DC VMDK file is attached to a different VM that does not match the known DC naming patterns, as shown in Figure 10.

Figure 10. Raw logs of VMDK being attached to a different VM (click to open in new window)

#Vendor="vmware" #event.module="vcenter" 
| #event.kind="event"
#event.dataset="vcenter.vpxd-main" Vendor.message=/vim\.vm\.ConfigSpec/ Vendor.message=/Applying ConfigSpec/i Vendor.operation="add" Vendor.fileName=/\.vmdk/i
// Add Domain Controller naming patterns below
| Vendor.folder_name!=/dc/i

Finally, we can again observe this activity taking place through the query below, which may be leveraged as a rule in Falcon Next-Gen SIEM:

#Vendor="vmware" #event.module="vcenter" 
    | #event.kind="event"
    | case {
        #event.dataset="vcenter.vpxd" Vendor.message=/vim\.event\.VmPoweredOffEvent/
        // Add Domain Controller naming patterns below
        | Vendor.vm_name=/dc/i
        | original_vm_name := Vendor.vm_name
        | attack_stage := "vm_power_off";
        #event.dataset="vcenter.vpxd-main" Vendor.message=/vim\.vm\.ConfigSpec/ Vendor.message=/Applying ConfigSpec/i Vendor.operation="add" Vendor.fileName=/\.vmdk/i
        // Add Domain Controller naming patterns below
        | Vendor.folder_name!=/dc/i
        | suspicious_vm := Vendor.folder_name
        | attack_stage := "attach_disk";
    }
    | groupBy([host.name, Vendor.original_vm_name], function=collect([#Vendor,#event.module,event.category[0],attack_stage,
suspicious_vm,original_vm_name,Vendor.fileName]))
    | attack_stage=/vm_power_off/m attack_stage=/attach_disk/m
    | summary:=format(format="The VMDK file %s of potential Domain Controller (%s) was attached to VM (%s)", field=[Vendor.fileName,original_vm_name,suspicious_vm])

Figure 11. A correlation rule detecting malicious activities targeting DCs within vCenter (click to open in new window)

To help further safeguard enterprises from vCenter and ESXi attacks, the following rule templates have been created to help protect vCenter and ESXi instances:

VMware - ESXi - Local Account Created
VMware - ESXi - Lockdown Mode Disabled
VMware - ESXi - New IP for SSH Login Detected
VMware - ESXi - Potential Unauthorized VMFS Access via SFTP
VMware - ESXi - Rogue VM Creation
VMware - ESXi - Root Account Password Changed
VMware - ESXi - SSH Access Firewall Configuration Changed
VMware - ESXi - System Binary Rename
VMware - ESXi - Teleport Usage
VMware - ESXi - Unusual vpxuser Service Account Logon Source
VMware - ESXi - Virtual Machine Created with Recently Uploaded ISO
VMware - ESXi - vpxuser Service Account Failed Login
VMware - ESXi - wget LOLBIN Usage
VMware - vCenter - Bash Shell Enabled
VMware - vCenter - Distributed Switch Attached and Removed from Virtual Machine
VMware - vCenter - Domain Controller Hijack
VMware - vCenter - Excessive UI Searches in Short Period
VMware - vCenter - Potential JSP Web Shell
VMware - vCenter - Root Password Change
VMware - vCenter - Sensitive Resource Search
VMware - vCenter - Virtual Machine Created with Recently Uploaded ISO

Additionally, for better visibility into your ESXi environment, the following dashboards are available in the Falcon Next-Gen SIEM Dashboards page:

VMware - ESXi - Overview
VMware - ESXi - Entity Investigation

How to Forward vCenter Logs to Falcon Next-Gen SIEM

In today's complex cybersecurity landscape, effectively monitoring and analyzing logs from critical infrastructure components like VMware vCenter is paramount. Below is a high-level overview of steps required to send vCenter logs to Falcon Next-Gen SIEM.

Configuring vCenter to send logs via syslog to a centralized log aggregator: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-monitoring-and-performance-8-0.html
Setting up and optimizing the CrowdStrike Falcon LogScale Collector, a powerful tool designed to ingest and process logs from various sources. https://www.crowdstrike.com/tech-hub/ng-siem/harness-falcon-log-collector-for-seamless-third-party-data-collection/
Creating a HTTP Event Collector (HEC) connector, on the Falcon Console. https://falcon.us-2.crowdstrike.com/documentation/page/bdded008/hec-http-event-connector-guide
Assigning the recently released vCenter parser to the HEC connector, ensuring incoming vCenter logs are accurately parsed and normalized for effective analysis within Falcon Next-Gen SIEM. https://falcon.us-2.crowdstrike.com/documentation/page/a76b8289/data-connectors#v43a2825

CrowdStrike’s newest vCenter parser, in combination with our ESXi protections, strengthens protection against vCenter and ESXi attacks. CrowdStrike Falcon Next-Gen SIEM is helpful in defending enterprises against vCenter attacks and alerting them when adversaries attempt to exploit these systems in their environments.

When are attacks truly driven by AI?
February 25, 2026 0

Dell PowerEdge R770 Review A Fluid New 2U Server
February 18, 2026 0
Scalar Tape Storage
February 15, 2026 0
Why Certification Has Become a Strategic Control for CISOs
February 15, 2026 0

Oracle Launches First-of-its-Kind Defense Ecosystem to Redefine National Security Innovation

GerriScary Hacking the Supply Chain of Popular Google Products

How Falcon Next-Gen SIEM Protects Enterprises from VMware vCenter Attacks

Attacks Seen in the Wild

Bring Your Own (BYO) ISO Persistence

Detecting BYO ISOs

Detecting VirtualGHOST

Domain Controller Hijacking

Detecting DC Hijacking

How to Forward vCenter Logs to Falcon Next-Gen SIEM

Related Posts

When are attacks truly driven by AI?

Dell PowerEdge R770 Review A Fluid New 2U Server

Scalar Tape Storage

Why Certification Has Become a Strategic Control for CISOs