Token Impersonation/Theft, T1134.001, is a sub-technique of Access Token Manipulation. The adversary duplicates another user's existing token and then impersonates it. MITRE files it under stealth and privilege escalation, and it applies to Windows.
How attackers use it
MITRE describes the sequence in terms of Windows API calls. An adversary can duplicate a token with DuplicateToken or DuplicateTokenEx. The duplicate can then go to ImpersonateLoggedOnUser, which lets the calling thread impersonate a logged-on user's security context, or to SetThreadToken, which assigns the impersonated token to a thread.
When is this useful? MITRE gives one case: the adversary has a specific, existing process in mind and wants to assign the duplicated token to it, for example when the target user has a non-network logon session on the system.
Three neighbors are easy to confuse with it:
- If the adversary wants a brand new process with the duplicated token, that is Create Process with Token (T1134.002), using
CreateProcessWithTokenWorCreateProcessAsUserW. - If the adversary creates a new token rather than duplicating an existing one, that is Make and Impersonate Token (T1134.003).
- Both sit under the parent, T1134, Access Token Manipulation.
Because the token comes from a process that already exists, the adversary does not need that user's password. They do need enough rights on the host to reach the token, which usually means administrator.
MITRE's page lists many tools and malware families, including Cobalt Strike, Emotet and Havoc.
How to detect it
MITRE's behavior chain for Windows correlates three things:
- A suspicious command line such as
runas, or an in-memory call into the token APIs. - Token handle duplication or a thread token assignment, using
DuplicateToken,DuplicateTokenEx,ImpersonateLoggedOnUserorSetThreadToken. - A new or existing process then running in the impersonated user's context.
Most teams cannot see API calls directly. Endpoint detection tools and ETW providers can. If you have neither, you can still watch for the outcome: processes running as an account that did not start them. Process creation logs (Security 4688, Sysmon event ID 1) carry the user and the parent, and Sysmon event ID 10 (process access) shows when one process opens another with rights that allow token access.
How to reduce the risk
The mitigations MITRE lists are two forms of least privilege.
- User account management. The adversary needs administrator access on the local machine to make full use of this technique. Restrict users and accounts to the privileges they require. Few local admins, few chances.
- Privileged account management. Limit permissions so users and groups cannot create tokens. The Group Policy setting is Create a token object, defined for the local system account only. Also restrict who can create a process level token to the local and network service accounts.
Check your own environment
whoami /priv
On a Windows host, this lists the privileges the current context holds. Compare a standard user session with an elevated one, and note any service account that holds powerful privileges it does not need.
Then check these points in your own setup:
- Which accounts are local administrators on servers? Remove day to day users from that list.
- Is Sysmon or an endpoint product recording process access and creation on servers that hold privileged sessions, such as jump hosts?
- Do admins log in interactively to ordinary workstations? Each such session leaves a token worth stealing.
Quick check
How does token theft differ from making a token?
Theft duplicates an existing token. Making a token creates a new one, for example with a known username and password through a new logon session.
Which API call assigns an impersonated token to a thread?
SetThreadToken.
Sources
- MITRE ATT&CK, T1134.001 Token Impersonation/Theft
