T1134No distinct observable

Access Token Manipulation

Stealth · Privilege EscalationWindows

Where this stands

A reviewer read the telemetry and concluded there is nothing here to detect that a sibling technique does not already cover.

AN0786's own description is the union of its two children's analytics, not a distinct observable of its own: the 'token-related APIs (e.g., LogonUser, DuplicateTokenEx) or commands (runas)' leg is AN1324, published in this wave as T1134.001's rule; the 'spawning of a new process under a different security context (e.g., SYSTEM)' leg is AN1253, published in this wave as T1134.002's rule. Both children share T1134's process_creation and process_access log sources verbatim, and the two legs T1134 adds beyond the children — Security 4672/4634 (logon session metadata) and 5136 (AD object modification) — are pure correlation legs, not standalone selectors: AN0786 asks for a time-windowed join across API usage, process creation and 'anomalies in ETW token/PPID data', which lib/sigma cannot express (no aggregations, no cross-event timeframes), and 5136 in particular tracks AD attribute changes s […]

Covered instead by T1134.001, T1134.002.

What the technique is

Adversaries may modify access tokens to operate under a different user or system security context to perform actions and bypass access controls. Windows uses access tokens to determine the ownership of a running process. A user can manipulate access tokens to make a running process appear as though it is the child of a different process or belongs to someone other than the user that started the process. When this occurs, the process also takes on the security context associated with the new token. An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing. These token can then be applied to an existing process (i.e. Token Impersonation/Theft) or used to spawn a new process (i.e. Create Process with Token). An adversary must already be in a privileged user context (i.e. administrator) to steal a token. However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level. An adversary can then use a token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system. Any standard user can use the runas command, and the Windows API functions, to create impersonation tokens; it does not require access to an administrator account. […]

Read it on attack.mitre.org

What MITRE says you would watch

AN0786
Detection of suspicious token manipulation chains: use of token-related APIs (e.g., LogonUser, DuplicateTokenEx) or commands (runas) → spawning of a new process under a different security context (e.g., SYSTEM) → mismatched parent-child process lineage or anomalies in Event Tracing for Windows (ETW) token/PPID data → abnormal lateral or privilege escalation activity.