Detect it by alerting when a process is started with an impersonation or primary token that does not match the calling user or service account. Focus on unusual token duplication, privilege escalation, and service abuse on endpoints and servers. Check for non-standard parent processes, sudden access to higher-privileged resources, and account activity that breaks the expected authentication pattern.
How to spot token-based process creation in telemetry
Process creation with a token is easiest to catch when the telemetry shows a process starting under an identity context that is different from the caller that initiated it. That usually means the token was duplicated, borrowed, or used for impersonation rather than the process inheriting a normal, expected login context. The useful signal is the mismatch between who started the action and which account actually received the execution context.
On Windows endpoints and servers, that means correlating process creation events with token-related activity, parent-child process chains, and the account tied to the resulting process. A process launched from an unusual parent, or one that suddenly reaches resources normally reserved for a higher privilege tier, is often more important than the token event alone. Detection works best when you baseline normal service behavior first, then look for breaks in that pattern.
Good hunting logic also distinguishes legitimate delegated or service-driven execution from abuse. Scheduled tasks, management tools, EDR actions, and service orchestration can all create processes with non-interactive contexts, so the detector should focus on abnormal token origin, unexpected privilege level, and unusual target resources. The same applies when a service account suddenly behaves like an admin account without the usual logon trail.
What abnormal token use looks like in practice
Abnormal token use often shows up as a process that claims a privileged or service identity without the surrounding authentication pattern that normally accompanies that identity. In practice, that can mean a shell or utility process inherits a primary token it should not have received, or a process appears with an impersonation token that does not align with the initiating user, host role, or service schedule. The key is not just that a token exists, but that the process context is inconsistent with how that token should be used.
Watch for sudden jumps in reach, such as access to admin shares, protected registry paths, directory changes, or privileged management interfaces immediately after process start. Those follow-on actions help separate noise from compromise because they show the token was not just present, it was operationally useful. When token abuse is real, the process usually does something a normal process under that account would not do at that time.
Non-standard parent processes are another strong clue. A process tree that does not fit the host’s normal administration pattern, especially when paired with a privileged token and unusual resource access, deserves immediate review. That combination is often more reliable than any single event field on its own.
Building detections that reduce false positives
Detections are stronger when they compare the new process against the expected account, expected parent, and expected execution path. If the process identity does not match the caller, the parent is atypical, and the child action is privileged, the alert is much more actionable. If only one of those conditions is true, treat it as a lower-confidence lead that needs enrichment rather than immediate escalation.
Use allowlists carefully for approved automation, but keep them narrow. Over-broad exclusions are a common way to miss token abuse on servers where service accounts, remote administration, and automation already create noisy baselines. The right balance is to allow known management paths while still flagging token use that escapes those paths or appears outside maintenance windows.
If your tooling can surface token type, integrity level, logon session, and caller context together, that is usually enough to create a useful triage rule. The more your detection can join process creation with authentication and privilege context, the less you need to rely on fragile string matching or hostname-specific exceptions.
Risk and Threat Considerations
Token-based process creation matters because it can turn a stolen or misused identity context into direct execution on an endpoint or server. That makes it attractive for privilege escalation, lateral movement, and service abuse, especially when defenders only watch logon events and miss what happens after the token is reused.
Failure mechanism: An attacker or insider obtains a usable token, then starts a process under that context so the new process inherits privileges that were never granted through the normal interactive path. If monitoring does not tie process creation back to the true caller and expected account behavior, the abuse can look legitimate.
Impact: The result can be silent privilege elevation, access to protected resources, and follow-on execution that blends into normal server activity. In the worst case, the token becomes the bridge from initial foothold to durable control of the host or adjacent 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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1134 — Access Token Manipulation | Token-based process creation is a core token manipulation and privilege abuse pattern. |
| T1055 — Process Injection | Suspicious process creation often co-occurs with execution abuse and process-hollowing style tradecraft. | |
| T1036 — Masquerading | Abuse can hide behind process names or parent paths that look legitimate while the token is abnormal. | |
| Recommendation — Map token-driven process starts to T1134 and hunt for token theft, duplication, or impersonation. Correlate anomalous process creation with T1055 indicators and verify the parent-child chain. Inspect process ancestry and naming for masquerading that accompanies suspicious token use. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Process creation and token context must be logged to detect abnormal execution paths. |
| IA-5 — Authenticator Management | Token abuse is easier to detect and constrain when credential and token lifecycle is tightly managed. | |
| AC-6 — Least Privilege | The issue is privileged execution beyond what the caller should normally be able to do. | |
| Recommendation — Enable audit generation for process creation and identity context needed to spot token abuse. Manage token lifecycle rigorously so stolen or duplicated tokens are easier to detect and revoke. Apply least privilege so token misuse cannot elevate a process beyond its expected role. | ||
Practitioner Guidance
What to verify: Confirm that your detector can join process creation, parent process lineage, and token context in one alert. If those three fields are not correlated, you will usually miss the difference between normal service execution and token abuse.
Decision rule: If a process starts with a token that does not match the initiating user or service account, treat it as suspicious immediately when it also gains higher-privileged access or launches from an unusual parent. If the token is expected, require stronger corroboration such as abnormal target resources or out-of-pattern timing before escalating.
Practitioner takeaway: The best detection is not “a process used a token,” but “a process used the wrong token, in the wrong way, at the wrong time.”