AI-Driven Cloud Defense Lessons from WARP PANDA

Most companies still treat VMware and cloud identity like “infrastructure plumbing”—set it up, patch occasionally, and assume your endpoint tools will catch anything serious.

WARP PANDA is what happens when that assumption meets a patient, technically sharp adversary. This China-nexus intrusion set has been observed targeting VMware vCenter/ESXi environments and then extending access into Microsoft 365 and Azure using stealthy tunneling, token replay, and cloud API enumeration. The tactics are engineered for long-term, low-noise persistence—the kind that slips past rule-based detection.

This post is part of our AI in Cybersecurity series, and I’ll take a clear stance: if your cloud and virtualization security strategy isn’t built around AI-driven threat detection and response, you’re betting your environment against an adversary that doesn’t need malware on laptops to win.

What WARP PANDA teaches us about modern cloud intrusions

WARP PANDA’s playbook shows a shift that’s now common in high-end intrusions: the control plane is the target. Once an attacker owns vCenter or cloud identity, they can operate “above” many traditional security controls.

CrowdStrike reports WARP PANDA intrusions against U.S.-based legal, technology, and manufacturing organizations, with some access dating back to late 2023. That dwell time is the headline. Long access usually means one of two things: the victim can’t see them, or can’t prove they’re gone.

A few behaviors matter because they’re repeatable patterns defenders can hunt:

• Pivoting from edge devices to vCenter (via valid credentials or vCenter vulnerabilities)
• Lateral movement over SSH, including suspicious use of the privileged vpxuser account
• Stealth tradecraft like log clearing and timestomping
• “Run a virtual instance” abuse: creating unregistered VMs, using them briefly, then shutting them down
• Data staging from VM snapshots using ESXi-compatible tooling (e.g., 7-Zip builds that run in those environments)

Here’s the uncomfortable truth: these techniques don’t need flashy malware or noisy ransomware. They rely on “normal” admin paths, in places where logging is inconsistent and ownership is split across infrastructure, cloud, and security teams.

The technical pattern: control-plane persistence + covert tunnels

The most useful way to think about WARP PANDA is not “a malware family” but a persistence-and-transport system spanning hypervisor, management plane, and cloud.

BRICKSTORM: blending into vCenter processes

BRICKSTORM is a Golang backdoor that can masquerade as legitimate vCenter processes (examples reported include updatemgr and vami-http). Its core value to an operator is simple: remote access and traffic tunneling from highly trusted infrastructure.

Notably, BRICKSTORM’s communications have been observed using:

• WebSockets over TLS
• DNS-over-HTTPS (DoH) to resolve C2 domains
• Nested TLS approaches to make inspection harder
• Public cloud / serverless infrastructure (for example, common “rentable” platforms that defenders hesitate to block broadly)

This is why purely signature-based controls struggle: even if you block one indicator, the operator can rotate domains or infrastructure quickly.

Junction + GuestConduit: hypervisor-to-guest tunneling

WARP PANDA also deployed ESXi- and guest-focused implants:

• Junction: an ESXi implant that listens on port 8090 (a port also used by a legitimate VMware service, vvold). It supports command execution, proxying, and communication with guest VMs via VSOCK.
• GuestConduit: a guest VM tunneling implant that establishes a VSOCK listener on port 5555 and forwards/mirrors traffic (appearing designed to pair with Junction).

This pairing is a big deal operationally: it enables east-west movement and covert routing inside virtualized estates, where many organizations still lack strong network visibility.

If your detection strategy assumes “compromises start on endpoints,” hypervisor-centric tunneling will keep embarrassing you.

Why AI-driven threat detection matters against stealthy actors

AI-driven threat detection is valuable here for one reason: the best signals are behavioral, not static. WARP PANDA’s tactics are built to mutate infrastructure and identifiers while keeping the operator workflow consistent.

What AI is good at (when implemented well) is correlating weak signals across domains:

• A vCenter process name that looks legitimate, but behaves oddly
• An ESXi host initiating outbound connections that don’t match its baseline
• A sudden appearance of VSOCK communication patterns that your environment never uses
• Session replay into Microsoft 365 that bypasses “normal” authentication flows
• A service principal enumeration burst via Microsoft Graph API that doesn’t fit the user’s role

Where classic detections break

Many SOCs still rely on:

• IOC matches (hashes, IPs)
• Threshold alerts (too many failed logins)
• Known-bad domain lists

WARP PANDA’s approach attacks those assumptions:

