T1134.003: Make and Impersonate Token
Adversaries may make new tokens and impersonate users to escalate privileges and bypass access controls. For example, if an adversary has a username and password but the user is not logged onto the system the adversary can then create a logon session for the user using the `LogonUser` function.[1] The function will return a copy of the new session's access token and the adversary can use `SetThreadToken` to assign the token to a thread.
This behavior is distinct from Token Impersonation/Theft in that this refers to creating a new user token instead of stealing or duplicating an existing one.
Analyst context for executives and security teams
Make and Impersonate Token is a Windows privilege-escalation and stealth behavior where an adversary with valid credentials can create a new logon session and use that session’s access token to operate as that user. The business issue is not just credential theft; it is whether Windows identity activity can be trusted once an attacker can create and apply a user security context without the user already being logged in.
Executive priority
Prioritize this as an identity and Windows endpoint control-validation issue. Leaders should ask whether privileged and sensitive accounts are tightly managed, whether SOC/IR teams can reconstruct unusual logon-session and token-use behavior, and whether evidence exists for audit and incident response when a process begins acting under a different user context. The ATT&CK relationships to FIN13, BlackByte, Cobalt Strike, SILENTTRINITY, and Mafalda show this behavior is relevant across financially motivated groups and post-exploitation tooling, but the supplied data does not establish current activity or exposure in any specific environment.
Technical view
This sub-technique belongs under Access Token Manipulation and applies to Windows. The supplied ATT&CK description specifically references creating a logon session with LogonUserW and assigning the resulting token with SetThreadToken. SOC and detection teams should validate behavior-chain coverage, especially where DET0498 is used as the detection strategy reference: credential use or new logon-session creation followed by a process or thread operating under that token. IR teams should be prepared to correlate account, process, and host timelines rather than treating logon events or process events in isolation.
Likely telemetry
- Windows logon-session and authentication audit data showing new user sessions created on a host
- Endpoint process telemetry for processes active before and after the suspicious logon/session change
- API-level or EDR telemetry, where available, for LogonUserW and SetThreadToken usage
- Account context and privilege information for the user whose token is created or impersonated
- Host-based security logs that support reconstruction of user context, process lineage, and timing
Detection direction
- Validate whether DET0498-style behavior-chain analytics exist for Windows hosts instead of relying on single events.
- Correlate new logon-session creation with subsequent process or thread activity under the newly created token.
- Tune carefully for legitimate administrative, service, and application behavior that may create logon sessions or impersonate users.
- Prioritize higher-risk detections when privileged accounts or sensitive business systems are involved.
- Check blind spots where endpoint telemetry lacks API visibility, thread-token context, or reliable process-to-user correlation.
Mitigation priorities
- Apply User Account Management: keep account lifecycle, deactivation, and privilege assignment current so unused or overprivileged credentials cannot easily support token creation.
- Apply Privileged Account Management: restrict and monitor privileged accounts, enforce least privilege and role-based access, and ensure privileged use is accountable in logs.
- Reduce standing privilege on Windows systems so a created token provides less operational reach.
- Ensure administrative and service-account practices are documented and reviewable so detection teams can distinguish expected impersonation from suspicious behavior.
Analyst notes and limits
This take is based on ATT&CK T1134.003 version 2.0 in enterprise-attack, its Windows platform scope, its stealth and privilege-escalation tactics, the Microsoft LogonUserW reference, and the supplied relationships to DET0498, M1018, M1026, parent technique T1134, groups, and software.
ATT&CK provides no official detection text for this object in the supplied fields. Telemetry and detection guidance therefore must be validated against local Windows logging, EDR capability, account model, and administrative workflows. The related groups and software indicate documented ATT&CK use relationships only; they do not prove active exploitation or customer-specific risk.
Make and Impersonate Token
Adversaries may make new tokens and impersonate users to escalate privileges and bypass access controls. For example, if an adversary has a username and password but the user is not logged onto the system the adversary can then create a logon session for the user using the `LogonUser` function.[1] The function will return a copy of the new session's access token and the adversary can use `SetThreadToken` to assign the token to a thread.
This behavior is distinct from Token Impersonation/Theft in that this refers to creating a new user token instead of stealing or duplicating an existing one.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1134 | Access Token Manipulation | This object subtechnique of Access Token Manipulation. |
Groups, software, and campaigns
G1043: BlackByte
BlackByte is a ransomware threat actor operating since at least 2021. BlackByte is associated with several versions of ransomware also labeled BlackByte Ransomware. BlackByte ransomware operations initially used a common encryption key allowing for the development of a universal decryptor, but subsequent versions such as BlackByte 2.0 Ransomware use more robust encryption mechanisms. BlackByte is notable for operations targeting critical infrastructure entities among other targets across North America.[1][2][3][4][5]
G1016: FIN13
S1060: Mafalda
S0692: SILENTTRINITY
SILENTTRINITY is an open source remote administration and post-exploitation framework primarily written in Python that includes stagers written in Powershell, C, and Boo. SILENTTRINITY was used in a 2019 campaign against Croatian government agencies by unidentified cyber actors.[1][2]
S0154: Cobalt Strike
Cobalt Strike is a commercial, full-featured, remote access tool that bills itself as “adversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors”. Cobalt Strike’s interactive post-exploit capabilities cover the full range of ATT&CK tactics, all executed within a single, integrated system.[1]
In addition to its own capabilities, Cobalt Strike leverages the capabilities of other well-known tools such as Metasploit and Mimikatz.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 2e9c2b903277… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
LogonUserW function
Microsoft. (2023, March 10). LogonUserW function (winbase.h). Retrieved January 8, 2024.
Open source URL -
[2]
mitre-attack T1134.003Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.