Overview

Token Impersonation/Theft (T1134.001) is a Windows privilege escalation technique in which an adversary duplicates an existing access token belonging to another user or process — typically one running with elevated privileges — and then impersonates that security context to bypass access controls. Using Windows API calls such as DuplicateToken, DuplicateTokenEx, ImpersonateLoggedOnUser, and SetThreadToken, an attacker can hijack the identity of a SYSTEM, Domain Admin, or other high-value account already active on the machine without needing that account’s credentials.

Because this technique operates entirely in memory using legitimate Windows APIs, it leaves minimal disk artifacts and can allow an attacker to silently move from a low-privileged foothold to full domain compromise. Every security team needs reliable detection for this technique because it is a standard post-exploitation step in frameworks like Cobalt Strike, Metasploit, and Mimikatz — meaning any environment with a persistent threat actor is likely to face it.

Attacker Perspective

Once an attacker has an initial foothold on a Windows system, token impersonation is one of the fastest paths to SYSTEM or Domain Admin privileges without touching credentials or triggering password-based detections.

• Cobalt Strike token stealing: The built-in steal_token <PID> command calls DuplicateTokenEx on a target process (e.g., a SYSTEM-level lsass.exe or winlogon.exe handle) and impersonates it within the Beacon thread, instantly elevating context without touching disk.
• Metasploit Incognito: The use incognito module followed by impersonate_token "DOMAIN\\Administrator" enumerates available tokens in running processes and duplicates the highest-privileged one, allowing the attacker to operate as a domain administrator from a low-privilege Meterpreter session.
• Mimikatz token elevation: token::elevate and token::impersonate commands duplicate a SYSTEM token from a privileged process and assign it to the current thread, giving the attacker SYSTEM-level access for subsequent credential dumping with sekurlsa::logonpasswords.
• Custom PowerShell or C# tooling: Attackers use reflectively loaded .NET assemblies or inline PowerShell calling [P/Invoke] wrappers around OpenProcessToken → DuplicateTokenEx → ImpersonateLoggedOnUser to avoid dropping known binaries, making signature-based detection ineffective.

This technique is attractive because it abuses fully legitimate Windows APIs, requires no new credentials, produces no new logon events in many configurations, and the impersonated identity can then be used for both local privilege escalation and lateral movement.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Audit Token Right Adjusted (Event ID 4703): Captures when a token privilege is enabled or disabled. Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Detailed Tracking → Audit Token Right Adjusted = Success, Failure. This is disabled by default and must be explicitly enabled.
• Windows Security Event Log — Audit Process Creation (Event ID 4688): Records new process creation with full command-line arguments (requires separate enablement). Enable command-line logging via GPO: Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events = Enabled. Without this, you cannot see what a spawned process was instructed to do.
• Windows Security Event Log — Audit Logon Events (Event ID 4624): Logon type 9 (NewCredentials) or type 3 (Network) events generated when impersonated tokens are used for network access. Enable via: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Logon/Logoff → Audit Logon = Success, Failure.
• Windows Security Event Log — Special Logon (Event ID 4672): Generated when an account with sensitive privileges (e.g., SeDebugPrivilege, SeImpersonatePrivilege) logs on or a token with these privileges is assigned. Enable via: Audit Special Logon = Success under Logon/Logoff audit policy.
• Windows Security Event Log — Privilege Use (Event ID 4673/4674): Captures use of sensitive privileges. Event ID 4673 is generated when a privileged service is called; 4674 when an attempt is made on a privileged object. Enable via: Advanced Audit Policy → Privilege Use → Audit Sensitive Privilege Use = Success, Failure. The privilege names to watch are SeDebugPrivilege, SeImpersonatePrivilege, and SeTcbPrivilege.
• Sysmon (System Monitor) — Event ID 10 (ProcessAccess): Critical for catching OpenProcessToken calls. Sysmon logs when one process opens a handle to another with specific access rights. Deploy Sysmon with a configuration that includes ProcessAccess rules targeting lsass.exe, winlogon.exe, and services.exe as target processes. The access mask 0x1400 (TOKEN_DUPLICATE | TOKEN_IMPERSONATE) is especially relevant.
• Sysmon — Event ID 1 (Process Create): Captures full process lineage including parent PID, command line, and user context. Needed to spot anomalous parent-child relationships when a stolen token is used to create a new process.
• Sysmon — Event ID 8 (CreateRemoteThread): Attackers sometimes inject threads into higher-privileged processes as part of token manipulation chains. Enable in Sysmon config with appropriate filters.
• Windows Defender / Microsoft Defender for Endpoint (MDE) API telemetry: If MDE is deployed, the DeviceEvents table in Advanced Hunting captures TokenImpersonation and PrivilegeEscalation action types natively, providing a high-fidelity supplementary source.
• EDR Process and API telemetry (CrowdStrike, SentinelOne, Carbon Black): Most EDR platforms capture API-level calls including DuplicateToken, DuplicateTokenEx, ImpersonateLoggedOnUser, and SetThreadToken. Ensure API telemetry is enabled in your EDR policy — this is the most direct detection source for this technique.

