Chained Attacks on Windows Admin Center and Entra Tokens Threaten Tenants

A newly exposed cluster of identity and management-plane flaws has rewritten the threat model for Windows administrators and cloud tenants: an Entra ID “actor token” validation failure that could enable largely undetectable, cross‑tenant impersonation combined with a high‑impact local elevation‑of‑privilege in Windows Admin Center (WAC) means the classic separation between “endpoint compromise” and “tenant compromise” can be erased in a single chained attack. At the same time, major vendors are racing to position AI platforms for public‑sector use — SAS’s FedRAMP authorization for SAS Viya shows that cloud AI is moving fast into government workloads even as identity plumbing remains brittle. This article explains what happened, why it matters to Windows admins and cloud defenders, and what immediate steps organizations must take to avoid a tenant‑wide disaster.

Background​

Windows Admin Center is a widely deployed, browser‑based management surface for Windows servers and clusters. Because WAC commonly lives on jump boxes, bastions and management hosts it holds privileged context and credentials that an attacker can abuse if the host is compromised. Recent coordinated disclosures have identified multiple local elevation‑of‑privilege (EoP) weaknesses in WAC that allow a low‑privileged local user or process to escalate to SYSTEM or administrative privilege on the host. These flaws are not theoretical: independent researchers documented practical exploitation paths such as signed PowerShell uninstall script abuse and a time‑of‑check/time‑of‑use (TOCTOU) DLL hijacking against the WAC updater. Separately, an identity validation flaw in Microsoft Entra (Azure AD) involving so‑called “actor tokens” allowed these special service‑to‑service tokens to be accepted by legacy APIs in a way that could impersonate privileged accounts across tenants without clear audit records. The researcher who reported the issue demonstrated that actor tokens could be requested in one tenant and presented to another tenant’s endpoints, bypassing logging and Conditional Access checks — a pathway to silent tenant‑wide compromise if weaponized. Microsoft assigned a CVE and pushed mitigations, but the incident is a stark reminder that identity flows and legacy APIs are high‑leverage targets. Meanwhile, SAS announced FedRAMP Moderate authorization for SAS Viya (SAS AI and Analytics for Government), enabling federal agencies to deploy the platform in Microsoft Azure for analytical and AI use cases. That authorization broadens the attack surface of interest to defenders: more mission workloads are moving to managed AI services running on the same hyperscale clouds whose identity systems have recently shown dangerous fragility.

---

Why these two stories are not independent risks​

Management plane bugs become tenant risks when identity plumbing is weak​

Local EoP bugs like the WAC vulnerabilities matter far beyond a single host because management hosts often hold machine identities, stored tokens, certificates, and privileged automation hooks. A successful local escalation to SYSTEM on a WAC host can be used to:

• Read local machine certificates and keys.
• Call local metadata endpoints or agent APIs that issue machine‑assigned tokens.
• Install malicious extensions or agents that automatically rotate across managed systems.
• Harvest credentials or service principal secrets used in automation.

If an attacker can obtain valid tokens (machine tokens, delegated tokens, or service‑to‑service tokens), and if identity infrastructure accepts or mis‑validates tokens across tenant boundaries, then a local host compromise can escalate into a silent tenant compromise. That is exactly the cross‑plane amplification security analysts warn about: an endpoint exploit → token theft → control-plane API abuse.

Actor tokens: why “invisible” tokens are so dangerous​

“Actor tokens” are special tokens used internally in complex cloud service communications. They were designed for controlled, backend impersonation scenarios — but the absence of strict issuer/audience validation, combined with logging blind spots, transforms them into a powerful weapon.
Key properties that raised alarm:

• Actor tokens could be requested in one tenant and presented to APIs governing another tenant.
• Use of these tokens was not always visible in the normal tenant audit logs, creating stealth.
• The tokens bypassed Conditional Access and other tenant‑level policy controls in some legacy API paths.

