Baselines and Reality at the ESXi Layer

Virtualization security is often split into two uncomfortable extremes:

Hardening guides that assume perfect prevention
Incident reports that start after everything already went wrong

This blog series exists to close that gap.

Using the VMware vSphere Security Configuration & Hardening Guide (SCG) and the LOLESXi Project, this series looks at ESXi security the way it actually works in practice:

what attackers can do after access exists
what defenders can realistically harden before that point
and why neither view is sufficient on its own

This is not a compliance walkthrough.
It is not an offensive tutorial.

It is a defender-focused look at the hypervisor, grounded in real capabilities, real tradeoffs, and operational reality.

How This Series Is Structured

Each post is standalone, but together they form a deliberate progression:

Post-compromise reality – what ESXi allows once access exists
Preventive baselines – how configuration reduces risk
Integration – why configuration and behavior must be understood together

This page combines the series introduction with Part 1.

Part 1

LOLESXi – Living Off The Land on ESXi

VMware ESXi is often treated as an appliance.
Installed once, hardened once, and then mentally removed from the threat model.

That assumption is no longer safe.

The LOLESXi Project exists to challenge it – not with exploits, not with malware, but by documenting what ESXi already allows after access exists.

This series deliberately starts after prevention has failed.

Why This Series Starts Here

Most security guidance focuses on preventing access.
That matters – but it is not sufficient.

LOLESXi begins with a different assumption:

An attacker has already reached the ESXi shell or API.

What happens next is rarely discussed, poorly monitored, and often misunderstood.

What LOLESXi Is About

LOLESXi stands for Living Off The Land ESXi.

The project catalogs:

native ESXi binaries,
built-in administrative commands,
and legitimate tooling present on every host.

There is no guidance on initial access.
That omission is intentional.

LOLESXi focuses exclusively on post-compromise capability – what is possible using only what ESXi already provides.

Why Living Off The Land Works on ESXi

Living Off The Land techniques rely on:

trusted binaries,
legitimate workflows,
minimal behavioral noise.

ESXi is especially susceptible because:

administrative access is rare but absolute,
logging is limited by default,
and hypervisors are rarely behavior-monitored.

From a defender’s point of view, malicious activity often looks indistinguishable from routine administration.

🔍 Detection idea

If your detection strategy relies on “unknown binaries” or “malware signatures”, it will fail on ESXi.
Detection must focus on behavior, timing, and intent – not tooling.

Native Tools, Platform-Level Impact

Using only built-in ESXi tooling such as:

esxcli
vim-cmd
vmkfstools
vm-support

an attacker can:

enumerate hosts and virtual machines
power off or delete workloads
destroy or exfiltrate virtual disks
reduce or eliminate forensic visibility

No exploit.
No dropped binaries.
No payload.

This is not guest-level impact – it is infrastructure-level failure.

What This Looks Like From a Logging Perspective

This is where most teams get it wrong.

`esxcli`

Used for system, network, storage, and service manipulation.

Detection ideas:

Alert on interactive esxcli usage outside maintenance windows
Flag esxcli system maintenanceMode set, network firewall, or storage changes without change tickets
Correlate esxcli execution with non-vCenter session sources

`vim-cmd`

Controls VM lifecycle and configuration.

Detection ideas:

Monitor for VM power-off, unregister, or destroy actions not initiated via vCenter
Alert on bursts of vim-cmd vmsvc/power.off or vmsvc/destroy
Correlate VM lifecycle changes with direct host access instead of vCenter APIs

`vmkfstools`

Direct access to virtual disks.

Detection ideas:

Alert on unexpected VMDK clone, zero, or delete operations
Watch for vmkfstools usage outside backup windows
Flag large VMDK operations without corresponding backup job context

`vm-support`

Often overlooked – and dangerous.

Detection ideas:

Alert on manual invocation of vm-support
Treat unexpected support bundle creation as potential reconnaissance or data staging
Monitor output locations and timestamps, not just execution

Timing Is a Signal

Most ESXi environments have:

predictable maintenance windows,
tightly scoped admin access,
very low interactive shell usage.

🔍 Detection idea

Time-based anomalies matter more than command content.

Examples:

ESXi shell usage at 02:00 with no change window
Multiple destructive commands in rapid succession
Admin actions immediately followed by log access or bundle creation

These are weak signals individually, but strong together.

What This Means for Defenders

LOLESXi is not a vulnerability list.
It does not claim ESXi is insecure by default.

It is a behavior reference.

It teaches you:

which native actions matter,
where intent hides behind legitimacy,
and why post-compromise ESXi activity must be treated differently than guest OS activity.

If you don’t understand these behaviors:

you won’t detect them,
you won’t investigate them correctly,
and you may mistake compromise for administration.

Where the Series Goes Next

LOLESXi assumes the worst-case scenario:
access already exists.

Most environments, however, fail before that point – through weak or inconsistent configuration.

The next article shifts focus from attacker behavior to defensive baselines:

👉 Part 2: Understanding the VMware vSphere Security Configuration & Hardening Guide (v9.0) (coming soon..)
→ how VMware defines reasonable minimum security
→ why priorities exist
→ and how hardening is meant to be automated, not memorized

After that:

👉 Part 3: SCG vs. LOLESXi – Configuration Baselines vs. Post-Compromise Reality (coming soon..)