MITRE ATT&CK T1134 Access Token Manipulation: Detecting and Containing Windows Token Abuse

Once an attacker is administrator on a Windows host, stealing or forging an access token lets them act as SYSTEM, as a logged-on domain admin or as a service account, without ever knowing a password. MITRE ATT&CK tracks this as T1134 Access Token Manipulation, a Windows technique listed under both Privilege Escalation (TA0004) and Stealth (TA0005) in ATT&CK v20, with five sub-techniques. This guide explains what each sub-technique does at the level a defender needs, which events and telemetry reveal it, how service accounts and other non-human identities widen the exposure, and which user rights and Active Directory settings shrink it. It is written for detection engineers, Windows and Active Directory administrators and identity teams. It deliberately contains no attacker procedures or tooling steps.

Key takeaways

• It is a post-admin technique. ATT&CK states the adversary must already be in a privileged context to steal a token; the usual goal is moving from administrator to SYSTEM, or borrowing a more useful identity that is already logged on.
• Service identities are the soft spot. SeImpersonatePrivilege is held by default by Local Service, Network Service and the Service group, so a compromised web or database service account is often one step from SYSTEM.
• Detect the chain, not the API. ATT&CK v20 detection strategies correlate token API use, a new process in a different security context and implausible parent-child lineage; any one signal alone is noisy.
• Logon type 9 and 4672 are your friends. Event 4624 with logon type 9 (NewCredentials) and event 4672 for unexpected accounts are cheap, high-value signals for token creation and privilege assignment.
• Fewer privileged sessions, fewer tokens to steal. Tiered administration, no domain admin logons on member servers, tight user rights assignment and clean SID-History remove most of the value of the technique.

What T1134 covers in ATT&CK v20

ATT&CK v20 (technique version 3.0, last modified 12 May 2026) describes T1134 as adversaries modifying access tokens to operate under a different user or system security context to perform actions and bypass access controls. A Windows access token describes the security context of a process or thread. According to Microsoft, it holds the user SID, group SIDs, a logon SID, the list of privileges, the owner and primary group, the default DACL, the token source, whether it is a primary or impersonation token, any restricting SIDs and the impersonation level. Every process has a primary token; a thread that impersonates a client holds an impersonation token as well.

ATT&CK notes that a stolen token can be used to authenticate to a remote system as that account, if the account has rights there.

T1134 rarely appears on its own. It usually follows T1068 Exploitation for Privilege Escalation or credential theft such as T1003.001 LSASS Memory, and it precedes lateral movement with T1078.002 Domain Accounts. ATT&CK v20 records its use by groups including APT28 (G0007), Lazarus Group (G0032), Turla (G0010), FIN6 (G0037), FIN8 (G0061), FIN13 (G1016), BlackByte (G1043) and Blue Mockingbird (G0108), the last of which abused SeImpersonate to escalate.

Where non-human identities fit

Token manipulation is usually told as a story about stealing an admin's session, but the most common real path runs through service identities. Microsoft's user rights documentation lists the default holders of Impersonate a client after authentication (SeImpersonatePrivilege) on workstations, member servers and domain controllers as Administrators, Local Service, Network Service and Service. Optional components such as IIS and ASP.NET add IUSR and IIS_IUSRS. Any process running under those identities can impersonate clients that connect to it, which is exactly what a service needs to do and exactly what an attacker who has compromised that service will try to exploit.

• Web and database services: an attacker who gains code execution in an IIS application pool or a SQL Server service account inherits SeImpersonatePrivilege. Microsoft's own risk statement describes an attacker with this right creating a service, misleading a client into connecting and impersonating it to raise their access to that of the device.
• Over-privileged service accounts: a domain service account that is a local administrator on many servers gives every token it produces a wide radius. See the Service Account Security Guide and the Windows Services and Service Account Security Guide.
• Interactive logons by automation and admins: scheduled tasks, deployment tools and admins who log on to member servers leave tokens in memory that a local SYSTEM-level attacker can copy. The token for a domain admin left on a file server is the classic jump to domain compromise.
• Credentials held by tools: T1134.003 needs a password, which often comes from scripts, configuration files and vaults that store service credentials in clear text. Moving those accounts to gMSA removes a human-known password from the picture.
• Cloud VMs: the technique is Windows-only, but a cloud VM often holds a managed identity that SYSTEM can reach, so treat a confirmed T1134 there as a possible cloud identity compromise.

Detection

ATT&CK v20 ships a detection strategy per sub-technique, each described as a behaviour chain: DET0283 for the parent technique, DET0482 (T1134.001), DET0456 (T1134.002), DET0498 (T1134.003), DET0489 (T1134.004) and DET0136 (T1134.005). The table turns them into log sources you can collect today.

Analytic logic that works

1. Context jump: join process creation events on parent process GUID and alert when the child's user is SYSTEM or a privileged domain account and the parent's user is a service identity (IIS AppPool, NT SERVICE accounts, SQL service accounts) or a standard user. Allow-list installers and management agents by signed image path.
2. Type 9 outliers: baseline which hosts and processes create logon type 9 sessions (admin consoles, runas /netonly use by named admins) and alert on new process images, new hosts or service accounts as the subject.
3. Privilege drift: alert on 4672 for SeDebugPrivilege or SeTcbPrivilege on any account outside the admin tier list, which Microsoft's event guidance recommends as a search.
4. SID-History watch: sIDHistory should be empty outside a planned migration; treat any 5136 change to it as a high-severity event and check whether the value carries a privileged RID.
5. Correlate onwards: raise severity when a context jump is followed within minutes by network logons (4624 type 3) to other hosts under the impersonated account. That is the transition from T1134 into lateral movement.

