Windows Privilege Model
Understanding the security architecture that controls access to everything
What You'll Discover
🎯 Why This Matters
Every Windows privilege escalation exploit targets a specific weakness in the Windows security model. Before you can break it, you need to understand how it works. Access tokens, SIDs, privileges, and integrity levels form the foundation of Windows security - and the foundation of every privesc technique you'll learn.
🔍 What You'll Learn
- How Windows access tokens carry identity and privileges through the system
- The structure of Security Identifiers (SIDs) and what each component means
- Windows privilege constants and which ones enable privilege escalation
- Mandatory Integrity Control and how it restricts low-privilege processes
🚀 Your First Win
In the next 5 minutes, you'll examine your own access token and identify the exact privileges that could enable escalation on a compromised system.
🔧 Try This Right Now
Open a Command Prompt and examine your current token's privileges:
whoami /priv
whoami /groups
whoami /allYou'll see: A list of privileges assigned to your token, your group memberships with their SIDs, and your complete security context. Note any privileges marked as "Enabled" - these are immediately usable.
Skills You'll Master
✅ Core Understanding
- Windows access token architecture
- SID structure and well-known SIDs
- User rights vs privileges
- Integrity levels (Low, Medium, High, System)
🔍 Expert Skills
- Identifying dangerous privileges
- Token manipulation concepts
- UAC and token filtering
- Primary vs impersonation tokens
Understanding the Windows Security Model
Windows security is built on a simple but powerful concept: every process runs with an access token that defines what it can do. This token contains your identity (SIDs), your privileges, and your integrity level. When you try to access a resource, Windows compares your token against the resource's security descriptor to determine access.
Access Token = Identity (SIDs) + Privileges + Integrity Level
Security Identifiers (SIDs)
Every security principal in Windows (users, groups, computers) has a unique SID. SIDs follow a specific format:
S-1-5-21-3623811015-3361044348-30300820-1013
│ │ │ └─────────────────────────────────┴── Relative ID (RID)
│ │ │ └── Domain/Machine Identifier
│ │ └── Identifier Authority (5 = NT Authority)
│ └── SID Revision (always 1)
└── SID prefixWell-known SIDs you should memorize:
SYSTEM
S-1-5-18
Highest privilege account
Administrators
S-1-5-32-544
Built-in admin group
Users
S-1-5-32-545
Standard users group
Dangerous Privileges
Certain privileges enable direct privilege escalation. When you see these on a compromised account, you have a path to SYSTEM:
| Privilege | Attack Vector |
|---|---|
| SeImpersonatePrivilege | Token impersonation (Potato attacks) |
| SeAssignPrimaryTokenPrivilege | Assign tokens to new processes |
| SeBackupPrivilege | Read any file (bypass ACLs) |
| SeRestorePrivilege | Write any file (bypass ACLs) |
| SeDebugPrivilege | Debug any process, inject code |
| SeTakeOwnershipPrivilege | Take ownership of any object |
Integrity Levels
Mandatory Integrity Control (MIC) adds another layer of access control. Even if ACLs allow access, a lower integrity process cannot write to higher integrity objects:
System - S-1-16-16384 (Windows services, kernel)
High - S-1-16-12288 (Elevated administrators)
Medium - S-1-16-8192 (Standard users, default)
Low - S-1-16-4096 (Sandboxed processes, browsers)
Untrusted - S-1-16-0 (Most restricted)Tools and Techniques
Built-in Windows Commands
Windows provides native tools for examining security context:
# Display current user's privileges
whoami /priv
# Display group memberships with SIDs
whoami /groups
# Display complete token information
whoami /all
# Check integrity level of current process
whoami /groups | findstr "Label"
# Display SID of current user
wmic useraccount where name='%username%' get sidPowerShell Security Cmdlets
PowerShell provides deeper insight into the security model:
# Get current Windows identity
[Security.Principal.WindowsIdentity]::GetCurrent()
# Check if running as administrator
([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
# List all privileges in current token
[Security.Principal.WindowsIdentity]::GetCurrent().Claims | Where-Object { $_.Type -match "privilege" }
# Get process integrity level
(Get-Process -Id $PID).HandleSysinternals Tools
Microsoft's Sysinternals suite provides professional-grade security analysis:
- Process Explorer - View tokens, privileges, and integrity levels of running processes
- AccessChk - Check permissions on files, services, registry keys, and more
- PsExec - Execute processes with different tokens (including SYSTEM)
Download from: Microsoft Sysinternals
Real-World Attack Scenarios
🔴 Case Study: IIS Application Pool to SYSTEM
Web applications running in IIS application pools run as service accounts with SeImpersonatePrivilege. This privilege, combined with Potato-family exploits, allows escalation from web shell to SYSTEM. This is one of the most common privilege escalation paths in real penetration tests.
Attack chain: Web shell → Check privileges → Find SeImpersonatePrivilege → Run JuicyPotato/PrintSpoofer → SYSTEM shell
🟠 Case Study: Backup Operators Group Abuse
Members of the Backup Operators group have SeBackupPrivilege and SeRestorePrivilege. These privileges bypass file ACLs, allowing reading of the SAM database and SYSTEM registry hive. With these files, offline password cracking or pass-the-hash attacks become possible.
Attack chain: Backup Operators membership → Export SAM/SYSTEM → Extract hashes with secretsdump → Pass-the-hash to Administrator
💡 Expert Insight
The Windows privilege model is complex by design. Every privilege exists for a legitimate purpose, but each one can be abused. Understanding why privileges exist helps you identify exploitation opportunities and explain risks to clients during penetration test debriefs.
Defensive Countermeasures
Principle of Least Privilege
The most effective defense against privilege escalation is ensuring accounts only have the privileges they need:
- Remove users from privileged groups (Administrators, Backup Operators) unless absolutely required
- Use Group Policy to restrict privilege assignment
- Service accounts should use Managed Service Accounts (MSAs) with minimal privileges
- Regular audits of group memberships and privilege assignments
Token Protection
- Enable Credential Guard to protect LSASS and tokens
- Configure UAC to "Always notify" for maximum protection
- Implement Windows Defender Credential Guard on sensitive systems
- Use Protected Users security group for high-value accounts
Monitoring and Detection
- Enable audit policies for privilege use and token manipulation
- Monitor Event ID 4672 (Special privileges assigned to new logon)
- Alert on SeDebugPrivilege and SeImpersonatePrivilege usage
- Use Microsoft Defender for Endpoint or similar EDR solutions
Frequently Asked Questions
What's the difference between a privilege and a right in Windows?
Privileges control what a user can do to the system (debug processes, backup files, shutdown), while rights control how users can log on (interactive, network, service). Both are assigned through Local Security Policy or Group Policy, but they serve different purposes. From a privesc perspective, privileges are what you're looking for.
Why do service accounts have SeImpersonatePrivilege?
Service accounts need this privilege to handle client requests. When a client connects to a service, the service impersonates the client to access resources on their behalf. This is by design, but it creates the attack surface that Potato exploits leverage. Microsoft considers this "working as intended" rather than a vulnerability.
Can I escalate privileges with a Medium integrity token?
Standard Medium integrity tokens don't have dangerous privileges by default. You'll need to find misconfigurations (weak service permissions, unquoted paths, writable program directories) or UAC bypasses to escalate. The privilege-based attacks like Potato require SeImpersonatePrivilege, which standard users don't have.
What's the difference between Administrator and SYSTEM?
Administrator is a user account that can be logged into and has a password. SYSTEM (LocalSystem) is a service account with the highest privileges on the local machine - it owns processes like services.exe and lsass.exe. SYSTEM can do everything Administrator can, plus access certain protected resources. In domain environments, SYSTEM represents the computer account.
🎯 Windows Security Model - Understood!
You now understand the foundation of Windows security: access tokens, SIDs, privileges, and integrity levels. Every privilege escalation technique you'll learn exploits weaknesses in this model.
Ready to learn manual enumeration techniques →