Key Indicators

• Sysmon Event ID 10 targeting LSASS or SYSTEM processes: In the Sysmon ProcessAccess event, check TargetImage = C:\Windows\System32\lsass.exe or C:\Windows\System32\winlogon.exe, and GrantedAccess containing 0x1400 or 0x1410 (TOKEN_DUPLICATE + TOKEN_QUERY + TOKEN_IMPERSONATE). The SourceImage field will reveal the process attempting the access.
• Event ID 4672 from unexpected accounts: If a standard user account or a service account that should never hold SeDebugPrivilege or SeImpersonatePrivilege appears in Event ID 4672, that is a high-confidence indicator. Check field SubjectUserName against your baseline of accounts permitted to hold these privileges.
• Event ID 4624 with Logon Type 9 (NewCredentials): A Logon Type 9 event (field LogonType = 9) from an unusual process or at an unusual hour indicates a new credential context being established, which is consistent with token duplication for network access. Correlate ProcessName in this event against known legitimate callers (e.g., runas.exe).
• Event ID 4703 showing SeImpersonatePrivilege enabled: If the EnabledPrivilegeList field in a 4703 event contains SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege for a process that is not a known service or IIS worker process, treat it as suspicious.
• Anomalous parent-child process relationships (Sysmon Event ID 1): A non-SYSTEM process spawning children that run under SYSTEM context is a strong behavioral indicator. Example: ParentImage = cmd.exe with IntegrityLevel = Medium spawning a child where IntegrityLevel = System. Check the User field mismatch between parent and child.
• Known tool command patterns (Event ID 4688 or Sysmon Event ID 1): Watch CommandLine for patterns associated with token manipulation tooling: token::elevate, token::impersonate, steal_token, impersonate_token, Invoke-TokenManipulation, or reflective loader patterns like -EncodedCommand followed by base64 blobs in a PowerShell process spawned from an unusual parent.
• EDR API telemetry — direct API calls: If your EDR exposes API-level visibility, look for DuplicateTokenEx or ImpersonateLoggedOnUser called from a process that is not lsass.exe, services.exe, a known AV/EDR process, or a documented Windows service. The calling process name and its parent are the key fields.
• Network connections following privilege change (Sysmon Event ID 3): A network connection event (Sysmon ID 3) from a process shortly after it was observed accessing LSASS or a privileged process can indicate that the stolen token is being used for lateral movement. Correlate by ProcessId and timestamp within a short window (e.g., 60 seconds).

Detection Logic

Rule 1 (Broad — High Sensitivity): Privileged Process Access from Non-System Process
IF EventID = 10 (Sysmon ProcessAccess)
AND TargetImage IN ["lsass.exe", "winlogon.exe", "services.exe"]
AND GrantedAccess IN ["0x1400", "0x1410", "0x1fffff"]
AND SourceImage NOT IN known_security_tools_whitelist
AND SourceUser NOT IN ["NT AUTHORITY\SYSTEM", "NT AUTHORITY\LOCAL SERVICE"]
THEN alert(severity=HIGH, rule="Suspicious Process Handle to Privileged Target")

