Ilan Kalendarov and Ben Zamir (Cymulate) attack the seam that most enterprises now depend on: the hybrid boundary between an Azure tenant and on-prem Windows. The old mental model, "cloud and on-prem are separate zones with a clear boundary", is obsolete, because a single management plane silently bridges both. Their case study is Windows Admin Center (WAC), Microsoft's browser-based tool for managing servers, on-prem and via Azure Arc. They found five vulnerabilities in it: a local privilege escalation from a world-writable ProgramData directory (on-prem CVE-2025-64669 and its cloud twin CVE-2026-23660), a tenant-wide RCE from mixing authorization and proof-of-possession tokens (CVE-2026-20965), an improper attestation flaw letting anyone obtain a valid WAC certificate for any device in any tenant, and a web chain of flow-redirection + XSS + insecure credential storage (CVE-2026-32196). Chained, they give bidirectional compromise: Azure→on-prem and on-prem→Azure, "one device to Global Admin." The defender lesson: treat management tools as Tier Zero, and hunt in identity/token behavior, because the compromise shows up there before any malware does.
Post 09 of my Black Hat Asia 2026 series. Analysis-first: the architecture, the flaw classes, the kill-chains at a conceptual level, and the detection guidance. No exploit code.
1. Why hybrid changes the threat model
The talk's framing is the most important part. In a hybrid estate:
- Old assumption: clear boundaries between cloud and on-prem, breach one, and the other is still a separate objective.
- Reality: one application session can control everything, because a hybrid management tool silently bridges both worlds. The boundary you're defending as if it exists has already been dissolved by the tool you deployed to make management convenient.
WAC is the exemplar: it operates through browser interfaces, gateway services, and Azure identity integration, and (via Azure Arc) reaches on-prem machines from the cloud. That makes it, in the researchers' words, an ideal pivot point, a single component that, if compromised, hands an attacker both estates.
2. The five flaws, by class
Each vulnerability is a familiar bug class, the danger is what they touch.
2.1 World-writable ProgramData → SYSTEM (CVE-2025-64669 / CVE-2026-23660)
WAC's C:\ProgramData\WindowsAdminCenter directory is writable by standard users. That improper access control violates the host's privilege boundary directly. A low-privileged user escalates to SYSTEM on any machine with WAC installed, via two documented paths: extension-uninstall abuse and updater DLL hijacking (planting a DLL the privileged updater loads). The cloud angle multiplies it: the Azure variant of WAC must be installed as an extension on every managed machine, so every Azure-Arc-managed machine running WAC is vulnerable to local privilege escalation. One misconfigured ACL becomes fleet-wide.
ProgramData subdirectory is a textbook finding. It matters enormously in this context because WAC runs as a privileged management agent on every managed host, so the same trivial LPE is present everywhere the management tool is, turning a local bug into a lateral-movement primitive across the whole estate.2.2 Token mixing → tenant-wide RCE (CVE-2026-20965)
This is the crown jewel. Azure WAC authenticates with a pair of tokens:
- a WAC.CheckAccess token, granting authorization to manage WAC, and
- a Proof-of-Possession (PoP) token, intended to bind the connection to a specific client.
The PoP token exists precisely to stop a stolen bearer token from being replayed by someone else, it's supposed to prove this client holds the key. The flaw: WAC doesn't properly validate the token pair. A CheckAccess token can be combined with an attacker-controlled PoP token, bypassing the identity and tenant validation the binding was meant to enforce. The consequence is stark: with a stolen CheckAccess token, an attacker gets administrative RCE on any WAC-managed device in the tenant. The binding control was present but not checked, so it provided no security at all.
2.3 Improper attestation → a valid cert for any device (unvalidated)
WAC uses an attestation service to issue a valid certificate, the attestation is supposed to verify the requesting endpoint is legitimate. But WAC certificate requests are not cryptographically validated. The result breaks the entire trust model: any unauthenticated user can obtain a valid WAC certificate for any device in any tenant. Once you can mint the identity the system trusts, downstream authorization decisions are meaningless.
2.4 Flow-redirection + XSS + insecure storage (CVE-2026-32196)
Both on-prem and Azure WAC carry a chain of web-app bugs:
- Flow-redirection: the application blindly follows an attacker-supplied gateway URL (a
gatewayUrlparameter), so an attacker can point the client's backend at a rogue server. - Response-based XSS: the WAC client is vulnerable to cross-site scripting in both variants, so attacker-controlled responses execute script in the management UI.
- Insecure credential storage (on-prem): credentials are stored in a recoverable way.
Flow-redirection is the glue: point the UI at a rogue WAC API server that impersonates the backend, and the XSS and token handling do the rest.
3. How they chain: both directions
Individually these are an LPE, an RCE, a trust-model break, and a web chain. Combined, trust boundaries collapse across environments in either direction.
Fig. 1 — The two kill-chains run opposite directions through the same tool. WAC is the hinge that makes "compromise one, own both" possible.
3.1 Kill Chain #1 — Azure → on-prem
Start as a low-privileged, non-admin user on an Azure VM that has WAC. (1) Exploit the world-writable-ProgramData LPE to become local admin/SYSTEM. (2) Use the improper token validation to impersonate the WAC backend / stand up a rogue WAC API server, giving RCE across Azure-Arc devices and other Azure VMs. (3) Pivot through jump servers into the on-prem network and abuse managed identities for tenant-level privilege escalation, ending in both on-prem network dominance and Azure tenant dominance.
3.2 Kill Chain #2 — on-prem → Azure
Start with low-privileged internal-network access. Enumerate identities, issue certificates (via the attestation flaw), and run an exploit loop: MitM / DNS-poison to capture tokens, impersonate, get RCE, enumerate new targets, repeat. That yields on-prem control (reach segments, control AD via terminal/jump servers) and tenant control (abuse managed identities, escalate, control the tenant). The slide's summary: "one device to Global Admin."
4. The defender's view: watch identity, not malware
The most useful part for blue teams is the detection guidance, because none of this is caught by endpoint malware detection, the whole chain is legitimate management operations performed with mis-validated trust. The compromise is visible first in identity behavior:
| Signal class | What to alert on |
|---|---|
| Unusual token / session behavior | Tokens reused across different resources or from new locations; identities performing high-risk operations without re-authentication; multiple different identities acting from the same IP/device |
| Hybrid boundary violations | Cloud identities accessing on-prem systems (or vice versa) in a pattern that never happened before (baseline deviation); jump-server access following cloud-only identity activity |
The three take-homes:
- Your hybrid management plane is an attack surface you're probably under-monitoring. WAC (or its equivalent) sits astride both estates; instrument it accordingly.
- One management tool + four CVEs = full bidirectional compromise. The blast radius of a management-tool bug is the union of everything it manages.
- Treat management tools as Tier Zero. Give them the same protection, isolation, and scrutiny as domain controllers and identity providers: monitor token usage and tighten their trust boundaries.
All five issues were responsibly disclosed to Microsoft (MSRC) and fixed between December 2025 and April 2026. The durable lesson outlives the specific CVEs: hybrid bridges are Tier-Zero infrastructure.
Is this only a WAC problem?
WAC is the case study, but the thesis is general: any tool that manages both cloud and on-prem, and holds credentials/tokens for both, is a bidirectional pivot. The classes of flaw (writable install dirs, unenforced token binding, unvalidated attestation, flow-redirection) recur across management products. Treat the category as Tier Zero, not just this product.
Why is the PoP-token flaw so serious?
Proof-of-Possession binding is the control that's supposed to make a stolen bearer token useless to a thief. If the server accepts a CheckAccess token paired with an attacker's PoP token, that protection evaporates and a stolen token becomes tenant-wide RCE. It's a control that was present but not validated.
How would I detect this if I couldn't patch immediately?
Focus on identity telemetry: token reuse across resources/locations, high-risk actions without re-auth, one device presenting multiple identities, and, most tellingly, cloud↔on-prem access patterns that deviate from baseline. Endpoint AV won't see it; identity analytics will.
Are the fixes enough?
The specific CVEs are fixed. The structural risk, that a single management plane bridges both estates, remains by design. The mitigation is architectural: isolate and monitor the management plane as Tier Zero, and minimize which identities/tokens it can hold.
Takeaways
- Hybrid dissolved the cloud/on-prem boundary. A single management tool bridges both, so one session can control everything.
- Five WAC flaws: writable-
ProgramDataLPE (×2, on-prem + cloud), PoP-token-mixing tenant-wide RCE, unvalidated attestation (cert for any device/tenant), and a flow-redirection + XSS + insecure-storage web chain. - They chain both ways, Azure→on-prem and on-prem→Azure, "one device to Global Admin."
- Recurring root cause: controls present but not validated (token binding, attestation, ACLs).
- Detect in identity/token behavior, not malware: token reuse, no-reauth high-risk ops, cross-boundary access anomalies.
- Treat management tools as Tier Zero, monitor their token usage and tighten their trust boundaries.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- MSRC — CVE-2026-20965 (WAC tenant-wide RCE) — the PoP-token validation flaw.
- MSRC — CVE-2025-64669 (WAC LPE) · CVE-2026-32196 (flow-redirection/XSS) — the other fixed issues.
- Cymulate research blog — the team's write-ups on hybrid attack techniques.
- Microsoft — Windows Admin Center overview — what WAC is and how it bridges Azure Arc and on-prem.
- Microsoft — Tier Zero / privileged access model — the framing for protecting management planes.