Token Impersonation

What is

A Windows access token is a security object that represents the security context of a process or thread.

It contains information such as the security identifier (SID) of the user, group memberships, privileges, and other security attributes used by Windows to determine what resources and actions the process is allowed to access.

Windows can create different types of tokens depending on how authentication takes place.

A delegation token is associated with an interactive logon where the user’s credentials can potentially be delegated to another service. A primary token is normally associated with a process, while an impersonation token allows a thread to temporarily act in the security context of another user.

Token impersonation attacks take advantage of tokens that are already present on a compromised Windows machine.

If an attacker obtains sufficient privileges to access and impersonate another user’s token, the attacker may be able to execute actions using that user’s security context without knowing the user’s password.

This can be particularly useful when a privileged user has authenticated to a compromised machine and their token is still available.

The important point is that token impersonation does not recover the user’s password or NTLM hash. Instead, the attacker abuses an existing Windows authentication context.

Requirements

For token impersonation to work, the following conditions generally need to be met:

• Access to a compromised Windows machine.

• Sufficient privileges to enumerate and impersonate available tokens.

• A user with a useful token present on the target machine.

• The target token must provide privileges or group memberships that are useful to the attacker.

• The compromised machine must allow the required token operations.

A common lab scenario is a compromised machine where a privileged domain user has previously authenticated.

Having a token present does not automatically mean that it can be successfully impersonated. The attacker’s current privileges and the type of token available are important factors.

How to

Summary

The basic workflow is:

load incognito
list_tokens -u

impersonate_token <USER_WITH_DOUBLE_BACKSLASH>

Detailed

1. Obtain a privileged Meterpreter session

The first step is to obtain a Meterpreter session on the target machine.

For this technique, the session should have sufficient privileges to interact with other users’ tokens. In a typical lab scenario, this is achieved by obtaining a session running as NT AUTHORITY\SYSTEM.

A module such as exploit/windows/smb/psexec can be used in an appropriate authorized lab environment.

When configuring the exploit, make sure that the selected payload provides a Meterpreter session rather than a standard command shell.

Once the session has been established, verify the current security context before continuing.

This is important because token manipulation requires appropriate privileges. A normal user session will generally not be able to enumerate or impersonate arbitrary tokens belonging to other users.

2. Load the Incognito extension

Once the Meterpreter session has been obtained, load the incognito extension. The extension provides commands for interacting with Windows access tokens.

load incognito

After loading the extension, enumerate the available user tokens.

list_tokens -u

The output may contain tokens belonging to local users as well as domain users.

Pay particular attention to tokens belonging to privileged accounts, such as members of privileged Active Directory groups.

The presence of a token does not necessarily mean that the associated user is currently logged in interactively. Tokens can also be created as a result of other authentication mechanisms and Windows operations.

3. Identify a useful token

Review the tokens returned by the enumeration.

For example, a token belonging to a domain administrator or another privileged account may provide a significant increase in privileges if it can be successfully impersonated.

It is important to distinguish between the username associated with a token and the permissions actually available through that token.

A token belonging to a normal domain user may provide little or no additional access.

A token belonging to a highly privileged account may allow access to resources that the original compromised account could not access.

4. Impersonate the token

Once a useful token has been identified, use the Meterpreter token impersonation functionality to switch the current security context to that user.

The token name must be specified using the format returned by the token enumeration command.

impersonate_token <USER>

In some cases, domain and username values contain backslashes. These must be handled correctly when providing the token identifier to Meterpreter.

If the operation succeeds, subsequent actions performed through the affected Meterpreter context may use the security context represented by the impersonated token.

The success of the operation does not necessarily mean that every process on the system has changed identity. Token impersonation applies to the relevant thread or process context, depending on how the operation is performed.

5. Verify the impersonated context

After impersonating the token, verify the current security context.

The goal is to confirm that the session is now operating with the identity and group memberships associated with the selected token.

This verification is important because successfully obtaining a token and successfully impersonating it are separate steps.

The resulting privileges should also be validated against the intended objective. For example, a domain user’s token may authenticate successfully but still lack local administrator or domain-level privileges.

