Create Process with Token

Create Process with Token is a Windows technique for starting a new process under a specified access token. Attackers use stolen or duplicated tokens to impersonate another user or elevate context after privilege escalation. Defenders should monitor token theft, abnormal process launches, and service or API misuse that creates processes in the wrong security context.

What Create Process with Token Means in Practice

Create Process with Token is a Windows technique for launching a new process under an access token that was stolen, duplicated, or otherwise obtained from another security context. It matters because the new process inherits that token’s permissions and can look legitimate to the system while acting on behalf of a different user or service.

In offensive use, the technique often follows privilege escalation, token theft, or service abuse. In defensive terms, it sits at the intersection of authentication material, process creation, and impersonation, so it should be understood as a context-switching mechanism rather than a simple process-launch command.

How the Token Changes Execution Context

A Windows token carries the security identity and privilege state that the kernel uses to decide what a process can access. When a process is created with a chosen token, the resulting child process operates under that token’s context, not necessarily the context of the caller that initiated the launch.

That distinction is what makes the technique powerful. If an attacker can duplicate or steal a more privileged token, they can start a process that inherits elevated rights, mapped network resources, group memberships, or service context that would not normally be available to their original session.

Why Defenders Watch for Token Abuse

Defenders care about this technique because it is a common post-compromise move for persistence, lateral movement, and privilege abuse. It can also obscure attribution, since the launched process may appear to belong to a trusted account or service even when it was spawned through malicious handling of credentials or session state.

Process creation telemetry, token-related API use, and unusual parent-child process relationships are useful clues. If a low-privilege or unexpected source process is creating children in a higher-value security context, that is often more important than the binary name itself.

For detection and hunting, the most useful reference point is MITRE ATT&CK Enterprise Matrix, which places token-related execution and privilege-abuse behaviour in a broader attack chain that defenders can map to telemetry and response logic.

Operational Consequences for Identity, Sessions, and Recovery

When create process with token is used successfully, the impact is rarely limited to a single process. It can expose session state, network access, cached authorisation, and service permissions tied to the token, which means the blast radius may extend beyond the initial host or application.

That is why incident response should treat token theft or misuse as both a host-level and identity-level event. A compromised token can require review of the originating account, any delegated access paths, and any secrets or sessions that the process could reach while running under that context. Practical identity and credential handling guidance is covered in API Key Management Guide and Secrets Management Guide, both of which reinforce the need to control lifecycle, exposure, and revocation for identity-bearing material.

Risk and Threat Considerations

This technique is dangerous because it turns a valid token into an execution vehicle. If attackers obtain a token with stronger privileges than their original foothold, they can spawn processes that blend into normal administrative or service activity while bypassing the intent of least privilege.

Failure mechanism: The weakness is usually token theft, token duplication, or misuse of an API or service path that allows process creation in an unintended security context. Once a token is reused, the resulting process can inherit trust and access that defenders expect only from the genuine owner.

Impact: The likely consequences are privilege escalation, lateral movement, persistence, and harder-to-detect abuse of trusted accounts or services. In severe cases, the token can become a reusable foothold for repeated access until the associated sessions, secrets, and account permissions are reviewed and rotated.

Practitioner Guidance

What to watch for: Prioritise anomalous process launches, especially where the creator and resulting security context do not normally match. Correlate process creation with token-handling events, service activity, and account privilege changes so that abuse stands out early.

Governance implication: Treat token handling as a privileged control surface, not just an implementation detail. The strongest defence is clear ownership over who can obtain, duplicate, delegate, or use tokens to launch processes, backed by monitoring that distinguishes legitimate delegation from suspicious impersonation.

Related resources from NHI Mgmt Group

• When does token theft create more risk than password theft?
• Why do OIDC token validation failures create confused deputy risk?
• Why do token reuse and refresh tokens create so much risk in SaaS integrations?
• Why do token-backed feature flags create governance risk?