Detecting and Mitigating Access Token Manipulation (T1134)

On Windows, every process runs with an access token. The token says whose process it is and what it may do. T1134, Access Token Manipulation, is MITRE's umbrella for adversaries changing or borrowing those tokens so that a process acts as someone else.

It is listed under the stealth and privilege escalation tactics and applies to Windows. Five sub-techniques cover the specific methods, and this post gives the shared picture.

How attackers use it

MITRE explains that a user can manipulate tokens to make a running process look like the child of a different process, or like it belongs to someone other than the user who started it. The process then takes on the security context of the new token.

Key points from the page:

• Token stealing. Built-in Windows API functions can copy tokens from existing processes. The copy can be applied to an existing process (Token Impersonation/Theft, T1134.001) or used to start a new one (Create Process with Token, T1134.002).
• Administrator first. Stealing a token requires an administrator context. Adversaries commonly use it to climb from administrator to SYSTEM. With the right permissions, a token can then be used to authenticate to a remote system as that account.
• Low barrier variants. Any standard user can use runas and Windows API functions to create impersonation tokens, with no administrator account needed. Other mechanisms, such as Active Directory fields, can also change tokens.

The other three sub-techniques are making and impersonating a token (T1134.003), parent PID spoofing (T1134.004) and SID-History injection (T1134.005).

MITRE's page lists many tools and malware that use token manipulation, such as Empire, PowerSploit, BlackCat and Cuba.

How to detect it

MITRE's detection strategy for Windows is a chain:

1. Use of token-related APIs, for example LogonUser or DuplicateTokenEx, or commands such as runas.
2. A new process under a different security context, for example SYSTEM.
3. A mismatch in parent and child lineage, or anomalies in Event Tracing for Windows token and parent process data.
4. Abnormal lateral movement or privilege escalation after.

You will rarely see the API calls without an endpoint product that records them. What every defender can see is the result: a process whose user or integrity level differs from its parent for no good reason. Process creation logs with the creator and the new process user (Security event 4688, Sysmon event ID 1) make that comparison possible. Logon events (Security 4624) help for the remote side.

How to reduce the risk

MITRE's two mitigations are about who may do this at all.

1. User account management. The adversary needs administrator access on the local system to use this fully, so restrict users and accounts to the privileges they need.
2. Privileged account management. Limit permissions so that users and groups cannot create tokens. This should be defined for the local system account only. The setting is in Group Policy under Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, User Rights Assignment, as "Create a token object". MITRE also advises defining who can create a process level token to only the local and network service accounts.

In plain terms, fewer local administrators means fewer places where this works.

Check your own environment

Read-only commands on a Windows host:

whoami /priv
whoami /groups

These show the privileges and group memberships of the current context. Run them from an ordinary account and an elevated one to see the difference.

Then ask three questions of your logging:

• Do you record process creation with command line (4688 with command line auditing, or Sysmon)?
• Can you compare a new process's user to its parent's?
• Who has the "Create a token object" right? The answer should be short.

Quick check

Sources

• MITRE ATT&CK, T1134 Access Token Manipulation