AI Detection Lessons from WARP PANDA Cloud Intrusions

Most companies get VMware and Microsoft 365 security wrong in the same way: they treat them like “infrastructure,” not like high-value targets.

WARP PANDA—a newly tracked, China-nexus adversary—has been doing the opposite. Throughout 2025, incident responders observed intrusions where the actor targeted VMware vCenter and ESXi, used stealthy implants like BRICKSTORM, and then expanded into Azure and Microsoft 365 using techniques like session token replay and Graph API enumeration. The pattern is clear: this isn’t smash-and-grab. It’s long-term, covert access.

This post is part of our AI in Cybersecurity series, and WARP PANDA is a perfect case study. Not because AI is magic, but because the behaviors here—tunneling through “normal” processes, living inside virtualization layers, blending with admin traffic—are exactly where AI-based threat detection outperforms rules and signatures.

What WARP PANDA tells us about modern cloud intrusions

WARP PANDA’s playbook shows that the “new perimeter” is whatever your admins trust most: virtualization control planes and SaaS identities.

If you’re still thinking about cloud security as “secure the VMs,” you’re already behind. These intrusions focused on the systems that manage everything else:

• VMware vCenter (the control plane for clusters and ESXi hosts)
• ESXi hosts (where attackers can hide below traditional endpoint tooling)
• Guest VMs (used for tunneling and staging)
• Microsoft 365 data stores (OneDrive, SharePoint, Exchange)

The uncomfortable takeaway: once an adversary is operating inside your virtualization stack, they can create blind spots on demand. In some observed activity, the actor created malicious, unregistered VMs, used them briefly, then powered them off—leaving defenders to piece together fragments.

Why vCenter becomes the “domain controller” of the data center

vCenter has the keys to your kingdom: credentials, automation hooks, inventory, snapshots, management networks. The threat report notes the use of privileged access such as the vpxuser account for lateral movement.

Here’s what works in practice: treat vCenter and ESXi management like you treat Active Directory—segmented, logged, monitored, and assumed to be under constant attack.

The stealth mechanics: BRICKSTORM, Junction, and GuestConduit

These intrusions matter because the tooling is designed to look boring.

WARP PANDA deployed:

• BRICKSTORM (Golang backdoor, masquerading as legitimate vCenter processes like updatemgr or vami-http, capable of tunneling and file ops)
• Junction (ESXi implant that listens on port 8090, mimicking a legitimate VMware service)
• GuestConduit (guest VM tunneling implant that uses VSOCK port 5555 to bridge guest ↔ hypervisor communications)

This is an attacker building an internal transit system across layers: vCenter → ESXi → guest VM → cloud services.

Why AI-based threat detection matters more than signatures here

Signature-based detection struggles when:

• binaries masquerade as expected processes
• traffic rides over TLS, WebSockets, and nested encrypted channels
• DNS resolution uses DNS-over-HTTPS (DoH)
• command-and-control sits behind common infrastructure patterns (serverless fronting, cloud services)

AI detection doesn’t “solve encryption,” but it does something more practical: it flags the shape of behavior.

Examples of behavior that’s more detectable with machine learning and anomaly analytics:

• a vCenter server that suddenly behaves like a proxy
• an ESXi host initiating outbound sessions it never initiates during normal operations
• VSOCK activity that doesn’t match known operational baselines
• unusual port usage (like persistent listeners on 8090 in environments where you don’t expect it)

If you’ve ever tried to write deterministic rules for “vCenter being weird,” you already know the problem: normal varies across organizations. AI helps by modeling your normal.

Initial access and lateral movement: the “edge-to-control-plane” pipeline

WARP PANDA frequently gained initial access by exploiting internet-facing edge devices, then pivoted into vCenter using valid credentials or vCenter vulnerabilities.

The vulnerability mix is a reminder that attackers don’t care whether the weakness is in a VPN gateway, an ADC, or vCenter itself. They just need a foothold:

• Ivanti appliance exploit chains (authentication bypass → remote command execution)
• F5 BIG-IP authentication bypass
• Multiple vCenter vulnerabilities (including DCERPC implementation issues)

The AI angle: detecting “credentialed” abuse

A lot of security teams still over-index on malware detection. But the most valuable detections in these cases are often about identity and privilege misuse:

• SSH authentications as root on ESXi hosts
• Any SSH activity tied to vpxuser
• sudden bursts of SFTP between infrastructure nodes
• management accounts being used outside maintenance windows

AI-assisted identity analytics and UEBA-style models can reduce the noise here. The goal isn’t to alert on every admin action—it’s to flag admin actions that don’t fit the admin’s usual pattern.

One stance I’ll defend: if your vCenter environment can’t tell you “this is unusual for this admin,” you’re relying on luck.

Cloud persistence and Microsoft 365 access: where the real data sits

WARP PANDA’s cloud activity is the part that should pull executives into the conversation.

