Attackers use create process with token to launch a new process under a different security context, usually after obtaining a usable token from another user or service. That lets them run tools with borrowed privileges and expand access. Defenders should monitor token theft paths, restrict sensitive token use, and investigate process creation that does not match the parent context.
How create process with token is abused in practice
Attackers use this technique to start a new process under a different security context, so the child process inherits borrowed access rather than the permissions of the launching user. That is useful for running tools, staging payloads, or accessing resources that the original account could not reach. It is a classic privilege transfer pattern, not just a process-launch trick.
In many environments, the token is the real objective because it can carry group membership, delegated rights, or elevated session context. Once an attacker has a usable token, create-process-with-token turns that token into immediate execution, which makes the technique attractive after token theft, session compromise, or abuse of a trusted service account.
For defenders, the important detail is that the process tree can look legitimate while the security context does not. If your investigation only checks parent-child process relationships, you can miss that the new process is operating with a different token than the parent user session would normally produce. The MITRE ATT&CK Guide for Defenders is useful here because this technique sits in the broader pattern of token impersonation, process masquerading, and defensive coverage mapping.
Where the token comes from and why it matters
The technique usually depends on prior access to a token that can be reused or impersonated. That token may come from theft, memory exposure, a compromised service, delegated access, or an overprivileged account. The practical risk is that the attacker does not need to “break” the target application again once the token is available, they only need a way to convert it into a fresh process with usable authority.
This is why token hygiene and token lifecycle controls matter so much. Long-lived or broadly scoped tokens give attackers more time and more reach if they are exposed. Short-lived, tightly scoped, and audience-bound tokens reduce the payoff when an attacker tries to turn a stolen token into a new process.
Attacks that start with token theft often chain into process creation, lateral movement, and service abuse. The same underlying weakness can also let an attacker blend into normal administration, because the spawned process may look like routine tooling rather than a separate intrusion.
What strong detection and response look like
Good detection is less about one alert and more about correlation. You want to compare the token context, the parent context, the target user context, and the spawned command line. If those four pieces do not line up, especially on a sensitive host or with an administrative token, the event deserves review.
It also helps to separate expected delegation from suspicious impersonation. Legitimate automation may create processes with alternate tokens for support or deployment tasks, but those paths should be bounded, documented, and auditable. Unexpected token use is most dangerous when it appears on endpoints, jump hosts, or servers that normally have little reason to launch processes across trust boundaries.
When this technique is seen alongside token theft indicators, credential dumping, or unusual session reuse, treat it as a sign that the attacker has already crossed an access boundary. The CISA Known Exploited Vulnerabilities Catalog and relevant threat advisories are useful reference points when the token was exposed through a publicly exploited weakness.
Risk and Threat Considerations
This technique is risky because it converts a stolen or borrowed token into active execution, which can bypass the normal assumptions behind user-based controls, monitoring, and least privilege. The same mechanism can also preserve attacker persistence if the token remains valid long enough for repeated process launches or secondary tooling.
Failure mechanism: A token with reusable authority is obtained, then used to spawn a new process that inherits access the attacker should not have had through the original session. That breaks the trust model between the visible user context and the effective security context.
Impact: Attackers can run commands, move laterally, access protected data, and impersonate a trusted identity path while leaving fewer obvious traces than a direct login or password-based compromise.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1134 — Access Token Manipulation | This technique centers on abusing tokens to run with different authority. |
| Recommendation — Map token-based process abuse to T1134 and hunt for token theft, impersonation, and abnormal process context. | ||
| CIS Controls v8 | CIS-5 — Account Management | Token abuse depends on excessive or mismanaged account and service access. |
| Recommendation — Tighten account lifecycle controls and remove standing access that can be reused through stolen tokens. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Reusable tokens are authenticators whose lifecycle and protection affect abuse risk. |
| AC-6 — Least Privilege | The technique is valuable because it turns borrowed authority into broader execution rights. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on reviewing mismatched token and process context in logs. | |
| Recommendation — Apply IA-5 to restrict token lifetime, scope, storage, and revocation handling. Enforce AC-6 so a stolen token cannot expand process rights beyond the minimum needed. Correlate process creation, token use, and identity context under AU-6 to surface suspicious delegation. | ||
Practitioner Guidance
What to verify: Check whether the token that enabled process creation was expected for that host, user, service, and time of day. If the answer is unclear, confirm the issuing path, session age, scope, and whether the token should still be valid.
Common mistake: Treating a normal-looking process tree as proof of legitimacy. A process can be parented by a benign binary and still be suspicious if the token context, privilege level, or user identity does not match the surrounding environment.
Decision rule: If the spawned process can access production data, administrative tools, or security controls, prioritise token containment and blast-radius assessment before spending time on user intent or manual review of the command line.
Practitioner takeaway: The security question is not just “what process started,” but “which authority was silently attached to it.” If that authority is borrowed, reused, or unexpected, treat the process as a potential post-compromise action until proven otherwise.