Defenders lean on process trees. A Word document that starts PowerShell is suspicious, and a good rule can alert on it. T1134.004, Parent PID Spoofing, is the technique that tries to break that rule by faking who the parent is.
It is an Access Token Manipulation sub-technique, filed under stealth and privilege escalation, and applies to Windows.
How attackers use it
MITRE explains that new processes are normally spawned directly by the calling process, unless a parent is explicitly specified. The CreateProcess API call supports a parameter that defines the parent process ID. Windows itself uses this. For example, User Account Control sets the parent correctly after an elevated process is spawned by SYSTEM (typically through svchost.exe or consent.exe) instead of the current user context.
Adversaries can abuse the same mechanism for two goals.
- Evasion. Defenses that block processes spawning directly from Office documents, or that analyze unusual parent and child pairs, can be sidestepped. MITRE's example is spoofing the parent of PowerShell or Rundll32 to be
explorer.exerather than an Office document delivered as an attachment. This could be done from Visual Basic in a malicious Office document, or any code that can call the Native API. - Privilege. With the right access to the chosen parent, a privileged adversary may start a process and assign a SYSTEM process such as
lsass.exeas the parent, so the new process inherits an elevated access token.
The page lists Cobalt Strike and DarkGate among software that does this.
How to detect it
MITRE's strategy looks for a process that explicitly forges its parent, using an extended startup info structure with the parent process attribute (UpdateProcThreadAttribute, then CreateProcessA, CreateProcessW or CreateProcessAsUserW), or other Native API paths. The result is implausible or mismatched lineage when you compare three records:
- the ETW event header process ID,
- the Security 4688 creator process ID and name,
- the Sysmon
ParentProcessGuid.
If those disagree about who the parent is, something is off. Most teams will not correlate all three by hand, but a detection engineer can. Pair this with a simpler rule: a child with a higher integrity level or a different user than its apparent parent, or an interactive tool like PowerShell parented by a service that never starts it.
How to reduce the risk
MITRE does not list a dedicated mitigation for this sub-technique. The practical defenses are those for the family:
- Limit local administrator rights, because privileged use needs access rights to the target parent.
- Limit who can create tokens, using the Create a token object right.
- Keep Office from spawning children at all with Attack Surface Reduction rules, so there is less need to hide.
Check your own environment
On a Windows host that logs process creation, a read-only look at recent events:
wevtutil qe Security /q:"*[System[(EventID=4688)]]" /c:20 /rd:true /f:text
This works only when process creation auditing is enabled. If it returns nothing, that is the first finding. Make sure the creator process fields and, if you use it, Sysmon's parent GUID are going to your log store.
Quick check
Why would an attacker spoof the parent as explorer.exe?
To avoid rules that flag a process spawned from an Office document, or other unusual parent and child pairs.
Which three log fields can disagree when the parent is forged?
The ETW event header process ID, the Security 4688 creator process, and the Sysmon ParentProcessGuid.
Sources
- MITRE ATT&CK, T1134.004 Parent PID Spoofing
