Windows Access Tokens and Security Context: The Authorization Core

Windows Kernel Execution Model

In the Windows NT architecture, users do not execute code: processes execute code.

When an identity authenticates, the operating system creates a logon session and binds an Access Token to it. Every process spawned within that session inherits a duplicate of this token. The Security Reference Monitor (SRM) exclusively inspects this token to grant or deny access to securable objects.

Concept

An Access Token is a Windows kernel object (nt!_TOKEN) generated by the Local Security Authority Subsystem Service (LSASS) upon successful authentication. It encapsulates the complete security context required for authorization decisions:

• User SID: The primary identity of the account.
• Group SIDs: All local, domain, and well-known group memberships evaluated at logon.
• Privileges List: Operating system capabilities assigned to the principal (SeDebugPrivilege, SeImpersonatePrivilege), each marked as Enabled or Disabled.
• Integrity Level: Mandatory Integrity Control (MIC) classification: Untrusted, Low, Medium, High, or System.
• Token Type: Primary Token (bound to a process) or Impersonation Token (bound to an individual thread to temporarily act on behalf of a client).
• Authentication ID & Logon Session: Unique LUID referencing the logon session.

---

Why This Matters in DFIR

Understanding access tokens is vital to deconstructing in-memory attacks and privilege escalation:

1. Token Theft & Impersonation (T1134): An attacker with SYSTEM rights on a server can inspect memory, duplicate an administrator’s access token (via incognito or Mimikatz token::elevate), and spawn processes under that identity without knowing their credentials.
2. User Account Control (UAC) Filtering: Interactive administrators receive a split token. By default, processes run under a Medium Integrity token stripped of administrative SIDs and privileges. Un-elevated malicious activity will fail against protected resources.
3. SeImpersonatePrivilege Exploitation (Potato Attacks): Service accounts (e.g., IIS pools, SQL service) holding this privilege can force a SYSTEM process to authenticate against a local named pipe, capture its token, and elevate immediately.

---

How It Works

1. Token Anatomy

                  ┌───────────────────────────────────────────────┐
                  │                 Access Token                  │
                  ├───────────────────────────────────────────────┤
                  │ User SID    : S-1-5-21-...-1105 (jdoe)        │
                  │ Group SIDs  : S-1-5-21-...-513 (Domain Users) │
                  │               S-1-5-32-544 (Administrators)   │
                  │               S-1-1-0 (Everyone)              │
                  │               S-1-5-11 (Authenticated Users)  │
                  │ Privileges  : SeChangeNotifyPrivilege (En)   │
                  │               SeDebugPrivilege (Disabled)     │
                  │ Integrity   : High (S-1-16-12288)             │
                  │ Token Type  : Primary                         │
                  │ Impersonation Level : SecurityImpersonation   │
                  └───────────────────────────────────────────────┘

When a process calls CreateProcess, the child process inherits a duplicate of the parent’s primary token by default.

2. Primary vs Impersonation Tokens

• Primary Token: Associated with the process. Applied to all threads unless thread-level impersonation is active.
• Impersonation Token: Applied to a specific thread to perform operations in the security context of a client:
  • SecurityAnonymous: Client identity is unknown.
  • SecurityIdentification: Server knows client identity and SIDs, but cannot access securable objects on its behalf.
  • SecurityImpersonation: Server can access local securable objects on behalf of the client.
  • SecurityDelegation: Server can access remote network resources on behalf of the client (requires Kerberos delegation).

---

What Is Possible

• Duplicating Tokens Across Processes: Using DuplicateTokenEx, an elevated process can copy a token from another session and spawn processes under that user identity.
• Enabling Disabled Privileges: If a privilege is present in a token with the Disabled flag, the process can enable it on demand via AdjustTokenPrivileges.
• Dropping Privileges (Restricted Tokens): Sandboxed applications (e.g., Chrome, Edge) can strip groups and privileges to spawn child processes at Low Integrity.

---

What Is Not Possible

• Injecting New SIDs into an Active Token: Once created by LSASS, the SID array within a token is immutable. Gaining new group memberships requires creating a new logon session.
• Writing Objects Under Identification Level: The SRM strictly blocks access requests requiring write permissions if the thread’s impersonation level is below SecurityImpersonation.
• Reaching Network Hosts with a Stolen Local Token: A stolen access token lacks Kerberos session keys and cannot traverse to remote machines without explicit delegation.

---

Forensic Traps

Common Investigation Mistakes

1. Assuming Process Identity Equals Thread Identity: Investigating a malicious file write attributed to svchost.exe (SYSTEM) can conceal token impersonation where an individual thread was impersonating a compromised user.
2. Overlooking UAC Filtering: Standard interactive logons for administrators run under a filtered Medium Integrity token where BUILTIN\Administrators is marked SE_GROUP_USE_FOR_DENY_ONLY.

---

Concrete DFIR Scenario: Named Pipe Impersonation

1. An adversary compromises an IIS application running under IIS APPPOOL\DefaultAppPool.
2. Execution of whoami /priv reveals SeImpersonatePrivilege : Enabled.
3. The attacker deploys PrintSpoofer or SweetPotato.
4. The tool creates a local named pipe (\\.\pipe\spoolss) and triggers the print spooler service (SYSTEM) to validate an RPC binding against it.
5. When the spooler connects, the exploit calls ImpersonateNamedPipeClient().
6. The thread adopts the spooler’s SYSTEM token and calls CreateProcessWithTokenW() to spawn an interactive shell with full SYSTEM authority.

---

Forensic Artifacts

EventID: 4672 # Special Privileges Assigned to New Logon
SubjectUserName: Administrator
PrivilegeList:
  SeDebugPrivilege
  SeImpersonatePrivilege
  SeTcbPrivilege

Sysmon EventID 10 # Process Access (Token Duplication)
SourceImage: C:\Users\Public\mimikatz.exe
TargetImage: C:\Windows\System32\lsass.exe
GrantedAccess: 0x1410 # PROCESS_VM_READ | PROCESS_QUERY_INFORMATION

---

Key Takeaways

1. The Windows kernel authorizes processes and threads via tokens, not usernames.
2. Tokens are snapshot copies of SIDs and privileges frozen at authentication time.
3. SeImpersonatePrivilege allows service accounts to escalate directly to SYSTEM.
4. UAC splits administrative tokens into Medium (filtered) and High (elevated) pairs.

---

Cross References

• Doc 05: Authentication vs Authorization
• Doc 09: Privileges vs Permissions