This catches any process attempting to open a privileged process with token-related access rights. Expected volume is medium — will fire on some legitimate AV/EDR activity, so tuning against known security tools is essential before deploying. Start in monitor mode and baseline for 1–2 weeks.

Rule 2 (Medium — Privilege Escalation Behavioral): Unexpected SeImpersonatePrivilege Enabled
IF EventID = 4703 (Token Right Adjusted)
AND EnabledPrivilegeList CONTAINS ["SeImpersonatePrivilege", "SeAssignPrimaryTokenPrivilege", "SeTcbPrivilege"]
AND SubjectUserName NOT IN known_service_accounts_with_impersonate
AND ProcessName NOT IN ["iis", "w3wp.exe", "msdtc.exe", "sqlservr.exe", "spoolsv.exe"]
THEN alert(severity=HIGH, rule="SeImpersonatePrivilege Enabled for Non-Service Process")

This targets the privilege enablement step that precedes impersonation. Expected volume is low in tuned environments — service accounts running IIS, SQL Server, and print spooler legitimately hold SeImpersonatePrivilege and must be baselined out. High-confidence alert when it fires on interactive user sessions.

Rule 3 (Medium — Logon Anomaly): Unusual Logon Type 9 from Non-Standard Process
IF EventID = 4624 (Logon Success)
AND LogonType = 9
AND ProcessName NOT IN ["runas.exe", "mstsc.exe"]
AND LogonProcessName NOT IN ["seclogo", "Advapi"]
AND SubjectUserName NOT CONTAINS "$"
THEN alert(severity=MEDIUM, rule="Suspicious NewCredentials Logon - Possible Token Impersonation")

Logon Type 9 (NewCredentials) is consistent with token-based impersonation for network resource access. Legitimate sources include runas /netonly. False positive rate is low when filtered correctly; alert volume should be minimal in most environments.

Rule 4 (Narrow — High Precision): Known Token Theft Tool Signatures
IF EventID IN [4688, 1] (Process Create)
AND CommandLine MATCHES ["token::elevate", "token::impersonate", "steal_token", "Invoke-TokenManipulation", "impersonate_token"]
OR (CommandLine CONTAINS "-EncodedCommand" AND ParentImage IN ["cmd.exe", "powershell.exe"] AND IntegrityLevel = "System" AND ParentIntegrityLevel = "Medium")
THEN alert(severity=CRITICAL, rule="Known Token Manipulation Tool or Suspicious Privilege Escalation Chain")

This is a high-precision rule targeting explicit tool signatures and the specific behavioral pattern of a medium-integrity parent spawning a SYSTEM-level child. Expected volume is very low — near zero in a healthy environment. Any firing of this rule should be treated as a confirmed incident until proven otherwise.

Tuning Guidance

