TL;DR: Windows privileges can override ACL-based permissions and let attackers escalate from a low-privileged foothold to SYSTEM, according to Semperis research. That means privilege assignments, service account defaults, and token handling matter as much as patching, because the abuse path is architectural rather than vulnerability-based.
NHIMG editorial — based on content published by Semperis: Windows privilege abuse and access token escalation
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Inventory service accounts for impersonation and token rights Find every account holding SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege, then validate whether the service still needs those rights.
- 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.
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.
👉 Read Semperis's analysis of Windows privilege abuse and token escalation →
Windows privilege abuse in Active Directory: what IAM teams miss?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Windows privileges and access tokens create durable escalation risk