T1134.004: Parent PID Spoofing
Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. New processes are typically spawned directly from their parent, or calling, process unless explicitly specified. One way of explicitly assigning the PPID of a new process is via the CreateProcess API call, which supports a parameter that defines the PPID to use.[1] This functionality is used by Windows features such as User Account Control (UAC) to correctly set the PPID after a requested elevated process is spawned by SYSTEM (typically via svchost.exe or consent.exe) rather than the current user context.[2]
Adversaries may abuse these mechanisms to evade defenses, such as those blocking processes spawning directly from Office documents, and analysis targeting unusual/potentially malicious parent-child process relationships, such as spoofing the PPID of PowerShell/Rundll32 to be explorer.exe rather than an Office document delivered as part of Spearphishing Attachment.[3] This spoofing could be executed via Visual Basic within a malicious Office document or any code that can perform Native API.[4][3]
Explicitly assigning the PPID may also enable elevated privileges given appropriate access rights to the parent process. For example, an adversary in a privileged user context (i.e. administrator) may spawn a new process and assign the parent as a process running as SYSTEM (such as lsass.exe), causing the new process to be elevated via the inherited access token.[5]
Analyst context for executives and security teams
Parent PID Spoofing matters because it can make a malicious Windows process look like it was launched by a trusted or expected parent process. For leaders, the risk is not just process creation abuse; it is that common SOC logic based on parent-child relationships can be misled, especially around Office-spawned activity, PowerShell, Rundll32, and elevated process contexts.
Executive priority
Prioritize this where Windows endpoint visibility, privilege escalation monitoring, and incident response evidence depend heavily on process trees. Security leaders should ask whether detections validate the real process creation chain rather than trusting displayed parentage alone, and whether SOC playbooks account for legitimate exceptions such as User Account Control behavior. This technique is relevant to resilience because it can weaken controls intended to block suspicious child processes and can complicate privilege-escalation investigations.
Technical view
This is a Windows sub-technique of Access Token Manipulation under stealth and privilege-escalation. The supplied ATT&CK description highlights explicit PPID assignment through process creation mechanisms, including CreateProcess behavior, and abuse scenarios where PowerShell or Rundll32 appear to originate from explorer.exe instead of an Office document. It also notes possible elevation when a privileged user context assigns a SYSTEM process such as lsass.exe as the parent and inherits the associated token. SOC and IR teams should validate behavior-chain detection for T1134.004, correlate parent-child process relationships with process creation metadata, command line, user context, token/elevation state, and surrounding Office, scripting, Native API, and UAC-related activity.
Likely telemetry
- Windows process creation events with parent process identifiers and process image names
- Command-line telemetry for child processes such as PowerShell and Rundll32
- User, integrity level, and token/elevation context associated with process creation
- Office document or macro-related process activity where available
- UAC-related process activity involving consent.exe, svchost.exe, or elevated child processes
Detection direction
- Validate DET0489-style behavior-chain coverage for Parent PID Spoofing rather than relying only on simple parent-child allow/block rules.
- Tune detections for suspicious mismatches such as Office-originated activity that appears to have explorer.exe as the parent for scripting or LOLBin-style execution described in the ATT&CK object.
- Include false-positive handling for legitimate Windows UAC behavior, since the ATT&CK description notes that Windows may legitimately set PPID after elevated process creation.
- Correlate process tree anomalies with user privilege context and token/elevation state to distinguish evasion-only cases from possible privilege-escalation paths.
- Use relationship context from software that uses this technique, including Cobalt Strike, KONNI, PipeMon, and DarkGate, as threat-informed test cases without assuming those tools are present in the environment.
Mitigation priorities
- Reduce reliance on parent process name alone as a control decision point; require additional context such as command line, signer, user context, and elevation state.
- Harden and monitor Windows endpoint process creation telemetry so IR teams can reconstruct suspected spoofed process chains.
- Review controls that block Office documents spawning scripting or system utilities and confirm they are not bypassed by parent spoofing assumptions.
- Limit administrative privileges and monitor privileged contexts because the ATT&CK description notes elevation potential when appropriate access rights to a parent process exist.
- Document legitimate UAC-related parent process patterns as audit and SOC tuning evidence.
Analyst notes and limits
The object has no official ATT&CK detection text, but it includes a detection-strategy relationship: DET0489, behavior-chain detection for T1134.004. The strongest defensive value is validating whether process-tree analytics are resilient to spoofed PPID and whether privilege context is captured alongside process creation. The revoked T1502 relationship indicates this object supersedes an older technique entry for Parent PID Spoofing.
This take is limited to the supplied ATT&CK fields, external references, and relationships. No environment-specific exposure, active exploitation, control effectiveness, or detection coverage can be inferred without local Windows endpoint telemetry and SOC rule review.
Parent PID Spoofing
Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. New processes are typically spawned directly from their parent, or calling, process unless explicitly specified. One way of explicitly assigning the PPID of a new process is via the CreateProcess API call, which supports a parameter that defines the PPID to use.[1] This functionality is used by Windows features such as User Account Control (UAC) to correctly set the PPID after a requested elevated process is spawned by SYSTEM (typically via svchost.exe or consent.exe) rather than the current user context.[2]
Adversaries may abuse these mechanisms to evade defenses, such as those blocking processes spawning directly from Office documents, and analysis targeting unusual/potentially malicious parent-child process relationships, such as spoofing the PPID of PowerShell/Rundll32 to be explorer.exe rather than an Office document delivered as part of Spearphishing Attachment.[3] This spoofing could be executed via Visual Basic within a malicious Office document or any code that can perform Native API.[4][3]
Explicitly assigning the PPID may also enable elevated privileges given appropriate access rights to the parent process. For example, an adversary in a privileged user context (i.e. administrator) may spawn a new process and assign the parent as a process running as SYSTEM (such as lsass.exe), causing the new process to be elevated via the inherited access token.[5]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1502 | Parent PID Spoofing | Parent PID Spoofing revoked by this object. |
| Enterprise | T1134 | Access Token Manipulation | This object subtechnique of Access Token Manipulation. |
Groups, software, and campaigns
S0356: KONNI
KONNI is a remote access tool that security researchers assess has been used by North Korean cyber actors since at least 2014. KONNI has significant code overlap with the NOKKI malware family, and has been linked to several suspected North Korean campaigns targeting political organizations in Russia, East Asia, Europe and the Middle East; there is some evidence potentially linking KONNI to APT37.[1][2][3][4][5]
S0154: Cobalt Strike
Cobalt Strike is a commercial, full-featured, remote access tool that bills itself as “adversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors”. Cobalt Strike’s interactive post-exploit capabilities cover the full range of ATT&CK tactics, all executed within a single, integrated system.[1]
In addition to its own capabilities, Cobalt Strike leverages the capabilities of other well-known tools such as Metasploit and Mimikatz.[1]
S0501: PipeMon
PipeMon is a multi-stage modular backdoor used by Winnti Group.[1]
S1111: DarkGate
DarkGate first emerged in 2018 and has evolved into an initial access and data gathering tool associated with various criminal cyber operations. Written in Delphi and named "DarkGate" by its author, DarkGate is associated with credential theft, cryptomining, cryptotheft, and pre-ransomware actions.[1] DarkGate use increased significantly starting in 2022 and is under active development by its author, who provides it as a Malware-as-a-Service offering.[2]
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 4de67c719603… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
DidierStevens SelectMyParent Nov 2009
Stevens, D. (2009, November 22). Quickpost: SelectMyParent or Playing With the Windows Process Tree. Retrieved June 3, 2019.
Open source URL -
[2]
Microsoft UAC Nov 2018
Montemayor, D. et al.. (2018, November 15). How User Account Control works. Retrieved June 3, 2019.
Open source URL -
[3]
CounterCept PPID Spoofing Dec 2018
Loh, I. (2018, December 21). Detecting Parent PID Spoofing. Retrieved June 3, 2019.
Open source URL -
[4]
CTD PPID Spoofing Macro Mar 2019
Tafani-Dereeper, C. (2019, March 12). Building an Office macro to spoof parent processes and command line arguments. Retrieved June 3, 2019.
Open source URL -
[5]
XPNSec PPID Nov 2017
Chester, A. (2017, November 20). Alternative methods of becoming SYSTEM. Retrieved June 4, 2019.
Open source URL -
[6]
mitre-attack T1134.004Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.