
A single compromised host can lead to tenant‑wide takeover, exposing critical workloads and demanding stronger zero‑trust safeguards.
The Windows Admin Center (WAC) Azure single sign‑on flow was designed to pair a role‑based WAC.CheckAccess token with a proof‑of‑possession (PoP) token, theoretically preventing token replay attacks. In practice, researchers discovered that WAC failed to tightly bind these tokens, omitting critical user‑principal‑name checks and allowing cross‑tenant PoP tokens. This oversight creates a scenario where an attacker who already controls a single managed machine can stitch together a stolen access token with a fabricated PoP token, effectively masquerading as any privileged user within the tenant.
Exploitation requires two conditions: local administrator access on a WAC‑enabled VM or Arc‑connected device, and a privileged user initiating a WAC session via the Azure portal during the attacker’s window. Once triggered, the attacker can execute remote commands, move laterally across Azure virtual machines, and compromise Arc‑connected resources without presenting valid Azure credentials. The vulnerability’s breadth stems from the overly permissive scope of the WAC.CheckAccess token, which, unlike typical scoped tokens, can be reused across multiple hosts, turning a single weak link into a tenant‑wide breach vector.
Microsoft’s response includes a patch bundled in Windows Admin Center Azure Extension version 0.70.00, which tightens token validation, enforces UPN matching, and restricts PoP usage to gateway URLs. Organizations should prioritize this update, apply least‑privilege principles, leverage Privileged Identity Management, enforce multi‑factor authentication, and isolate WAC servers in dedicated subnets. Monitoring for anomalous token activity and restricting port 6516 traffic further reduces attack surface, aligning with a zero‑trust model that assumes breach and limits impact.
Comments
Want to join the conversation?
Loading comments...