By NHI Mgmt Group Editorial TeamDomain: Breaches & IncidentsSource: CymulatePublished April 15, 2026

TL;DR: Chained Windows Admin Center flaws can let an attacker trigger unauthenticated, one-click remote code execution, steal Azure tokens from local storage, and hijack administrative sessions across on-prem and Azure-managed deployments, according to Cymulate Research Lab. Server-side trust in redirect targets and response handling is the brittle point, not just client-side input validation.


At a glance

What this is: This is a vulnerability analysis showing how Windows Admin Center control-flow flaws can be chained into unauthenticated admin-level remote code execution and token theft.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat management-plane workflows, browser-held tokens, and cross-origin trust boundaries as security controls, not implementation details.

👉 Read Cymulate's analysis of the Windows Admin Center control-flow hijacking flaw


Context

Windows Admin Center is a management plane, and management planes concentrate identity risk because they sit between operators, browser sessions, and privileged systems. In this case, the core weakness is not a single bug but a broken trust boundary across redirect handling, JSON parsing, and token storage, which turns a normal admin workflow into an execution path for attackers.

For identity teams, the important lesson is that access to infrastructure management tools is still identity security. When browser-held tokens, delegated admin sessions, and managed-device control are all coupled together, one flaw can move from authenticated workflow abuse to full administrative compromise across both on-prem and cloud-connected environments.


Key questions

Q: What breaks when a management console trusts attacker-controlled redirect targets?

A: The console stops being a controlled admin boundary and becomes a routing layer an attacker can steer. That allows phishing, request diversion, and in some cases script execution inside a privileged origin. Once the browser follows a malicious but valid-looking endpoint, downstream authentication and session handling can be weaponised.

Q: Why do browser-stored management tokens increase compromise impact?

A: Because any script execution in that origin can read them and replay them as if it were the operator. In management tools, that turns a web flaw into session impersonation, often with cloud or infrastructure control attached. The risk is highest when the token is long-lived or has broad management scope.

Q: How do security teams detect unsafe response handling in admin portals?

A: By testing every non-success path, not just the happy path. Look for JSON error fields, reflected markup, cross-frame messaging, and server-supplied strings that reach the DOM without encoding. If backend diagnostics can alter browser behaviour, the portal has an exploitable trust boundary.

Q: Who is accountable when a management-plane flaw exposes administrative access?

A: The owning platform team and the identity governance function share accountability, because the flaw spans application design and privileged access control. Management consoles should be governed like identity infrastructure, with clear ownership for redirect policy, token handling, session design, and secure update response when flaws are found.


Technical breakdown

Attacker-controlled gateway URLs break the management trust boundary

The first mechanism is control-flow hijacking through a valid but tampered gateway URL. The application accepts attacker-chosen HTTPS endpoints as long as they present a trusted certificate, which means the browser is redirected into an attacker-controlled flow while still believing it is talking to a legitimate WAC endpoint. That matters because the trust decision is based on transport legitimacy, not application legitimacy. Once the browser is pointed at the wrong server, subsequent responses can shape the admin workflow and prepare the conditions for script execution or credential capture.

Practical implication: validate gateway destinations against an allowlist and treat redirect targets as security-relevant input.

Server responses become script execution when JSON error handling is unsafe

The second mechanism is response-based XSS in the portal and gateway flow. When the application parses non-200 responses as JSON and renders the message field without sanitisation, an attacker can inject HTML and JavaScript through an error response rather than through a form field. That is a common but dangerous pattern in management applications because the server is treated as trusted by default. In cross-origin admin portals, the server response must be handled as untrusted data, especially when that response can influence the browser context of a privileged operator.

Practical implication: sanitise every server-supplied field before rendering it inside privileged management interfaces.

Local storage token exposure turns XSS into full session impersonation

The third mechanism is insecure credential storage in the on-prem deployment. Azure access and refresh tokens were stored in browser local storage under the WAC management domain, which makes them readable to any script running in that origin. Once XSS exists, token theft becomes straightforward, and the attacker can replay the stolen credentials to impersonate the user with management-level access. This is especially serious because the abuse is not limited to a single page session. The browser becomes a credential container, and the management plane becomes a token exfiltration target.

Practical implication: keep management tokens out of browser local storage and limit their lifetime and replay value.


Threat narrative

Attacker objective: The attacker aims to obtain administrative control of managed servers and Azure-connected resources by abusing the management plane itself.

  1. Entry occurs when a victim visits or is redirected to a tampered Windows Admin Center URL that still appears legitimate.
  2. Escalation follows when unsafe redirect handling and response-based XSS let the attacker execute script inside the privileged WAC browser context or force a malicious gateway flow.
  3. Impact occurs when the attacker uses the compromised browser context to steal management tokens or invoke commands, resulting in administrative control over managed systems and Azure access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Control-flow trust is the real asset in management-plane security. Windows Admin Center is not just a web app, it is a privileged identity broker between operators, browser sessions, and managed infrastructure. Once an attacker can steer that flow with a valid-looking URL, the security model depends on redirect trust that should never have been granted to external input. Practitioners should treat management-plane routing as an identity control surface, not a convenience feature.

