WARP PANDA Shows Why AI Wins Against Quiet APTs

A single compromised vCenter server can quietly turn into an enterprise-wide visibility problem. Not because defenders aren’t logging. Not because teams don’t care. It’s because modern adversaries are getting better at living inside the infrastructure you least want to touch: hypervisors, management planes, and cloud identity.

CrowdStrike’s reporting on a newly tracked China-nexus adversary, WARP PANDA, is a clean example of where traditional “alert on malware” thinking falls apart. This actor isn’t trying to be loud. They’re aiming for persistent, covert access—the kind that survives reboots, blends into normal admin activity, and uses your own virtual and cloud plumbing as a transport layer.

This post is part of our AI in Cybersecurity series, and I’m taking a strong stance: APT defense in 2026 is a data-and-behavior problem, not a signature problem. AI-driven threat detection—paired with good telemetry—gives you a real shot at spotting what WARP PANDA is doing before it becomes a multi-quarter incident response saga.

What WARP PANDA gets right (and defenders often miss)

WARP PANDA’s playbook is optimized for stealth in virtualized and cloud environments. They target VMware vCenter and ESXi, pivot using privileged accounts, and tunnel traffic through places most organizations don’t baseline well.

From the public details, several themes stand out:

• Long dwell time: CrowdStrike observed intrusions where initial access dated back to late 2023, with activity continuing through 2025.
• Hypervisor-aware tradecraft: WARP PANDA deployed implants specific to ESXi hosts and guest VMs (including Junction and GuestConduit), plus web shells and BRICKSTORM.
• OPSEC discipline: Log clearing, timestomping, and even spinning up malicious, unregistered VMs that get shut down after use.
• Cloud follow-through: Azure and Microsoft 365 access (OneDrive, SharePoint, Exchange), including session token replay and Graph API enumeration.

Here’s why that matters: if your detection strategy depends on “known bad” indicators and workstation EDR alone, this actor can sit in the seams—between vCenter, ESXi, identity, and cloud audit trails.

The contrarian reality: vCenter is a crown jewel, but it’s treated like a utility

Most companies treat virtualization management like power or water: it should always be on, and only a few admins touch it. That mindset creates a blind spot.

Attackers know that:

• vCenter and ESXi logs often aren’t centrally monitored with urgency.
• “Weird” traffic from hypervisors doesn’t get the same scrutiny as weird traffic from endpoints.
• Admin actions can be a perfect disguise.

WARP PANDA abuses that gap by using VMware-adjacent implants, tunneling through management components, and moving laterally with accounts like vpxuser.

The technical story in plain English: how the intrusion works

The core chain is straightforward: compromise an edge device, pivot to vCenter, expand across ESXi and guests, then use tunnels to access cloud and exfiltrate data. The sophistication shows up in how quietly they execute it.

Initial access: edge devices and vCenter exploitation

WARP PANDA was observed exploiting multiple classes of vulnerabilities:

• Internet-facing edge devices (examples included Ivanti and F5)
• VMware vCenter vulnerabilities (multiple CVEs spanning years)

This is a reminder that “patching is table stakes” isn’t a slogan—it’s literally the front door.

Lateral movement: SSH and privileged VMware accounts

Once inside, WARP PANDA uses SSH and privileged access paths, including the native vCenter-managed account vpxuser.

That detail is operationally important: vpxuser exists for vCenter-to-host management. SSH activity using vpxuser should be treated as a high-priority investigation signal, because it implies someone is using a service-style account like a human operator.

Persistence and stealth: unregistered VMs, log clearing, timestomping

WARP PANDA reportedly created malicious VMs that were unregistered in vCenter, used them, then shut them down. That’s the kind of move that defeats simplistic “show me new VM inventory changes” checks.

They also used:

• Log clearing (reducing forensic fidelity)
• Timestomping (blending malicious files into older timelines)

These are classic defense evasion techniques, but deployed in a VMware-centric context where many SOCs have weaker detections.

Exfiltration staging: snapshots, VM disks, and 7-Zip

One of the more uncomfortable details: WARP PANDA staged data by extracting from thin-provisioned snapshots of live guest VMs using an ESXi-compatible 7-Zip. That’s not “steal a few files.” That’s “treat the virtual disk like a database.”

They also cloned domain controller VMs, likely to access the AD DS database. If you’re not watching for domain controller cloning, you’re assuming the most sensitive identity asset can’t be copied. In virtual environments, it can.

The malware angle: why these implants are built for cloud-era stealth

The malware described in the reporting is designed to hide in normal platform behavior—especially in virtual infrastructure and encrypted traffic. That’s exactly the detection problem AI is good at.

BRICKSTORM: tunneling and obfuscated C2

BRICKSTORM is a Golang backdoor that can masquerade as legitimate vCenter processes (examples included names like updatemgr and vami-http). It supports tunneling and file management.

The key operational detail is its communications approach:

• WebSockets over TLS
• DNS-over-HTTPS (DoH) for resolution
• Nested TLS channels
• Use of public cloud and edge platforms for command-and-control hosting

Even well-run networks struggle to “block C2” when C2 looks like normal encrypted web traffic and sits behind legitimate services.

Junction + GuestConduit: ESXi-to-guest tunneling using VSOCK

Junction and GuestConduit are described as Golang implants that use VSOCK (VM sockets) to communicate between hypervisors and guest VMs.

That’s a meaningful escalation in tradecraft because:

