03. Access Token Impersonation
Overview¶
Windows access tokens define the security context under which a process or thread operates. They contain information such as the associated user, groups, privileges, and security identifiers.
Access Token Impersonation is a post-exploitation technique in which an existing access token is used to execute actions under another security context.
The examples below are based on a controlled Windows lab environment using Metasploit/Meterpreter.
Windows Access Tokens¶
Windows access tokens are created and managed as part of the Windows authentication process, primarily through the Local Security Authority Subsystem Service (LSASS).
A token can be thought of as a security identity attached to a process or thread:
User Authentication
|
v
Access Token
|
+---- User identity
+---- Groups
+---- Privileges
+---- Security information
|
v
Process / Thread
When a user successfully authenticates, Windows creates a token representing that user's security context. Processes created under that context normally inherit the token.
Token Types¶
Access tokens relevant to impersonation can broadly be divided into two categories.
Impersonation Tokens¶
Impersonation tokens allow a process or thread to temporarily operate under another security context.
They are commonly associated with services and other non-interactive authentication scenarios.
Delegation Tokens¶
Delegation tokens are associated with interactive authentication and can potentially be used to authenticate to other systems.
For an attacker who already has code execution, delegation tokens can therefore be particularly valuable.
Required Windows Privileges¶
Successful token impersonation depends heavily on the privileges available to the current process.
Important privileges include:
SeAssignPrimaryTokenPrivilege¶
Allows a process to replace the primary token associated with another process.
SeCreateTokenPrivilege¶
Allows creation of a token with a specified security context.
SeImpersonatePrivilege¶
Allows a process to impersonate the security context represented by an impersonation token.
This privilege is especially important in many Windows privilege-escalation scenarios.
Initial Access in the Lab¶
The screenshots show a Windows host exposing several services:
The HTTP service was running Rejetto HFS.
Metasploit can be searched for the corresponding module:
Example result:
In a lab, the module can be selected and its options inspected:
msf6 > use exploit/windows/http/rejetto_hfs_exec
msf6 exploit(windows/http/rejetto_hfs_exec) > show options
The relevant target configuration shown in the lab is:
The payload configuration uses a Meterpreter reverse TCP session.
Once the controlled lab exploit succeeds, Meterpreter reports a session:
The important point is that initial access and token impersonation are separate stages.
Inspecting the Meterpreter Session¶
After obtaining a Meterpreter session, basic system information can be checked:
The screenshots show a Windows system and an x86 Meterpreter session.
The current security context can be checked with:
Example:
This tells us that the Meterpreter process is initially running in the context of LOCAL SERVICE.
Checking Process Privileges¶
The current process privileges can be examined with:
An example initial privilege set contains:
SeAssignPrimaryTokenPrivilege
SeAuditPrivilege
SeChangeNotifyPrivilege
SeCreateGlobalPrivilege
SeImpersonatePrivilege
SeIncreaseQuotaPrivilege
SeIncreaseWorkingSetPrivilege
SeSystemtimePrivilege
SeTimeZonePrivilege
The presence of:
is particularly relevant when studying token impersonation.
The Incognito Extension¶
Meterpreter provides the incognito extension for working with Windows access tokens.
Load it with:
Once loaded, the token-related commands become available.
The extension can enumerate available tokens:
Example output from the lab:
Delegation Tokens Available
========================================
ATTACKDEFENSE\Administrator
NT AUTHORITY\LOCAL SERVICE
Impersonation Tokens Available
========================================
No tokens available
This indicates that an Administrator delegation token is present and can be examined in the context of the lab.
Impersonating an Administrator Token¶
The token can be selected with:
A successful result looks like:
The current identity can then be verified:
Expected result:
The important concept here is that the Meterpreter process has changed its effective security context without obtaining the Administrator password.
Why Process Migration Matters¶
Token impersonation is tied to the process/thread security context. Process migration can therefore change which token and privileges are available.
For example, the lab initially identifies an Explorer process:
An attempted migration may fail:
After successfully impersonating an appropriate token, migration into an accessible process may succeed:
The exact result depends on the Windows version, process permissions, token type, and security controls.
Verifying the New Security Context¶
After impersonation and migration, check the identity again:
The lab demonstrates:
Privileges can then be inspected:
The resulting privilege set is substantially larger and includes privileges such as:
SeBackupPrivilege
SeCreatePagefilePrivilege
SeDebugPrivilege
SeImpersonatePrivilege
SeLoadDriverPrivilege
SeManageVolumePrivilege
SeRestorePrivilege
SeSecurityPrivilege
SeTakeOwnershipPrivilege
SeSystemEnvironmentPrivilege
This illustrates the difference between the original service account context and the Administrator security context.
Enumerating Additional Tokens¶
After moving into a more privileged process, list_tokens can reveal additional security contexts:
The lab demonstrates tokens such as:
Delegation Tokens Available
========================================
ATTACKDEFENSE\Administrator
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\SYSTEM
Window Manager\DWM-1
Impersonation Tokens Available
========================================
Font Driver Host\UMFD-0
Font Driver Host\UMFD-1
NT AUTHORITY\NETWORK SERVICE
The presence of:
is significant because SYSTEM is one of the highest-privileged local security contexts in Windows.
SYSTEM Token Demonstration¶
In the controlled lab, the SYSTEM token can be selected using:
A successful operation reports:
The identity can then be verified:
Result:
And the available privileges can be inspected again:
The lab shows a much larger set of SYSTEM-level privileges.
Important Concept¶
The overall attack chain demonstrated in the lab is:
Vulnerable Service
|
v
Initial Code Execution
|
v
Meterpreter Session
|
v
Identify Current User
|
v
Check Process Privileges
|
v
Find Available Access Tokens
|
v
Impersonate Suitable Token
|
v
Migrate When Required
|
v
Verify Security Context
The key lesson is that having code execution does not automatically mean having administrative privileges.
The security context of the compromised process determines what can be accessed. If a privileged token is available to a process and the process has the necessary Windows privileges, token impersonation may allow the process to operate under that more privileged identity.
Useful Meterpreter Commands¶
sysinfo
getuid
getprivs
pgrep explorer
migrate <PID>
load incognito
list_tokens -u
impersonate_token "<DOMAIN>\<USER>"
Defensive Perspective¶
Token impersonation is important for defenders because compromised service accounts with powerful privileges can become a path toward privilege escalation.
Useful defensive measures include:
-
Apply the principle of least privilege to service accounts.
-
Avoid granting
SeImpersonatePrivilegeunnecessarily. -
Keep Windows and exposed applications patched.
-
Monitor suspicious process creation and process migration behavior.
-
Monitor unusual use of privileged tokens.
-
Restrict unnecessary network-facing services.
-
Use modern endpoint detection and response controls.
-
Investigate unexpected transitions from service accounts to Administrator or SYSTEM contexts.
Conclusion¶
Windows access token impersonation demonstrates how security context can be more important than the initial account obtained during exploitation. By examining privileges and available tokens, a compromised process may be able to operate under a more privileged identity.
The lab demonstrated the progression from an initial service-level Meterpreter session to identifying available delegation tokens, impersonating privileged identities, and verifying the resulting security context.
Understanding access tokens, Windows privileges, and token exposure is essential for both penetration testers and defenders, as the same weaknesses that enable privilege escalation can be mitigated through least privilege, proper service-account configuration, patching, and monitoring of suspicious token and process activity.