That combination — uncontrollable token issuance plus insufficient verification and poor telemetry — is a recipe for tenant‑wide compromise if an attacker can obtain or forge such tokens. Microsoft has mitigated the specific issue through an emergency update path, but the architectural lesson endures: identity is the crown jewel; when identity validation fails, perimeter controls mean very little.

---

Deep dive: the Windows Admin Center EoP findings​

Two practical exploit paths researchers reproduced​

Independent labs that analyzed the WAC codebase and behavior reported two reliable exploitation classes:

• Extension uninstall / signed PowerShell abuse: WAC’s uninstall mechanism enumerated and executed signed PowerShell scripts located in a writable uninstall folder under C:\ProgramData\WindowsAdminCenter. If directory ACLs are permissive, an attacker can place a signed script or find a signed script to reuse and cause privileged code execution during uninstall. This results in elevated execution context and SYSTEM‑level operations.
• Updater TOCTOU and DLL hijack: The updater process performed signature or integrity checks in one context and then launched an updater executable that loaded DLLs from a directory that could be replaced in the small window between check and use. A time‑of‑check/time‑of‑use race lets a low‑privilege user drop a DLL that the updater loads under SYSTEM, achieving full host compromise.

Both techniques exploit WAC’s trust in artifacts placed in shared, writable directories and underscore the operational importance of filesystem ACLs, atomic validation, and strict separation for installer/updater contexts. A confirmed vendor advisory and assigned CVE(s) validate the issue class and severity.

Why WAC on jump hosts is an especially bad place for this bug​

Management stations and jump hosts are prime targets because they:

• Store or escrow credentials and tokens for multiple systems.
• Serve as the control point for automation and deployment (patching, configuration management).
• Are trusted by other systems and automation tooling — meaning malicious changes there are often accepted without second thought.

When WAC is compromised, an attacker can leverage the host’s privileged role to move laterally, extract machine or tenant tokens, and then attack the cloud control plane. The WAC EoP is not just a host problem; it is a management‑plane emergency.

---

The chain: how a local WAC exploit can become a tenant compromise​

• Initial foothold: attacker obtains low‑privileged local access to a machine that hosts WAC (phishing, malicious installer, vulnerable service).
• Local EoP: attacker exploits WAC CVE to escalate to SYSTEM using uninstall/DLL TOCTOU techniques.
• Token harvest / machine identity abuse: attacker queries local metadata endpoints or agent APIs (e.g., Azure Connected Machine / azcmagent or similar) to obtain machine‑assigned tokens or to request service tokens.
• Cross‑plane impersonation: attacker uses harvested tokens against management APIs. If actor token validation is flawed or legacy APIs accept actor tokens without strict tenant/audience checks, attacker can impersonate privileged identities elsewhere. This is the scenario the Entra actor token reports warned about.
• Tenant takeover: attacker creates service principals, grants consent, adds role assignments, or otherwise modifies tenant configuration and resources — possibly without creating clear audit trails.

This realistic multi‑stage chain shows why defenders must treat identity validation and management host hardening as a single joint problem rather than isolated controls.

---

Vendor responses and timeline (what we can verify)​

• Microsoft: issued advisories, assigned CVE identifiers for the WAC EoP and for the Entra actor token validation issue, and deployed mitigations. Vendor advisories emphasized mapping CVEs to KBs and per‑SKU updates; administrators are instructed to consult Microsoft’s Security Update Guide for precise KB mappings before patching. Public readouts describe the identity fix as requiring no customer action in some cases (because Microsoft rolled mitigations server‑side), but defenders should validate tenant status and apply all recommended patches.
• Independents: security vendors and researchers published technical writeups and PoC details illustrating practical exploitation chains for WAC EoP and the Entra actor token misuse. These writeups validated vendor classifications and supplied practical mitigations (ACL hardening, audit hunts, token rotation).
• SAS: announced FedRAMP Moderate authorization for SAS Viya — an independent, non‑security story in the same news cycle but operationally relevant because it shows the accelerating adoption of cloud AI platforms by government. Agencies planning to onboard Viya now have a FedRAMP‑authorized path for procurement.