For the wider event catalogue see the Active Directory Security Monitoring and Event IDs Guide, and for building the rules the ATT&CK Detection Strategies and Analytics Guide.

Prevention and hardening

ATT&CK's own mitigations for T1134 are M1026 Privileged Account Management (limit who can create tokens and who can replace process level tokens) and M1018 User Account Management (least privilege, since full use requires administrator rights). For the trust side see the Active Directory Trusts and SID Filtering Guide.

Implementation sequence

1. Turn on the telemetry: enable Audit Special Logon, Audit Logon, Audit Process Creation with command line and Audit Directory Service Changes on domain controllers; deploy Sysmon or confirm your EDR records process access and token API events.
2. Inventory user rights: export User Rights Assignment from every GPO and compare SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeCreateTokenPrivilege and SeDebugPrivilege holders against the Microsoft defaults. Record every extra holder with an owner and reason.
3. Find where privileged tokens live: list interactive and RDP logons by Tier 0 accounts to non-Tier 0 hosts for the last 30 days (4624 types 2 and 10). This is your exposure list.
4. Pilot the analytics in alert-only mode: run the five analytics above against two weeks of data, tune allow-lists for installers, backup agents and management tools, then promote to paging alerts.
5. Apply the GPO changes in rings: remove extra user rights and add deny-logon rights for Tier 0 on a pilot server group first, watch application and service failures for a week, then expand. Rollback is reverting the GPO link; keep the previous GPO backup.
6. Migrate service accounts: move high-privilege service accounts to gMSA and remove local admin membership. See How to convert AD service accounts to gMSA.
7. Clean SID-History: query for accounts with a populated sIDHistory, confirm with the migration owner and remove entries no longer required.
8. Test detection: confirm each analytic fires using an approved emulation exercise in a lab domain, not on production hosts.

Decision guidance

• EDR versus native logs: T1134.001 and .004 are hard to see in Security log events alone because the key action is an API call. If you rely on native logs, prioritise the 4672, 4624 type 9 and lineage analytics; if you have EDR, use its token telemetry and keep the native events as a cross-check.
• Small versus large estates: small organisations get most of the benefit from tiering domain admins and moving service accounts to gMSA. Large estates with migrations and multiple forests must also own SID-History hygiene and trust configuration.
• Response threshold: treat a confirmed token context jump to SYSTEM on a server as a host compromise; treat one that leads to network logons under a domain admin as an Active Directory incident and follow the Active Directory Domain Compromise Response Playbook.

Measuring progress

• Tier 0 exposure: number of Tier 0 interactive or RDP logons to non-Tier 0 hosts per month, target zero.
• User rights drift: accounts holding SeImpersonatePrivilege, SeDebugPrivilege or SeAssignPrimaryTokenPrivilege beyond the documented baseline, target zero unexplained.
• Service account privilege: percentage of service accounts that are local administrators anywhere, trending down.
• SID-History population: accounts with sIDHistory set outside an active migration, target zero.
• Detection coverage: sub-techniques with a tested, alerting analytic, out of five.

Common failure patterns

• Admins working everywhere: domain admins log on to member servers for routine support, leaving tokens that turn one compromised server into a domain compromise.
• Service accounts as local admin: a single shared service account with admin rights on every server, whose tokens are available on all of them.
• Alerting on API names alone: DuplicateTokenEx is called constantly by legitimate software, so rules without lineage and context correlation are switched off within a week.
• Migrations that never finish: SID-History left on thousands of accounts years after a merger, which hides malicious entries among legitimate ones.
• Treating it as endpoint-only: responders reimage the host but do not reset or review the accounts whose tokens were present, so the borrowed identity stays usable.

Framework mapping

Practitioner checklist

• Enable Audit Special Logon, Audit Logon, process creation with command line and Directory Service Changes auditing.
• Baseline and alert on 4672 privilege assignments for accounts outside the admin tier.
• Baseline logon type 9 creators and alert on new processes, hosts or service accounts.
• Correlate process lineage to catch context jumps from service identities to SYSTEM.
• Restrict SeCreateTokenPrivilege, SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege and SeDebugPrivilege to documented holders.
• Stop Tier 0 logons on member servers and workstations; enforce with deny-logon rights.
• Move service accounts to gMSA, dMSA or virtual accounts and remove local admin rights.
• After any confirmed incident, reset and review every account whose token was present on the host.

Standards and references

• MITRE ATT&CK: Access Token Manipulation (T1134)
• MITRE ATT&CK: SID-History Injection (T1134.005)
• Microsoft: Access Tokens
• Microsoft: Impersonate a client after authentication
• Microsoft: Create a token object
• Microsoft: 4624(S) An account was successfully logged on
• Microsoft: 4672(S) Special privileges assigned to new logon
• MITRE D3FEND: Process Lineage Analysis

Related NHI Mgmt Group resources: MITRE ATT&CK T1078 Valid Accounts Guide · Service Account Security Guide · Active Directory and Entra ID Hardening Guide · Lateral Movement Guide · MITRE ATT&CK Guide for Defenders