CreateProcessWithLogonW is a Windows API function that starts a new process under the security context of specified user credentials. It is used when a caller needs to launch a process as another user without logging on interactively, and the spawned process receives the target account’s access token and privileges.
How CreateProcessWithLogonW Works
CreateProcessWithLogonW is a Windows process-creation API that launches a new process under a supplied user context instead of the caller’s own logon session. That means the new process inherits the target account’s access token, group memberships, and privilege boundaries, which can materially change what it can reach on the system and across the network.
This makes the function more than a convenience wrapper. It is a security-relevant boundary crossing point because it changes who the operating system believes is acting, even though the request originated from another process. When used correctly, it helps separate administrative or delegated tasks from the parent process. When used carelessly, it can blur accountability and create unexpected privilege paths.
Why It Matters for Access Control
The key security property of CreateProcessWithLogonW is that access decisions are evaluated against the target account, not the caller. That affects local file access, registry access, network authentication, mapped resources, and any authorization checks that depend on the logon token. In practice, the function is often used when a tool needs to perform an action as a different user without requiring an interactive desktop logon.
Because the spawned process receives a fresh security context, the call can be used to apply least privilege more precisely, but it can also be used to bypass the assumptions that other controls make about the initiating process. A parent process with limited rights may still be able to start a child process that acts with more useful access if it can supply valid credentials for the target account.
Common Security Implications
From a defensive perspective, the important question is not simply whether the API works, but what the resulting token can do. A process started this way may access sensitive files, service resources, administrative shares, or internal tools available to that account. If the credentials used are privileged, the launched process can become an effective execution bridge into higher-trust areas of the environment.
The function is also relevant to monitoring because process lineage alone may not reveal the effective identity under which activity occurs. Security teams often need to correlate process creation events, logon events, and token-bearing actions to understand whether a process was intentionally started under alternate credentials or whether that behavior reflects misuse.
Where Misuse Creates Risk
Operationally, the main risks are credential exposure, excessive privilege, and unclear ownership of actions performed by the spawned process. If credentials are embedded in scripts, passed through automation, or reused broadly, the call becomes a pathway for unauthorized execution rather than a controlled delegation mechanism.
It is also easy to overestimate the safety of “run as another user” workflows. The API does not itself validate business intent, enforce separation of duties, or guarantee that the target identity is appropriate for the task. Those controls still have to be designed around the process launch pattern.
Risk and Threat Considerations
When this API is used with privileged or reused credentials, it can become an abuse path for privilege escalation, lateral movement, or disguised execution under a trusted account. The risk is greatest when an attacker can obtain credentials, influence automation, or trigger a launcher that silently starts trusted software in a more powerful security context.
Failure mechanism: The parent process supplies credentials or delegated access that cause Windows to mint a new token with the target account’s rights, and downstream actions are then attributed to that account rather than the original caller.
Impact: Attackers or misconfigured automation can gain broader file, network, or administrative access, while defenders lose clarity about who initiated the action and under what authority it occurred.
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 NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CreateProcessWithLogonW depends on supplied credentials for a new logon context. |
| AC-6 — Least Privilege | The API changes which privileges the spawned process receives and can exercise. | |
| AU-2 — Event Logging | Process creation under another user requires auditability to attribute actions correctly. | |
| Recommendation — Protect and rotate the credentials used to launch alternate-user processes. Restrict which accounts can start processes under alternate credentials. Log alternate-credential process launches and correlate them with logon activity. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The call changes trust context and should be evaluated as an access decision. |
| Recommendation — Verify the resulting token and session trust before allowing sensitive actions. | ||
| MITRE ATT&CK | T1134 — Access Token Manipulation | Launching under another user relies on token-based authority changes that attackers can abuse. |
| Recommendation — Map alternate-context process launches to token abuse detection and hunt for suspicious privilege transitions. | ||
Practitioner Guidance
Why practitioners should care: Treat alternate-credential process creation as a privileged operation, not a harmless convenience feature. The security outcome depends on the sensitivity of the target account and on how credentials are handled before the process starts.
What to watch for: Investigate unusual parent-child process relationships, unexpected alternate logon events, and automation that repeatedly launches high-trust processes from lower-trust contexts. Those patterns often indicate delegated administration, but they can also indicate credential misuse or hidden privilege transfer.
Practitioner takeaway: Control who may launch processes under alternate identities, and make sure the resulting token, not just the launching binary, is covered by your monitoring and review model.