In late summer 2025, the actor leveraged access into Microsoft Azure environments to get to Microsoft 365 data, including OneDrive, SharePoint, and Exchange. In at least one scenario, they obtained user session tokens (likely from browser artifacts) and used session replay—tunneling traffic through implants—to access M365 services.

They also established persistence by registering a new MFA device via an Authenticator app code after signing into a user account.

Why this bypasses “strong MFA” in the real world

If you’re thinking “MFA would stop that,” here’s the nuance:

• session tokens can outlive a single MFA challenge
• attackers can replay sessions from “trusted” contexts
• adding a new MFA device turns one compromise into long-term access

This is where AI-driven cloud security monitoring earns its keep:

• spotting anomalous OAuth/app behavior
• detecting suspicious Graph API enumeration patterns
• correlating sign-in risk with impossible travel, device drift, or token anomalies
• identifying new MFA registrations that don’t match prior enrollment patterns

Practical stance: monitor MFA enrollment events like you monitor password resets. They’re that important.

A practical defense plan: where to apply AI, automation, and hardening

You don’t need a science project. You need a plan that assumes an APT will eventually touch your virtualization and cloud identity layers.

1) Put vCenter and ESXi on an “assume breach” monitoring tier

Start by treating virtualization logs as first-class security telemetry.

Do this:

• forward and retain ESXi and vCenter syslog to an external logging platform
• baseline normal admin access (who, from where, when)
• alert on high-risk actions (shell enablement, SSH usage, unusual service listeners)

AI helps most when it has consistent, high-quality telemetry. If logs are incomplete, the model will learn the wrong normal.

2) Detect tunneling and proxy behavior, not just known C2

WARP PANDA used tunneling through vCenter/ESXi/guest VMs to blend with legitimate traffic.

Hunt for:

• outbound connections from management networks to unusual destinations
• vCenter acting as a relay (many internal-to-external flows that don’t match baseline)
• spikes in encrypted web sessions from infrastructure nodes

This is a strong fit for AI-driven network anomaly detection because the signal is often “this host should never do this.”

3) Shut down the easy paths inside VMware

Hardening beats detection when the control is realistic.

High-value changes:

• disable or tightly restrict SSH to ESXi hosts
• enforce least-privilege local accounts for daily admin
• enable ESXi execInstalledOnly
• restrict outbound internet access from ESXi and vCenter
• segment ESXi management interfaces with strict firewall rules
• monitor and restrict nonstandard port usage (including 8090)

If you can only do one thing this quarter: segmentation for management interfaces. It reduces the attacker’s room to maneuver even if they get credentials.

4) Treat Microsoft 365 as a data lake with active adversaries

Because it is.

Do this:

• monitor for new MFA device registrations and enforce approvals where feasible
• detect abnormal Graph API usage (service principal enumeration, unusual directory role reads)
• alert on large SharePoint/OneDrive download patterns from new device fingerprints
• shorten token lifetimes and tighten conditional access for high-risk roles

AI-based threat detection is particularly useful here because “normal collaboration” varies wildly by department. Models that learn per-user and per-team behavior can reduce false positives while still catching mass collection.

5) Use automation to shrink attacker dwell time

WARP PANDA’s strength is patience and stealth. Your advantage needs to be speed.

Security automation ideas that consistently pay off:

1. Auto-quarantine suspicious infrastructure nodes from egress when tunneling indicators appear
2. Auto-disable newly added MFA methods pending verification for high-risk accounts
3. Auto-open incident workflows when vCenter/ESXi events correlate with unusual cloud sign-ins

Automation isn’t about replacing analysts. It’s about preventing “we’ll look at it Monday” from becoming “they’ve been here for six months.”

A useful rule: if an alert involves vCenter + outbound tunneling + cloud token anomalies, treat it as an incident until proven otherwise.

Questions security leaders should ask after reading about WARP PANDA

Direct questions beat generic roadmaps. Here are the ones I’d use in a leadership meeting:

• Can we prove which systems can SSH to ESXi hosts today?
• Do we alert on any vpxuser interactive usage (especially SSH)?
• Are vCenter and ESXi logs centrally retained for at least 90 days?
• Can we detect unregistered or unsanctioned VMs?
• Do we monitor MFA enrollment events and approve them for privileged roles?
• Can we correlate virtualization anomalies with Microsoft 365 access patterns?

If any of these are “we’re not sure,” that’s the work.

Where AI fits in the bigger “AI in Cybersecurity” story

The WARP PANDA case makes one thing obvious: attackers are building cross-layer operations—edge devices to virtualization to cloud identity to SaaS data. Point solutions don’t connect those dots well.

AI helps when it’s used for what it’s good at:

• correlating weak signals across domains (endpoint, identity, cloud, network)
• detecting anomalies against your specific baselines
• automating triage and response steps fast enough to matter

If your 2026 plan is “more rules,” you’re going to lose time—and time is the one resource an APT needs.

The next step is straightforward: pick one environment (vCenter + ESXi + Microsoft 365), define what “normal” looks like, then apply AI detection and response to the handful of behaviors that simply shouldn’t happen. What would you find if you ran that baseline next week?