• IIS and Web Application Services: w3wp.exe and IIS worker processes legitimately hold SeImpersonatePrivilege for application pool impersonation. Exclude ProcessName IN ["w3wp.exe", "iisexpress.exe"] from Rule 2, but keep monitoring their network connections for unusual destinations.
• SQL Server: sqlservr.exe and SQL Agent (sqlagent.exe) use token impersonation for linked server connections and job execution under specific accounts. Exclude these known-good service accounts by adding SubjectUserName IN [sql_service_accounts] to your allowlist in Rule 2.
• Security and EDR tools: CrowdStrike Falcon (CSFalconService.exe), Carbon Black (cb.exe), Cylance, and Windows Defender Antivirus (MsMpEng.exe) all legitimately open handles to LSASS and other privileged processes for monitoring. Build a dynamic allowlist for your deployed security stack and exclude from Rule 1 using SourceImage NOT IN security_tool_whitelist. Validate this list quarterly.
• Print Spooler and RPC services: spoolsv.exe and COM/DCOM activation services (dllhost.exe) use impersonation in normal operation. Exclude SourceImage IN ["spoolsv.exe", "dllhost.exe"] from Sysmon-based rules but flag immediately if these processes establish outbound network connections, as that combination (legitimate impersonation + outbound network) may indicate PrintNightmare or similar exploitation.
• Backup agents: Enterprise backup solutions (Veeam, Veritas, Commvault) open privileged process handles during backup operations. Work with your backup team to identify service account names and process names, then exclude them with SourceImage IN [backup_agent_processes] AND SubjectUserName IN [backup_service_accounts].
• Scheduled task and remote management baseline: SCCM and Intune management processes may trigger Logon Type 9 events. Identify the management server IP ranges and service account names, then exclude with SubjectUserName IN [management_accounts] AND WorkstationName IN [management_servers] in Rule 3.

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists in the source log. Pull the exact raw event from your SIEM using the EventID, host, and timestamp from the alert. For Sysmon Event ID 10 alerts, confirm the GrantedAccess value and both SourceImage and TargetImage fields are present and match what triggered the rule — rule logic errors and data parsing issues can produce false alerts.
2. Identify the affected host and user — flag if privileged. Determine the hostname, IP address, and the user account context of the suspicious process from the SubjectUserName or User field in Windows Security Event Log or Sysmon Event ID 1. Cross-reference the account against your Active Directory privileged account inventory (Domain Admins, Enterprise Admins, service accounts) — if the source or target account is privileged, escalate immediately.
3. Pull the full command-line and parent process chain. Use Sysmon Event ID 1 or Windows Event ID 4688 (with command-line logging enabled) to reconstruct the full process tree: start from the suspicious process and walk backwards through ParentProcessId to identify the root of execution. Look for unusual parent processes (e.g., cmd.exe spawned by outlook.exe, or PowerShell spawned by a document viewer) that indicate the initial access vector.
4. Correlate Windows Security Events around the same timestamp. Pull Event IDs 4672, 4673, 4674, 4703, and 4624 from the Windows Security Event Log on the affected host within a ±5 minute window of the alert timestamp. Look for SeDebugPrivilege or SeImpersonatePrivilege appearing in the PrivilegeList fields — this confirms privilege use and narrows whether token duplication was actually exercised versus merely attempted.
5. Check for network connections and files written to disk from the suspicious process. Use Sysmon Event ID 3 (NetworkConnect) filtered by the ProcessId of the suspicious process to identify any outbound connections made after the token access event. Use Sysmon Event ID 11 (FileCreate) and Event ID 15 (FileCreateStreamHash) to detect any payloads, tools, or output files written to disk — pay particular attention to %TEMP%, %APPDATA%, C:\Windows\Temp, and C:\ProgramData.
6. Look for lateral movement originating from this host. Query your SIEM for Windows Event ID 4624 (Logon Type 3 — Network) and Event ID 4648 (Explicit Credential Logon) on remote hosts where the SubjectUserName or IpAddress matches the compromised host or account, within 1 hour after the initial alert. In Sysmon, check for SMB or WMI-related network connections (Sysmon Event ID 3) to internal hosts on ports 445, 135, 5985, or 3389 originating from the affected system.
7. Escalation decision — determine whether this is a confirmed incident or a benign event. The alert is a confirmed incident requiring full IR response if any of the following are true: the source process is not in your approved whitelist, a known attack tool signature (Mimikatz, Cobalt Strike, Metasploit) is present in the command line or file hashes, privilege-sensitive events (4672/4673) correlate with the process, or outbound network connections or lateral movement are observed. Treat it as benign or a false positive only if the source process is a verified, whitelisted security or backup tool, no anomalous child processes or network connections exist, and the account and host match a known, documented maintenance window.

Response Playbook

Containment

