SCG vs. LOLESXi – Configuration Baselines vs. Post-Compromise Reality

Part 3

In Part 1, we looked at post-compromise reality on ESXi.
In Part 2, we stepped back to understand defensive baselines defined by VMware’s Security Configuration & Hardening Guide.

This final post connects both perspectives – and explains why neither works on its own.

Two Projects, One Platform, Different Questions

The VMware vSphere Security Configuration & Hardening Guide and the LOLESXi Project are often mentioned together – sometimes even treated as alternatives.

They are not.

They answer different questions at different stages of the attack lifecycle.

SCG asks: How should ESXi and vCenter be configured?
LOLESXi asks: What can be done once that configuration is bypassed?

One is preventive.
The other is descriptive.

Where the SCG Ends

The SCG focuses on:

supported configuration states,
reduced attack surface,
sane defaults,
and auditable security controls.

Its strength is before compromise.

The guide deliberately stops at:

configuration,
product capabilities,
and supported behavior.

It does not attempt to model attacker intent – and it shouldn’t.

🔍 Detection idea

SCG controls define expected state.
Any silent deviation from that state is a signal – especially on P0 controls.

Where LOLESXi Begins

LOLESXi starts where most guides stop.

It assumes:

Access already exists.

From there, it documents how:

native ESXi binaries,
legitimate administrative workflows,
and trusted tooling

can be used for destructive or evasive actions – without exploits or malware.

🔍 Detection idea

Once access exists, tool legitimacy is irrelevant.
Only behavior, timing, and sequence matter.

The False Choice Many Teams Make

A common failure pattern looks like this:

Teams that rely only on hardening assume compromise won’t happen
Teams that focus only on post-compromise assume prevention is futile

Both are wrong.

Hardening without post-compromise awareness creates blind spots.
Post-compromise knowledge without baselines creates inevitability.

How SCG and LOLESXi Complement Each Other

Used together, the two projects form a coherent defensive model:

SCG defines what “normal” looks like
LOLESXi defines what “dangerous” looks like anyway

This enables:

configuration drift detection,
behavioral monitoring on ESXi,
and context-aware incident response.

🔍 Detection idea

Most LOLESXi-style activity is preceded by SCG drift:

logging reduced,
access controls weakened,
services re-enabled.

Watch for weakening before destruction.

Detection Lives Between Configuration and Behavior

Effective ESXi detection does not live in one place.

It exists:

between baseline and deviation,
between admin action and timing,
between expected workflow and sequence.

Examples:

SCG drift followed by direct vim-cmd usage
ESXi shell access outside maintenance windows
Support bundles created immediately after config changes

Individually weak signals.
Together, strong indicators.

The Bigger Takeaway

The hypervisor is no longer “out of scope”.

Security at this layer becomes credible only when:

configuration baselines are enforced and
post-compromise behavior is understood.

The SCG lowers probability.
LOLESXi prepares you for consequences.

You need both.

Where This Series Ends

This series covered:

Post-compromise reality (LOLESXi)
Preventive baselines (SCG)
Why configuration and behavior must be treated together

This is the foundation.

What comes next is operationalization:

turning signals into alerts,
behaviors into playbooks,
and drift into detection.

References

🔗 LOLESXi Project:
https://lolesxi-project.github.io/LOLESXi/

🔗 VMware vSphere Security Configuration & Hardening Guide:
https://github.com/vmware/vcf-security-and-compliance-guidelines

hcidude's blog