Caveat: some early community posts and aggregator feeds showed inconsistent CVE strings or slightly differing impact statements; the authoritative mapping and package identifiers remain Microsoft’s Security Update Guide and the vendor KBs. Defenders should not rely solely on CVE numbers found in third‑party summarizations — always confirm KB/package mapping in official vendor update guides.

---

Immediate, prioritized actions for Windows administrators and cloud defenders​

The joint nature of these findings means response actions must be coordinated across endpoint, identity and cloud teams. Below is a prioritized checklist.

Triage and containment (first 24 hours)​

• Inventory: identify all Windows Admin Center instances, jump hosts, bastions and management servers in your environment. Map versions and installed SKUs. Use your asset inventory (SCCM/Intune/WSUS/Azure Resource Graph) to find WAC hosts quickly.
• Patch planning: consult Microsoft’s Security Update Guide to map CVE → KB → exact package for your SKU and schedule a staged rollout (pilot → canary → broad). Do not assume a single KB will fit every environment.
• Harden filesystem ACLs: restrict write access to C:\ProgramData\WindowsAdminCenter and its Updater and Extensions\uninstall subfolders to SYSTEM and Administrators only. This blocks the most straightforward script/DLL placement attacks even if a patch is delayed.
• Isolate management hosts: temporarily segment WAC hosts to a restricted management network and enforce host‑level firewall rules to limit exposure.

Short‑term (24–72 hours)​

• Revoke and rotate high‑value tokens and machine identities on hosts that show suspicious activity. If you suspect a WAC host was compromised, rotate any certificates, keys, and service principal secrets it could access.
• Enforce phishing‑resistant MFA (FIDO2 or certificate‑based) for all administrative accounts that can consent to apps or manage WAC. Reduce the number of users who can grant tenant‑wide consent.
• Hunt for indicators of compromise: unexpected SYSTEM process creations whose parent is the WAC service; sudden service installs; scheduled tasks; or unusual calls to local metadata endpoints (IMDS/HIMDS). Prioritize EDR hunts on jump hosts.

Medium term (3–14 days)​

• Apply vendor patches broadly and validate via automated telemetry checks that updates were applied and that WAC‑triggered elevation behavior no longer occurs.
• Centralize audit logs: make sure all token issuance events, admin consent events, and internal service token flows are forwarded to a SIEM and retained long enough for useful investigation.
• Restrict application consent and app registrations: disable user consent for high‑impact scopes and require admin‑only consent for application permissions that affect tenant configuration.

Long term (weeks → months)​

• Adopt device‑bound tokens (DPoP, mTLS) for sensitive refresh flows and prefer opaque tokens at resource boundaries to reduce the value of stolen JWTs.
• Reduce legacy API exposure: plan to deprecate or isolate legacy endpoints (e.g., Azure AD Graph) and migrate to modern, auditable flows (Microsoft Graph) with strict tenant and audience checks.
• Segregate administrative duties: adopt Privileged Identity Management (PIM) and just‑in‑time elevations with approvals and session recording for the most sensitive roles.

---

SAS Viya FedRAMP: opportunity and risk for government customers​

SAS’s FedRAMP Moderate authorization for SAS Viya brings benefits for agencies: a managed, auditable AI/analytics platform with governance, explainability and model monitoring built into the stack. For IT teams, that can accelerate pilots and give procurement teams a direct, compliant path to deploy advanced analytics in Azure. But FedRAMP authorization is a necessary baseline, not an automatic trust signal that obviates operational security work. Agencies must still:

• Validate the ATO package and the FedRAMP Moderate System Security Plan (SSP) artifacts that describe how SAS manages keys, logging, vulnerability remediation and incident response.
• Require contractual clarity on data residency, key management, and breach notification timelines.
• Test vendor exit and data‑export processes (export runbooks, verified restores) before productioning mission‑critical decisioning systems.
• Treat the platform as part of the broader cloud estate: enforce least privilege for service accounts and integrate SAS Viya operational logs into the agency SIEM.