• Isolate the host at the network level — but do not power it off. Use your EDR console (CrowdStrike Network Containment, SentinelOne Network Quarantine, or Defender for Endpoint Isolate Device) to immediately cut the host’s network connectivity while preserving the live memory state for forensic analysis. If EDR containment is unavailable, apply a host-based firewall block via GPO or a network ACL at the switch level. Do not shut down the machine — volatile memory may contain the stolen token, injected shellcode, or C2 configuration that will be lost on reboot.
• Disable the affected user account in Active Directory immediately. In Active Directory Users and Computers or via PowerShell (Disable-ADAccount -Identity <username>), disable the account that was being impersonated and the account that performed the impersonation if they are different. For service accounts, coordinate with application owners before disabling to assess impact, but do not delay if domain admin credentials are involved.
• Terminate the malicious process on the affected host. Use your EDR to kill the process identified in the alert by PID. If EDR is unavailable and you have a remote shell, use taskkill /PID <pid> /F. Document the PID, process name, and parent before killing it.
• Revoke active sessions and tokens for the impersonated account. In Active Directory, reset the password for any account whose token was stolen to invalidate Kerberos TGTs. Run klist purge on the affected host if accessible. If the account is a Domain Admin, coordinate with your AD team to also run Invoke-ADUserPurgeAuthenticationCache or equivalent to force re-authentication across the domain. For cloud-integrated environments, revoke OAuth tokens and invalidate Azure AD refresh tokens via the Microsoft Graph API or Azure AD portal.
• Block identified C2 infrastructure at the perimeter. Extract any external IP addresses or domains from Sysmon network connection events (Event ID 3) or EDR telemetry associated with the malicious process. Block these at your perimeter firewall, web proxy, and DNS filtering solution immediately. Submit IOCs to your threat intelligence platform for enrichment and broader blocking.

Eradication

• Hunt for and remove persistence mechanisms on the affected host. Check the following locations for attacker-added persistence: scheduled tasks (schtasks /query /fo LIST /v or Autoruns), registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), new or modified services (sc query and compare against your baseline), WMI event subscriptions (Get-WMIObject -Namespace root\subscription -Class __EventFilter), and startup folders. Remove any entries not present on a known-good baseline image.
• Find and delete dropped tools or payloads. Use your EDR’s file search capability or run a manual search on the host for file hashes, paths, or names identified during investigation (check %TEMP%, %APPDATA%, C:\Windows\Temp, C:\ProgramData). Submit hashes to VirusTotal or your threat intel platform to confirm malicious classification before deletion. Preserve copies of malicious files in a controlled malware repository for post-incident analysis.
• Reset credentials for all accounts that touched the compromised host. Reset passwords for every account that logged onto the affected host in the 48 hours prior to and including the incident window, with priority for any privileged accounts. For service accounts, coordinate rotation with application teams. Enable “User must change password at next logon” and notify account holders through a verified out-of-band channel.
• Check all lateral movement targets for signs of compromise. For every host that received a network logon from the affected system or account (identified in investigation Step 6), run a rapid triage — check for new user accounts, modified scheduled tasks, new services, and outbound network connections in the same timeframe. If any signs of compromise are found on a lateral movement target, initiate the same containment and eradication process for that host.
• Rotate any secrets or API keys that may have been exposed. If the impersonated account had access to secrets management systems (HashiCorp Vault, CyberArk, Azure Key Vault), API gateways, or had credentials stored in configuration files, rotate all those secrets immediately. Review access logs for those systems for the account in the incident timeframe to determine if exfiltration of secrets occurred.

Recovery

• Verify the host is clean before reconnecting to the network — re-image if confidence is low. Before removing network isolation, run a full EDR scan and review all persistence locations manually. If you cannot achieve high confidence that all attacker artifacts are removed (e.g., rootkit indicators, unsigned drivers, or gaps in telemetry during the incident window), re-image the host from a known-good golden image rather than attempting cleanup. A rebuilt host is always preferable to a host with residual attacker access.
• Re-enable the affected user account only after confirming no persistence remains. Coordinate with the account owner to re-enable the account only after the host is confirmed clean, the password has been rotated, and MFA has been verified or enrolled. Provide the user with a new device or a re-imaged workstation if the original host was re-imaged.
• Monitor the affected host and account for 72 hours post-remediation. Create a temporary, elevated-sensitivity detection rule in your SIEM that alerts on any activity from the previously affected host or re-enabled account during the 72-hour window. Assign a dedicated analyst to review these alerts manually — do not rely solely on automated triage during this period.
• Document the full incident timeline and conduct a lessons-learned review. Produce a written incident timeline covering initial access through containment, including all IOCs, affected accounts, affected hosts, actions taken, and detection gaps identified. Within 5 business days of closure, conduct a brief lessons-learned session with the SOC team and relevant stakeholders to identify whether detection rules, playbooks, or telemetry coverage need to be updated.
• Update detection