AN1324: Analytic 1324
Detection of token duplication and impersonation attempts by correlating suspicious command-line executions (e.g., runas) with API calls to DuplicateToken, DuplicateTokenEx, ImpersonateLoggedOnUser, or SetThreadToken. The chain includes the initial command execution or in-memory API invocation → token handle duplication or thread token assignment → a new or existing process assuming the impersonated user's context.
Analyst context for executives and security teams
This analytic matters because Windows token duplication and impersonation can let activity run under another user’s security context, which can complicate accountability, privilege boundaries, and incident scoping. For leaders, the decision value is whether the organization can prove who executed sensitive actions when token impersonation is attempted, and whether SOC and IR teams can correlate command execution with lower-level Windows API behavior.
Executive priority
Prioritize this as an identity and incident-response visibility question for Windows environments. Security leaders should ask whether endpoint telemetry can connect suspicious command-line activity, such as runas usage, with token duplication or impersonation API calls. This supports operational resilience, audit evidence, and faster incident decisions when user context may not reflect the original actor or process.
Technical view
For SOC and detection engineering teams, validate whether Windows endpoint data can correlate process command lines or in-memory execution with calls to DuplicateToken, DuplicateTokenEx, ImpersonateLoggedOnUser, or SetThreadToken, followed by a process or thread assuming an impersonated user context. Because ATT&CK provides no separate detection text and no relationship context for this analytic, tuning should be based on local baselines for legitimate administrative tooling, service behavior, and applications that normally use impersonation.
Likely telemetry
- Windows process creation events with command-line arguments
- Endpoint telemetry for API calls involving token duplication or impersonation
- Process/thread context showing user identity changes or token assignment
- Parent-child process relationships around suspicious command execution
- Security or EDR records showing runas or similar credential-context execution
Detection direction
- Confirm that telemetry captures both command-line execution and relevant Windows API activity; either source alone may be insufficient for high-confidence correlation.
- Tune detections around the sequence described by the analytic: command execution or in-memory invocation, token duplication or assignment, then execution under the impersonated context.
- Baseline legitimate administrative, service, and application impersonation patterns to reduce false positives.
- Review blind spots where endpoint sensors do not expose API-level token activity or where command-line logging is incomplete.
- Because no ATT&CK relationships are supplied, do not assume linkage to a specific tactic, technique, threat actor, or campaign without local evidence.
Mitigation priorities
- Harden Windows identity and privilege practices so routine users and services do not hold unnecessary rights that make impersonation higher impact.
- Restrict and monitor administrative use of credential-context execution tools where operationally feasible.
- Ensure endpoint logging and EDR policies preserve process command line, parent process, user context, and token-related behavioral telemetry.
- Prepare IR playbooks to validate the original process, impersonated user context, and downstream actions when token impersonation is suspected.
- Use detection validation exercises to confirm the SOC can investigate token context changes, not just process names.
Analyst notes and limits
This is a detection analytic for Windows focused on correlating suspicious command-line execution with token duplication and impersonation API calls. The supplied ATT&CK object does not specify tactics, related techniques, mitigations, data components, or procedure examples, so the take is intentionally framed around telemetry validation and defensive decision-making rather than attribution or confirmed coverage.
Official detection text and relationship context were not supplied. The object supports Windows-only discussion and does not justify claims about active exploitation, adversary groups, impact, or guaranteed detectability. Local endpoint sensor capability and logging configuration are required to determine practical coverage.
Analytic 1324
Detection of token duplication and impersonation attempts by correlating suspicious command-line executions (e.g., runas) with API calls to DuplicateToken, DuplicateTokenEx, ImpersonateLoggedOnUser, or SetThreadToken. The chain includes the initial command execution or in-memory API invocation → token handle duplication or thread token assignment → a new or existing process assuming the impersonated user's context.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 1.0 | Current bundle | 75710d33d27e… |
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]
mitre-attack AN1324Open 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.