In short: FedRAMP opens doors to new capabilities, but identity hygiene and tenant protections must match the assurance level the agency expects.

---

Critical assessment: strengths and lingering risks​

Notable strengths​

• Vendor responsiveness: Microsoft moved quickly to mitigate the Entra actor token issue once a responsible disclosure was filed, and researchers were able to push coordinated disclosures that led to CVEs and patches. That closed a potentially catastrophic class of silence‑enabled attacks before widespread exploitation was reported.
• Practical mitigations exist: many of the high‑impact WAC exploit paths rely on avoidable misconfigurations (world‑writable management folders, permissive uninstall flows). Hardening ACLs, enforcing atomic validation in update flows, and restricting who can consent to apps are actionable controls that materially reduce exposure.
• FedRAMP accreditation for SAS Viya is a concrete step that enables agencies to pursue modernization with a vendor that supports explainability and ModelOps, easing procurement friction.

Residual risks and caveats​

• Audit and telemetry gaps persist: the Entra actor token incident highlighted that internal backend tokens and legacy API paths can evade tenant logs. Organizations cannot assume complete visibility — additional instrumentation and service‑level logging are necessary.
• Legacy APIs and technical debt: the persistence of older APIs and undocumented token types (actor tokens) means new mitigations can be brittle; until legacy endpoints are fully retired, attack surface remains.
• Chaining remains feasible: even with patches applied, adversaries who gained footholds during the vulnerability window may still have persistence. Aggressive hunting for historic role assignments, newly created service principals, and revoked tokens is essential.
• Supply‑side concentration: as agencies adopt FedRAMP‑authorized AI platforms, they also increase reliance on cloud providers’ identity systems. Systemic identity architecture failures are therefore more consequential: a single identity flaw can ground multiple services.

---

Practical checklist for boardroom to SOC​

• Board / CISO: treat management hosts as crown jewels — budget for immediate remediation of management plane vulnerabilities and mandate evidence (logs, KB rollout artifacts) that tenant protections are in place.
• IAM teams: validate tenant telemetry for actor token issuance and make legacy API deprecation a priority. Implement device‑bound tokens and short token lifetimes for privileged app flows.
• Platform/Infrastructure teams: inventory WAC and other management surfaces; harden ACLs, isolate jump hosts and apply updates in staged waves with verification.
• Security operations: run retrospective hunts for admin consent grants, new service principals, and cross‑tenant role changes during the period in question. Rotate keys and secrets as part of containment.
• Procurement/Government IT: when adopting FedRAMP solutions like SAS Viya, require ATO artifacts, test export/exit playbooks, and integrate vendor logs into agency SOC workflows.

---

Conclusion​

The recent mix of identity validation flaws and management‑plane EoP bugs is a textbook example of combined risk: individually dangerous, but together able to escalate a local foothold into a tenant‑wide compromise. Microsoft’s fast mitigations and independent research pushed the community to close the most urgent gaps, but the core lesson is enduring — identity validation and management host hardening are inseparable. Administrators must act now: inventory management hosts, lock down filesystem ACLs, apply vendor KBs, harden consent and token lifecycles, and run aggressive hunts for historic abuse. At the same time, agencies adopting FedRAMP‑authorized AI platforms should treat authorization as a starting point — not a finish line — and demand operational proof that identity, logging and exit controls are solid before trusting AI with mission decisions.
The technical fixes exist and are practical, but they require coordinated execution across IT, security and procurement teams. The window for preventing an adversary from chaining a host compromise into a tenant takeover is narrow — act as if the attacker is already inside, and harden the identity and management surfaces accordingly.

---

Source: Cyber Press https://cyberpress.org/azure-identi...to-us-government-with-fedramp-authorization/]