• Long dwell time means they can wait out noisy windows.
• DoH + TLS + proxying reduces visibility in network controls.
• Serverless/CSP infrastructure creates “block collateral damage” hesitation.
• Valid accounts and tokens reduce the obvious “malware” footprint.

What “AI” should actually do in this scenario

You don’t need sci-fi autonomy. You need three practical capabilities:

1. Entity behavior baselining for vCenter/ESXi assets and privileged accounts
2. Cross-layer correlation across virtualization logs, identity logs, and network telemetry
3. Fast triage summarization so analysts can act on a coherent storyline, not 200 alerts

If your tool claims AI but can’t answer “what changed, compared to normal, and why do we care,” it won’t help against an actor optimized for stealth.

A defender’s checklist: detections and hardening that actually map to WARP PANDA

The goal isn’t to memorize one adversary. The goal is to harden the specific seams WARP PANDA exploited: edge → vCenter → ESXi/guest → cloud identity and data.

1) Treat vCenter/ESXi as Tier-0 systems

Start with a strict security posture for virtualization management:

• Restrict outbound internet access from ESXi and vCenter wherever possible.
• Implement network segmentation and firewall controls on ESXi management interfaces.
• Forward vSphere syslog to an external platform and retain it long enough to investigate multi-month intrusions.
• Consider disabling SSH on ESXi hosts; if you can’t, heavily restrict it.

Practical stance: if vCenter can browse the internet freely, you’ve handed an intruder a comfortable command relay.

2) Hunt for vpxuser misuse and suspicious SSH patterns

vpxuser is designed for vCenter-to-host management, not for humans.

Prioritize investigations for:

• Any interactive SSH activity involving vpxuser
• SSH authentication as root on ESXi
• New SSH keys or unusual SSH client fingerprints from management networks

AI-based anomaly detection shines here because the “right” threshold is environment-specific. In many estates, any vpxuser SSH is anomalous.

3) Detect “malicious VM” tactics: unregistered VMs and short-lived compute

WARP PANDA has been observed creating unregistered VMs (not visible in the normal inventory) and shutting them down after use.

Build detections around:

• Creation of VMs that never appear in the inventory
• Short-lived VM lifetimes paired with unusual network activity
• Snapshot operations followed by archive/extraction activity

This is also a governance issue: if nobody owns VM inventory integrity, attackers will.

4) Monitor nonstandard port usage on ESXi (including 8090) and VSOCK

Junction’s choice of port 8090 is a reminder that “optional service ports” become hiding places.

Recommended actions:

• Baseline ESXi listening services; alert on new listeners.
• Flag unexpected traffic on 8090 in ESXi management contexts.
• If you can capture it, monitor VSOCK usage—most organizations have little legitimate need for it at scale.

5) Cloud: detect token replay and Graph API reconnaissance

WARP PANDA’s cloud activity matters because it turns a virtualization compromise into an organization-wide data access event.

Detection ideas that map to real operations:

• Session token anomalies (new device signatures without interactive login patterns)
• Sudden access to SharePoint/OneDrive collections outside a user’s normal scope
• Microsoft Graph API enumeration spikes: service principals, directory roles, application lists, mailbox enumeration
• New MFA device registrations that occur soon after a suspicious login

If you only look for “impossible travel” and password spray, you’ll miss token-based intrusion paths.

“People also ask” answers (for teams building an AI security roadmap)

How does AI detect stealthy cloud threats better than rules?

AI performs better when the threat is behavioral: unusual admin workflows, new communication paths, abnormal token usage, and cross-system sequences that rules rarely capture cleanly.

What telemetry is essential to catch attacks like WARP PANDA?

At minimum: vCenter/ESXi syslog, identity logs (MFA events, token activity), Microsoft 365 audit logs, and network flow/DNS visibility from management networks.

What’s the fastest way to reduce risk in 30 days?

Lock down outbound access from vCenter/ESXi, enforce MFA via federation for vCenter access, restrict or disable SSH, and centralize logging with retention long enough to investigate multi-month activity.

Next steps: make AI a force multiplier, not a dashboard feature

WARP PANDA is a case study in why AI in cybersecurity can’t be bolted on as a reporting layer. The environments under pressure—vCenter, ESXi, cloud identity, Microsoft 365—produce signals that only become meaningful when you correlate them across systems and time.

If you want a practical north star, use this one: assume the attacker will obtain valid access and then hide in “normal admin” behavior. Your job is to make that behavior measurable, baseline-able, and actionable.

Where do you feel the biggest visibility gap right now—virtualization management, cloud identity, or east-west traffic inside your VM estate?