Make and Impersonate Token is a Windows privilege that allows a process to create a token and impersonate another security context. Attackers abuse it to run code with higher privileges or move laterally after compromise. Defenders should restrict the right, audit which accounts hold it, and watch for suspicious token manipulation.
What the right means in Windows security
Make and Impersonate Token is not just another access right, it is a powerful Windows privilege that lets a process create a token and act under another security context. That makes it a direct path to privilege escalation when a compromised account or service can mint or borrow authority it should not have.
The risk is not limited to the immediate host. Once a process can impersonate another context, the attacker may inherit permissions, reach protected resources, or pivot into adjacent systems that trust that context.
How it is abused after compromise
In practice, this right is attractive because it can turn a foothold into broader control without needing to crack every downstream system individually. Attackers may use token manipulation to run commands as a more privileged user, impersonate a service account, or blend into a legitimate workflow while they move laterally.
MITRE ATT&CK Enterprise is useful here because token impersonation and related access-token manipulation techniques sit squarely in the credential and lateral-movement portion of the adversary playbook. The right becomes especially dangerous when paired with stolen credentials, service abuse, or post-exploitation tooling that already has local execution.
Defenders should think of it as a privilege boundary problem, not merely an authorization setting. If a low-trust process can manufacture or inherit a higher-trust context, the host has effectively lost part of its separation model.
Where organisations should look for exposure
Exposure usually starts with account hygiene and entitlement review. Any account, service, or application granted this right deserves explicit justification, because its misuse can bypass normal application-layer permissions and make compromise much more damaging than a standard local execution issue.
NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with reviewing this privilege through access control, authentication, audit, and configuration controls. Organisations should also examine whether the right is present on endpoints that are already exposed to remote administration, automation, or high-value service accounts.
NIST Cybersecurity Framework 2.0 supports the broader governance question of who is allowed to hold sensitive privileges, how that exposure is identified, and how detection coverage is maintained over time.
Why detection and recovery matter after use
Token abuse often leaves only subtle traces, so defenders need to look for the behaviour around the privilege, not just the privilege itself. Suspicious logons, abnormal parent-child process chains, unusual access to administrative resources, and token-related activity from unexpected hosts are all useful signals.
After a suspected misuse event, the key question is not only whether the process was stopped, but whether the attacker already used the impersonated context to create persistence, steal data, or plant additional access. A clean-looking host can still hide a compromised trust path if the impersonated identity was used to open new sessions or issue further credentials.
NIST Privacy Framework is not a primary fit for the privilege itself, but it is relevant where token abuse exposes personal data or regulated records through impersonated access.
Risk and Threat Considerations
This privilege creates high-consequence exposure because a single local compromise can become a trusted impersonation event. If attackers reach a process with token creation and impersonation ability, they can often escalate quietly, reuse legitimate paths, and make later detection harder than with noisier exploit chains.
Failure mechanism: A process with this right can mint or assume a token that carries more authority than the original context, defeating the intended separation between ordinary execution and privileged access.
Impact: Attackers may escalate privileges, move laterally, access protected resources, or preserve access through impersonated sessions that appear legitimate to downstream systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1134 — Access Token Manipulation | Token impersonation is a core ATT&CK access-token manipulation technique. |
| Recommendation — Map suspicious token use to T1134 and hunt for privilege escalation and lateral movement. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | This privilege should be tightly limited under least-privilege access control. |
| AU-2 — Event Logging | Suspicious token creation and impersonation require auditable security events. | |
| AU-12 — Audit Record Generation | Token abuse is best detected when relevant events are actually generated. | |
| Recommendation — Restrict this right to only the accounts that truly require it. Log token-related activity and review anomalous impersonation attempts. Enable generation of audit records for token and logon activity tied to privilege use. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | The right is an access-control exposure that must be governed and monitored. |
| Recommendation — Review privileged access assignments and remove unnecessary holders of this right. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a high-value privilege rather than a routine permission. If the right is broadly assigned, the blast radius of any endpoint or service compromise expands well beyond the initial foothold.
What to watch for: Audit which accounts hold the right, confirm each one has a documented operational need, and verify that monitoring is tuned to flag token creation, impersonation, and unusual privilege transitions. The most useful stance is to minimise holders, constrain where it is granted, and investigate any unexpected use as a potential intrusion signal.
Related resources from NHI Mgmt Group
- Why do AI agents make traditional OAuth token handling riskier than normal application code?
- Why do AI and agentic workflows often make request-based gateway pricing less efficient than token-based models?
- Why do missing access controls and weak token handling make APIs a high-risk attack path?
- What mistakes do DeFi teams make when assessing token quality and protocol exposure?