Reduce the risk by restricting token assignment privileges, monitoring for process creation that uses another account’s token, and alerting on privileged token theft or duplication. Attackers use this technique to launch processes under elevated or borrowed identities, so strong least privilege and token-use auditing are essential.
How to reduce token-based process creation risk
The practical goal is to make token use narrow, auditable, and hard to abuse. If a process can be launched under a borrowed or elevated token, an attacker can cross privilege boundaries without needing full interactive login. That is why the safest mitigations focus on who may assign tokens, how those events are monitored, and whether token use is constrained to the smallest feasible set of identities and sessions.
One useful control is to treat token assignment as a privileged action, not a routine convenience. Restrict who can create or duplicate a process with another account’s token, and make that permission rare enough that it stands out in review. This is especially important where borrowed tokens can inherit broad access or outlive the original user action.
Monitoring should look for the process pattern itself, not just the login event that preceded it. Detect process creation that reuses another identity’s token, unusual parent-child process relationships, and token material being copied or injected into a new execution context. For defenders, the value is in seeing the handoff between identity and process behavior, because that is where the abuse occurs.
Auditing token use is most effective when it is tied to escalation paths. If the token belongs to a privileged account, a service account, or a session with access to sensitive systems, the event should be more visible and more actionable than ordinary process starts. Where feasible, pair those alerts with token lineage or ownership data so investigators can tell whether the token was legitimately delegated or simply stolen.
In practice, this is where least privilege and short token lifetime reinforce each other. Tight privilege reduces the damage if a token is misused, while shorter-lived or better-scoped tokens reduce the opportunity window for process abuse. The two controls are complementary, because visibility without restriction still leaves too much room for misuse.
Why attackers use borrowed or duplicated tokens
Attackers favor this technique because it can make malicious activity look like legitimate execution. A process created with a valid token may inherit trust, access rights, and logging context that would be harder to obtain through a fresh attack path. That can help an intruder bypass controls that focus only on password theft or interactive sign-in anomalies.
The risk increases when token reuse or duplication is normal enough that defenders cannot easily distinguish expected administration from abuse. Where a platform permits impersonation, delegation, or token passing, the boundary between legitimate automation and unauthorized process launch needs to be explicit and monitored. MITRE ATT&CK Enterprise is useful here because it frames token abuse as part of the broader credential access and privilege escalation problem, not as an isolated event.
Borrowed-token abuse also becomes more valuable to attackers when a token carries downstream permissions into file systems, services, APIs, or administrative tools. In those cases, the process creation step is not the end goal, it is the vehicle for later movement or impersonation. That is why defenders should treat token-origin questions as part of identity control, not only endpoint monitoring.
What to verify before you trust the control
Do not assume a restriction exists just because token use is logged. Verify which identities are actually allowed to mint, assign, or duplicate tokens, and confirm that those privileges are not shared broadly among operators, service owners, or automation roles. The control only works if the administrative path is genuinely narrow.
Also verify that your detection can separate normal delegation from suspicious impersonation. If the environment uses scheduled tasks, service wrappers, jump hosts, or automation platforms, those legitimate paths can create noise unless you baseline them carefully. A good audit rule is one that highlights the unexpected without drowning analysts in approved process patterns.
For deeper hardening, review whether tokens are audience-bound, short-lived, or otherwise limited in what they can authorize. CISA Known Exploited Vulnerabilities Catalog is not a token-control standard, but it reinforces the broader defensive practice of prioritising abuse paths that are known to be actively exploited when they sit inside your process-launch chain.
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 and CIS Controls v8 set 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 privilege abuse and credential manipulation pattern. |
| Recommendation — Map token-based process abuse to T1134 and hunt for token theft, duplication, and impersonation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifecycle, scoping, and protection depend on authenticator management. |
| AC-6 — Least Privilege | Restricting who may assign or reuse tokens is a least-privilege control problem. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detecting borrowed-token process creation requires review of audit events and anomalies. | |
| Recommendation — Enforce IA-5 to restrict token issuance, rotation, storage, and revocation. Apply AC-6 to limit token assignment and process-creation privileges to the minimum set. Use AU-6 to review token-use events and alert on abnormal process creation patterns. | ||
| CIS Controls v8 | CIS-5 — Account Management | Token assignment and borrowed identity usage are account-governance concerns. |
| Recommendation — Use CIS-5 to restrict account and token privileges and remove unnecessary access. | ||
Practitioner Guidance
What to prioritise: Focus first on the privilege that allows token assignment or duplication. If too many operators can create processes under another account’s identity, the monitoring layer will only tell you you were abused after the fact.
What to verify: Confirm that alerts distinguish a legitimate delegated workflow from a process started with a borrowed token. The signal should be strong enough to drive investigation, not just awareness.
Decision rule: If the token can reach privileged services, treat any unexplained process creation with that token as a potential credential abuse event and investigate the token source before deciding whether the process itself was malicious.
Practitioner takeaway: The best mitigation is not simply more logging, it is making token-based process creation rare, attributable, and tightly bounded so misuse becomes both harder to perform and easier to prove.