• VSOCK traffic is often under-monitored compared to normal TCP/IP flows.
• It enables host-to-guest communications paths that don’t look like standard lateral movement.
• It supports “tunnel through the virtualization layer” patterns that many SOC playbooks don’t even mention.

If your team’s detection content treats the hypervisor like a black box, this is the kind of tooling that lives there comfortably.

Where AI-driven threat detection changes the outcome

AI doesn’t magically stop an APT. It gives you earlier and more reliable signals that something’s off—especially when attackers mimic admin behavior. The reason WARP PANDA makes a good AI case study is that their success depends on defenders failing to connect weak signals across domains.

1) Behavior analytics beats “known bad” in management planes

When malware masquerades as legit processes, signatures and basic allowlists won’t save you. AI-driven threat detection can instead focus on behavior patterns such as:

• vCenter processes initiating unusual outbound connections
• New network tunnels originating from ESXi management networks
• Rare parent-child process relationships (even on Linux-like appliances)
• Changes in timing and frequency of admin actions

A practical rule of thumb I’ve seen work: baseline “quiet infrastructure” and alert on deviation, not volume. vCenter should be boring.

2) Cross-layer correlation is the real win

WARP PANDA blends hypervisor activity, identity abuse, and cloud access. Humans can correlate that—eventually. AI can do it continuously.

Correlations worth automating:

• SSH logins to ESXi + unusual outbound traffic shortly after
• vpxuser usage + VM snapshot activity + compressed archives staged
• Browser token theft indicators + immediate Microsoft 365 access from atypical paths
• Graph API enumeration that doesn’t match the user’s normal job role

This is where an AI-assisted SOC earns its keep: it reduces “time-to-suspicion.”

3) Cloud identity signals: session replay and MFA device registration

Two cloud behaviors described in the reporting should be treated as top-tier detection priorities:

• Session token replay (often following browser data access)
• New MFA device registration after an initial login

AI helps here by scoring identity events based on combinations: device posture, geo/ASN drift, impossible travel patterns, unusual API calls, and changes in access cadence.

Put simply: when attackers stop using passwords, you must stop detecting passwords.

A practical defense checklist (VMware + cloud) you can implement this quarter

You don’t need a perfect environment to raise the cost for WARP PANDA-style intrusions. You need disciplined controls and the right telemetry. Here’s a tight checklist grounded in the behaviors from the case.

VMware and virtualization controls

1. Centralize and retain ESXi and vCenter syslog outside the VMware stack.
2. Monitor for unregistered or unsanctioned VMs and treat them as incidents until proven otherwise.
3. Restrict outbound internet access from ESXi and vCenter (default-deny where possible).
4. Segment management networks and lock down ESXi management interfaces with strict firewall rules.
5. Reduce SSH exposure: disable SSH on ESXi where feasible; if not, enforce tight allowlists and strong monitoring.
6. Alert on vpxuser interactive usage, especially via SSH.
7. Watch nonstandard ports on ESXi (port 8090 is specifically relevant to the Junction masquerade pattern).
8. Enable execution controls like execInstalledOnly where supported.

Cloud and identity controls

1. Mandate MFA through an identity federation provider for vCenter access and administrative portals.
2. Detect new MFA device registrations and require step-up verification.
3. Hunt for token replay patterns: sudden Microsoft 365 access without typical interactive authentication signals.
4. Monitor Graph API usage (enumeration of users, roles, service principals, and mail access).
5. Rotate admin credentials and API keys on a schedule that matches your risk (quarterly is a common baseline; high-risk environments go monthly).

Detection engineering: what to measure (so AI can help)

AI is only as good as the signals you feed it. Prioritize telemetry that answers these questions:

• What is “normal” outbound traffic volume and destination profile for vCenter and ESXi?
• Which accounts normally touch virtualization management, and how often?
• How often do snapshots, clones, and exports occur—and who triggers them?
• Which users normally enumerate directory roles or download large SharePoint collections?

If you can’t answer those reliably, your incident response starts too late.

Snippet-worthy stance: If your hypervisor logs aren’t in your detection pipeline, you’re defending a modern enterprise with half a map.

What to do if you suspect WARP PANDA-style activity

Treat it as an intrusion in progress until proven otherwise. Long-dwell APT operations reward hesitation.

Immediate actions that tend to work:

• Isolate vCenter/ESXi management access paths (tighten firewall rules, restrict admin jump hosts).
• Force credential and token resets for suspected accounts (including revoking active sessions).
• Triage for tunneling: unusual outbound TLS/WebSocket patterns from virtualization components.
• Review VM events: new snapshots, clones (especially domain controllers), exports, and unexpected VM creation.
• Pull forensic images where possible before making sweeping changes that destroy evidence.

If your environment is large, this is where AI-assisted triage is more than convenience—it’s how you avoid drowning in “maybe relevant” logs.

The bigger lesson for AI in cybersecurity

WARP PANDA is a reminder that defenders aren’t losing because they’re careless. They’re losing because attackers are choosing control planes and identity layers where detection is hardest and where actions can be disguised as maintenance.

AI-driven threat detection fits this moment because it’s built for patterns across time and systems—the exact shape of a stealthy APT campaign in virtual and cloud environments.

If you’re responsible for security outcomes, here’s the question I’d pressure-test before the next audit cycle: can your team confidently detect suspicious behavior inside vCenter/ESXi and correlate it to cloud identity activity within hours—not weeks?