Windows privileges and access tokens create durable escalation risk

At a glance

What this is: This is an analysis of how Windows privileges and access tokens can be abused for local privilege escalation and follow-on compromise.

Why it matters: It matters because IAM, PAM, and NHI teams often audit permissions but miss privilege assignments that can turn ordinary accounts and service identities into SYSTEM-level footholds.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Semperis's analysis of Windows privilege abuse and token escalation

Context

Windows privileges are not the same thing as access permissions. In Active Directory and local Windows environments, an account can hold rights that bypass normal ACL checks, which means the real exposure is often hidden in user-right assignments, service account defaults, and inherited policy. The primary issue here is Windows privilege abuse in environments that assume patching alone will contain escalation.

Semperis shows that attackers do not need a new bug to gain SYSTEM. They can exploit legitimate privileges such as impersonation, backup, restore, and debug rights to escalate locally and then move laterally. For IAM, PAM, and NHI programmes, that makes privilege inventory and effective entitlement review a core control plane, not an afterthought.

In practice, the risk is highest where service accounts, built-in operator groups, and delegated administrative roles are left with more capability than they need. That is typical in mature but complex Windows estates, and it is exactly why architectural controls matter more than exception-driven cleanup.

Key questions

Q: What breaks when Windows privileges are treated like ordinary permissions?

A: Security teams miss the rights that can override ACLs and enable escalation even when file and share permissions look correct. That gap lets service accounts, operator groups, and privileged users reach SYSTEM through legitimate features rather than exploits. The fix starts with effective privilege review, not just permission review.

Q: Why do service accounts create disproportionate Windows escalation risk?

A: Service accounts often carry impersonation and token-related rights that are enough to move from application context to SYSTEM. Because those rights are attached at runtime, the account can appear ordinary in directory reports while still retaining dangerous authority. That is why service account governance must include token state and user-right assignments.

Q: How do security teams know whether Windows privilege controls are actually working?

A: They should measure whether dangerous rights are absent from non-essential accounts, whether resultant policy matches intended design, and whether EDR telemetry shows token-manipulation attempts. If whoami /priv, DuplicateToken, or ImpersonateLoggedOnUser appear on sensitive hosts without an approved admin task, the control is failing in practice.

Q: Who is accountable when backup privileges expose protected Windows data?

A: Accountability sits with the owner of the privilege model, the service owner, and the platform team together. Backup and restore rights can bypass ordinary protections, so they need explicit business justification, periodic review, and clear offboarding when a role or service changes. Residual access after the task ends is a governance defect.

Technical breakdown

Windows privileges versus ACLs: why the permission model can be bypassed

Windows privileges are system rights assigned to an account or group, while ACLs govern access to specific objects. The important distinction is that privileges can override ordinary object permissions, so a user may be blocked by an ACL yet still perform high-risk actions if the token includes the right privilege. These privileges are commonly assigned through local policy or Group Policy, and many are only visible once a shell is running in the right security context. That makes privilege review a separate exercise from permission review. Practical implication: audit user-right assignments and resultant policy, not just filesystem or share permissions.

Practical implication: separate privilege review from ACL review and inspect resultant policy across all Windows estates.

Access tokens and impersonation: how Windows carries privilege at runtime

Windows access tokens represent the security context for a process or thread. At logon, the system creates a token containing the user SID, group memberships, privilege set, and token type, and child processes inherit copies of that context. Because many privileges are already embedded in the token, attackers who reach an elevated context can often enable or reuse what is already present rather than adding something new. Token manipulation matters because changing token type or impersonating a different caller can open paths to SYSTEM without exploiting a patchable bug. Practical implication: monitor token-manipulation APIs and treat elevated shells as high-risk runtime states, not just administrative conveniences.

Practical implication: monitor token-manipulation APIs and elevated shells as active escalation surfaces.

Impersonation, backup, and restore rights: the shortest path to SYSTEM

The most abused privileges in this article are SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeBackupPrivilege, and SeRestorePrivilege. Impersonation privileges let a process act as another security context, which is why Potato-family techniques remain effective against service accounts and application identities. Backup and restore privileges are even more dangerous because they can bypass normal file and registry protections, enabling reading protected data or overwriting service configuration. In shared Windows environments, those rights can turn a routine service account into a domain-impacting foothold. Practical implication: reduce dangerous rights on service identities and built-in operator groups before attackers inherit them by design.

Practical implication: remove high-risk rights from service identities and built-in operator groups wherever operationally possible.

Threat narrative

Attacker objective: The attacker wants local SYSTEM privileges that can be converted into credential theft, persistence, and eventual domain-level compromise.

1. Entry begins when an attacker compromises a service account, captures credentials, or reaches a host where dangerous Windows privileges are already assigned to the token.
2. Escalation follows through token impersonation, backup and restore abuse, or debug-style access that lets the attacker cross from limited context to SYSTEM-level control.
3. Impact occurs when the attacker uses that elevated position to dump credentials, overwrite protected files, alter services, or move laterally into broader Active Directory compromise.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

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

NHI Mgmt Group analysis