Response-based XSS in admin tooling is an identity compromise, not a cosmetic web flaw. The application rendered attacker-controlled error content inside a privileged origin, which let script execute in the same context as the operator. That means the trust boundary failed at the server response layer, where management consoles often assume correctness because the data came from a backend they own. For IAM and PAM teams, this is a reminder that browser context around privileged workflows must be defended like any other sensitive authentication boundary.

Insecure browser token storage creates identity blast radius. Storing Azure access and refresh tokens in local storage made the on-prem deployment brittle once script execution was possible. Identity blast radius: the credential exposure range created when a single browser-origin flaw can convert one admin session into reusable management tokens. That is not a storage mistake in isolation, it is a governance failure because replayable access was placed in the most script-exposed part of the client. Practitioners should treat token placement as part of privilege design.

Least privilege was assumed at provisioning time, but this exploit chain invalidated that assumption. The workflow presumed that a legitimate admin session would remain confined to intended actions and trusted endpoints. That assumption fails when an attacker can redirect the session, inject script, and reuse tokens to act as the operator across managed systems. The implication is that management-plane privilege cannot be defined only by role assignment. It also depends on whether the runtime path itself can be subverted.

From our research:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
  • That visibility gap is why lifecycle, token, and delegation controls need separate review, as covered in 52 NHI Breaches Analysis.

What this signals

Identity blast radius: management-plane compromise is increasingly a token and delegation problem, not just a web vulnerability problem. When browser-held credentials can be replayed into cloud control, the security programme has to model where identity artefacts live, not just who owns the role.

Teams should expect more attacks that chain redirect abuse, response-driven XSS, and token theft into one workflow. The practical response is to treat privileged browser sessions as sensitive identity assets and to validate them against controls in the NIST SP 800-53 Rev 5 Security and Privacy Controls.

For organisations running hybrid admin tooling, the next maturity step is separating administrative intent from browser-executable trust. That means tightening session scope, reducing token replay value, and reviewing how management flows align with the MITRE ATT&CK Enterprise Matrix for credential access and privilege escalation.


For practitioners

  • Harden gateway allowlisting Restrict Windows Admin Center gateway endpoints to known-good destinations and reject attacker-chosen HTTPS targets even when certificates are valid. Treat redirect destinations and broker URLs as security inputs that require explicit policy enforcement.
  • Sanitise all server-originated error content Review every admin portal path that renders backend error messages, JSON fields, or diagnostic strings into a privileged browser context. Apply output encoding and server-side validation before any message reaches the DOM.
  • Remove replayable tokens from browser local storage Move management tokens out of local storage, shorten their usable lifetime, and reduce the value of any token exposed through script execution. Browser-accessible storage should not hold credentials that can impersonate administrative access.
  • Segment management-plane privileges from cloud access Separate the identity used to reach the management console from the identity that can operate Azure resources so one browser compromise does not automatically become tenant-wide access. Validate the delegation chain independently at each step.
  • Test for response-driven XSS in trusted admin flows Include error-path testing in security validation for management portals, especially when responses from internal services are parsed, rendered, or forwarded across frames. Validate both client input and server response handling in the same test plan.

Key takeaways

  • Windows Admin Center flaws show how a management console can become an attack path to full administrative control when redirect handling, response parsing, and token storage are trusted too easily.
  • The abuse chain matters more than any single bug, because one valid-looking link can lead to script execution, credential theft, and cross-environment impersonation.
  • Practitioners should harden gateway allowlists, remove replayable tokens from browser storage, and test privileged portals for response-driven XSS in the same control set.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
MITRE ATT&CKTA0006 , Credential Access; TA0004 , Privilege Escalation; TA0001 , Initial AccessThe article chains credential theft and privilege escalation through a trusted admin flow.
NIST CSF 2.0PR.AC-1Redirect trust and token handling are access control issues in a privileged interface.
NIST SP 800-53 Rev 5AC-6The flaw expands effective privilege far beyond intended scope.
OWASP Non-Human Identity Top 10NHI-03The on-prem issue exposes token storage and lifecycle weaknesses in a non-human access path.
NIST Zero Trust (SP 800-207)section 5.1The attack breaks implicit trust in the management session and backend path.

Map the attack chain to ATT&CK and prioritise controls that block credential capture and privilege gain.


Key terms

  • Control-Flow Hijacking: A condition where an attacker influences the path an application follows so that a legitimate workflow reaches an unintended destination or action. In management software, this often means redirecting trusted browser activity into attacker-controlled responses, which can then shape authentication, execution, or command delivery.
  • Response-Based XSS: A cross-site scripting flaw where malicious code is injected through a server response rather than a user input field. In privileged admin tooling, that is especially dangerous because the response is often treated as trusted and can execute in the same origin as the management interface.
  • Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.
  • Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full report

Cymulate's full analysis covers the exploitation mechanics this post intentionally leaves at the pattern level:

  • Step-by-step reproduction of the Azure-managed and on-prem attack chains, including the exact flow redirection and XSS conditions
  • Detailed payload examples showing how the forged gateway and JSON error response were used to reach execution
  • Token handling specifics for the on-prem deployment, including how browser local storage exposed Azure access and refresh tokens
  • Operational remediation guidance for customers using updated Windows Admin Center releases

👉 The full Cymulate post covers the exploit chain, token exposure path, and remediation guidance in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org