Understanding the attack

The attack can be represented as:

Privileged User authenticates
            |
            v
      Windows creates
       access token
            |
            v
   Token remains available
     on compromised host
            |
            v
   Attacker obtains privileged
      session on the host
            |
            v
   Enumerate available tokens
            |
            v
     Impersonate token
            |
            v
 Execute actions using the
 impersonated security context

Windows uses access tokens to determine the security context under which processes and threads operate.

An access token contains information used by the operating system to make authorization decisions. This includes the user’s SID, group SIDs, privileges, and other security information.

When a user authenticates to a Windows machine, Windows can create a security token associated with that logon session.

If a privileged user has authenticated to a compromised machine, an attacker with sufficient privileges may be able to interact with that token.

The attacker does not need to know the user’s password because the authentication context already exists on the machine.

The important distinction is between credentials and tokens.

With credential theft, the attacker attempts to obtain material such as passwords, NTLM hashes, Kerberos tickets, or other authentication secrets.

With token impersonation, the attacker instead abuses an existing Windows security context.

The attack therefore depends heavily on where privileged users authenticate.

For example, if an administrator authenticates to a workstation that is subsequently compromised, the administrator’s token may become an important privilege-escalation target.

The effectiveness of the technique depends on several factors:

• Whether a useful token is present.

• Whether the attacker has sufficient privileges to access or impersonate it.

• The type of token available.

• The privileges and group memberships represented by the token.

• The resources that the impersonated identity can access.

• Windows security controls and restrictions affecting token manipulation.

Token impersonation also does not automatically grant Domain Administrator privileges.

The resulting access is determined by the identity represented by the token and the permissions associated with that identity.

Common problems

No useful tokens are available

If token enumeration only returns the current user or low-privileged accounts, there may not be a privileged user currently authenticated to the machine.

Token impersonation cannot create a privileged identity that does not already exist.

In this situation, the attacker would need to identify another machine or user session where a more privileged account has authenticated.

The Incognito extension cannot be loaded

Verify that the session is a Meterpreter session and that the payload is compatible with the target architecture.

Also verify that the current session has sufficient privileges to perform the required token operations.

A standard command shell does not provide the same token-manipulation functionality as Meterpreter with the incognito extension.

Token enumeration does not show the expected user

The presence of a user on the network does not mean that their token is available on the compromised machine.

The user must have authenticated to that specific host in a way that resulted in a token accessible to the current context.

Check whether the privileged user actually logged on to the target machine and whether their session is still active.

Token impersonation fails

A token may be visible during enumeration but still be unusable for the intended operation.

Check:

• The privileges of the current Meterpreter session.

• The type of token being targeted.

• Whether the token is still valid.

• Whether the token belongs to the expected user.

• Whether Windows security controls prevent the required operation.

Impersonation succeeds but access does not change

Successfully impersonating a token does not guarantee that the resulting identity has the permissions expected by the attacker.

Verify the effective user identity and group memberships after impersonation.

Also remember that access is determined by the permissions associated with the impersonated identity and the specific resource being accessed.

Defensive considerations

Token impersonation is closely related to the broader problem of privileged users authenticating to compromised or untrusted systems.

Important defensive measures include:

• Prevent privileged administrators from logging into ordinary workstations whenever possible.
• Use dedicated administrative accounts for privileged operations.
• Apply the principle of least privilege.
• Restrict local administrator privileges on workstations.
• Use controls such as Windows Defender Credential Guard where appropriate.
• Enable protections such as LSASS protection where supported and appropriate.
• Use privileged access workstations for sensitive administrative operations.
• Monitor privileged account logons to workstations and servers.
• Monitor for unusual token manipulation and privilege-escalation activity.
• Reduce the number of systems where highly privileged accounts are allowed to authenticate.

One of the most important defensive principles is to prevent privileged credentials and authentication contexts from being unnecessarily exposed to compromised machines.

Even if an attacker cannot recover the administrator’s password, an existing privileged token may provide an alternative path to elevated access.