Windows privilege abuse is a governance failure, not a patching problem. Semperis is describing rights that work as designed, which means defenders cannot wait for a vendor fix to close the gap. The programme failure is the assumption that ACL review alone captures effective authority. Practitioners should treat privilege assignments as a distinct control domain under PAM and Windows administration governance.

Privilege assignment creates an identity blast radius that many teams never measure. A service account with SeImpersonatePrivilege, or a built-in operator group with backup and restore rights, is not just a local admin inconvenience. It is an escalation pathway that can expose protected files, tokens, and eventually Active Directory material. That makes effective privilege review a tiered risk exercise, not a checkbox on an access review form.

Impersonation rights remain one of the clearest examples of standing privilege debt in Windows estates. The same account may look low-risk in directory reporting while retaining runtime powers that can be activated instantly. That mismatch is why NHI governance and PAM have to look at token state, service defaults, and effective rights together. The conclusion is simple: if the token can impersonate, the account is already operating above its apparent tier.

Backup and restore privileges collapse the boundary between operational access and compromise. A role intended for resilience can become a credential-exposure mechanism when it can read protected data or overwrite service configuration. This is the same governance pattern that shows up across NHI programmes: privileged capability outlives the business need that justified it. The implication is that recovery roles need the same lifecycle scrutiny as administrative roles.

Windows privilege governance should be treated as part of the broader non-human identity and workload identity problem. Service accounts, application pool identities, and managed service identities often carry the very rights attackers want. That connects Windows administration directly to NHI lifecycle management, because the risk is not the account name but the effective runtime authority attached to it. Practitioners should align privilege governance with identity lifecycle, not with platform teams alone.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• Our research also shows that 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
• If your programme is still treating token exposure as a code-only problem, review The 52 NHI breaches Report for the wider lifecycle pattern.

What this signals

Standing privilege debt: Windows environments accumulate authority that outlives the business need that created it, and that is where escalation risk becomes persistent. The practical issue is not whether the host is patched, but whether runtime authority can still be activated by a low-friction token or service context. Teams should align privilege cleanup with lifecycle offboarding, using the same discipline applied to NHI and workload identities.

Service accounts and built-in operator groups deserve the same governance intensity as human administrative accounts because the attack path depends on their effective rights, not their label. For practitioners, the next step is to connect Windows right assignment reviews to PAM, EDR, and identity lifecycle reporting so that hidden escalation paths surface before they are exercised.

The broader signal is that identity programmes can no longer separate human IAM from machine and service identity controls when a Windows token can become a domain foothold. The control question is whether your environment can detect and remove runtime authority that exists only because a legacy privilege remains assigned, not because anyone still needs it.

For practitioners

• Review resultant privilege assignments across all Windows estates Inspect Computer Configuration, Windows Settings, Security Settings, Local Policies, and User Rights Assignment, then compare effective policy after inheritance and precedence are applied. Prioritise Tier 0 systems, jump hosts, and shared RDP servers.
• Inventory service accounts for impersonation and token rights Find every account holding SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege, then validate whether the service still needs those rights. Where possible, restrict assigned privileges through the Required Privileges registry key and re-test service function.
• Treat backup and restore roles as domain-risk roles Review membership in Backup Operators, Server Operators, Print Operators, and Account Operators, then validate whether local logon rights or backup semantics expose NTDS.DIT, registry hives, or protected service paths.
• Monitor token-manipulation activity in EDR telemetry Alert on whoami /priv execution and API usage such as DuplicateToken, ImpersonateLoggedOnUser, CreateProcessWithToken, and LsaLogonUser. Use those signals to separate routine administration from active escalation behaviour.

Key takeaways

• Windows privileges can bypass ACL-based assumptions, so permission review alone does not contain escalation risk.
• The article shows that impersonation, backup, restore, and debug-style rights can convert ordinary service context into SYSTEM-level control.
• The control that matters most is effective privilege governance across service accounts, operator groups, and resultant policy, not patching alone.

Key terms

• Windows Privilege: A Windows privilege is a system right granted to an account that can allow actions beyond ordinary object permissions. It is separate from ACLs and can enable sensitive operations such as impersonation, backup, restore, or driver loading even when file-level permissions look restrictive.
• Access Token: An access token is the runtime security context Windows attaches to a process or thread. It contains identity, group membership, and privilege information, which means escalation often happens by reusing or manipulating a token rather than changing a password or bypassing a login prompt.
• Impersonation Privilege: Impersonation privilege is the ability to act as another security context after authentication. In Windows estates, that matters because a service account or application identity with the right privilege can borrow a higher-privilege token and execute actions as SYSTEM or another caller.
• Resultant Policy: Resultant policy is the effective set of Windows rights an account receives after local settings, Group Policy, inheritance, and precedence are applied. It is the real control state, which often differs from what any one administrator thinks was configured.

What's in the full article

Semperis's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how specific Windows privileges are abused to reach SYSTEM across different privilege families.
• Code-level API examples for token manipulation, impersonation, backup, and restore abuse.
• The full list of targeted privileges and the attacker workflows associated with each one.
• Hardening guidance for service accounts, built-in groups, and local policy assignments in Windows estates.

👉 Semperis's full article covers the privilege-specific abuse paths and hardening steps in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.