Parent Process PID Spoofing
Identifies parent process spoofing used to thwart detection. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/07/14"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2026/04/30"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies parent process spoofing used to thwart detection. Adversaries may spoof the parent process identifier (PPID)
11of a new process to evade process-monitoring defenses or to elevate privileges.
12"""
13from = "now-9m"
14index = ["logs-endpoint.events.process-*"]
15language = "eql"
16license = "Elastic License v2"
17name = "Parent Process PID Spoofing"
18references = [
19 "https://blog.didierstevens.com/2017/03/20/that-is-not-my-child-process/",
20 "https://www.elastic.co/security-labs/elastic-security-labs-steps-through-the-r77-rootkit",
21]
22risk_score = 73
23rule_id = "c88d4bd0-5649-4c52-87ea-9be59dbfbcf2"
24severity = "high"
25tags = [
26 "Domain: Endpoint",
27 "OS: Windows",
28 "Use Case: Threat Detection",
29 "Tactic: Defense Evasion",
30 "Data Source: Elastic Defend",
31 "Resources: Investigation Guide",
32]
33type = "eql"
34
35query = '''
36/* This rule is compatible with Elastic Endpoint only */
37
38sequence by host.id, user.id with maxspan=3m
39
40 [process where host.os.type == "windows" and event.type == "start" and
41 process.Ext.token.integrity_level_name != "system" and
42 (
43 process.pe.original_file_name : ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe", "eqnedt32.exe",
44 "fltldr.exe", "mspub.exe", "msaccess.exe", "powershell.exe", "pwsh.exe",
45 "cscript.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "msbuild.exe",
46 "mshta.exe", "wmic.exe", "cmstp.exe", "msxsl.exe") or
47
48 (process.executable : ("?:\\Users\\*.exe",
49 "?:\\ProgramData\\*.exe",
50 "?:\\Windows\\Temp\\*.exe",
51 "?:\\Windows\\Tasks\\*") and
52 (process.code_signature.exists == false or process.code_signature.status : "errorBadDigest")) or
53
54 process.executable : "?:\\Windows\\Microsoft.NET\\*.exe"
55 ) and
56
57 not process.executable :
58 ("?:\\Windows\\System32\\WerFaultSecure.exe",
59 "?:\\WINDOWS\\SysWOW64\\WerFaultSecure.exe",
60 "?:\\Windows\\System32\\WerFault.exe",
61 "?:\\Windows\\SysWOW64\\WerFault.exe")
62 ] by process.pid
63 [process where host.os.type == "windows" and event.type == "start" and
64 process.parent.Ext.real.pid > 0 and
65
66 /* process.parent.Ext.real.pid is only populated if the parent process pid doesn't match */
67 not (process.name : "msedge.exe" and process.parent.name : "sihost.exe") and
68
69 not process.executable :
70 ("?:\\Windows\\System32\\WerFaultSecure.exe",
71 "?:\\WINDOWS\\SysWOW64\\WerFaultSecure.exe",
72 "?:\\Windows\\System32\\WerFault.exe",
73 "?:\\Windows\\SysWOW64\\WerFault.exe")
74 ] by process.parent.Ext.real.pid
75'''
76
77note = """## Triage and analysis
78
79### Investigating Parent Process PID Spoofing
80
81#### Possible investigation steps
82
83- Which source events prove the real creator, spoofed child, and visible-parent mismatch?
84 - Focus: Timeline source events for shared `host.id` and `user.id`; record creator and child `process.entity_id`, `process.pid`, `process.executable`, and child `process.parent.pid` versus `process.parent.Ext.real.pid`.
85 - Hint: the sequence alert may not expose `process.parent.Ext.real.pid`; use the recovered child event. If absent, empty, or mapped to multiple creator candidates, treat recovery as unresolved, not benign.
86 - Implication: escalate when `process.parent.Ext.real.pid` maps to the recovered creator while the child reports a different visible parent with no brokered-launch explanation; lower suspicion when both events resolve to one recognized broker, installer, support, or sensor-corrected path for the same product/user.
87- Does the recovered creator look like a plausible spoofing initiator?
88 - Focus: creator `process.pe.original_file_name`, `process.executable`, `process.command_line`, `process.code_signature.exists`, and `process.code_signature.status`.
89 - Implication: higher concern when the creator is an Office process, script host, LOLBin, user-writable or .NET executable, or unsigned/bad-signature binary whose command line does not fit software deployment; lower suspicion when creator identity and command line fit the recognized updater, installer, EDR, or support component from step 1.
90- Is the spoofed child a credible target for cover or a likely payload?
91 - Focus: child `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.Ext.relative_file_creation_time`, and file events for the child path. $investigate_0
92 - Implication: escalate when the child is newly created, unsigned or untrusted, renamed, or launched from user-writable, temp, task, or unusual .NET paths; lower suspicion when path, signer, original file name, and file age match the same recognized product layout. Identity alone does not clear lineage manipulation.
93- Is the visible parent credible for this child?
94 - Focus: child `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, and `process.parent.pid`, compared with recovered creator `process.entity_id`.
95 - Implication: stronger evidence of deliberate cover when the visible parent is a trusted system, shell, productivity, or management process with no command context or product relationship to the child; lower suspicion when a recognized service, compatibility layer, or broker mediates that exact child on this host.
96- Does user, session, or token context raise severity?
97 - Focus: `user.id`, `user.domain`, child `process.Ext.session_info.logon_type`, and `process.Ext.token.integrity_level_name`.
98 - Implication: escalate faster when the chain runs under an unexpected account, remote or network session, service context, or higher integrity than the creator-child role explains; lower suspicion when user, session, integrity, and host pairing fit the recovered support or management workflow.
99- Did the spoofed child immediately continue execution in a way that matches payload launch or hollowing?
100 - Focus: recovered child `process.entity_id` and descendants where `process.parent.entity_id` matches it, checking `process.Ext.created_suspended`, `process.command_line`, and descendant `process.executable`. $investigate_1
101 - Implication: escalate when the child is created suspended, spawns shells, script hosts, credential tools, unusual binaries, or synthetic process-id/GUID-like command-line values; lower suspicion when descendants stay inside the recovered product workflow.
102- If local lineage remains suspicious or unresolved, do related alerts change scope?
103 - Focus: related alerts for the same `user.id`: PPID spoofing, unusual parent-child, injection, suspicious launcher, or payload execution. $investigate_2
104 - Hint: if user scope is sparse or ambiguous, check the same `host.id`. $investigate_3
105 - Implication: broaden scope when the same user or host shows related process manipulation or payload activity; keep local when related alerts are quiet and source-event evidence resolves to one recognized workflow.
106
107- Escalate when source recovery, creator role, visible-parent mismatch, child identity, session/token context, or follow-on behavior indicates deliberate lineage manipulation or payload launch; close only when all recovered process evidence binds to one exact recognized brokered-launch workflow with no contradiction; preserve source events and escalate when evidence is mixed or incomplete.
108
109### False positive analysis
110
111- Treat installers, updaters, application brokers, remote-support tools, and endpoint-security components as candidate explanations, not benign categories. Close only when one recovered creator-child-visible-parent tuple is internally consistent across creator and child `process.executable`, visible parent `process.parent.executable`, signer `process.code_signature.subject_name`, command intent `process.command_line`, session type `process.Ext.session_info.logon_type`, and the same `user.id` plus `host.id`. If telemetry cannot prove legitimacy, require outside confirmation for that exact activity before closing.
112- Before creating an exception, validate recurrence of the same recovered creator-child-visible-parent pattern for the same host or user cohort across prior alerts from this rule. Anchor on stable creator, child, and visible-parent executables, `process.code_signature.subject_name`, session/integrity context, and relevant `host.id` or `user.id`; avoid exceptions on `process.name`, process IDs, or real-parent PID values alone.
113
114### Response and remediation
115
116- Before containment reversal, isolation, process termination, or cleanup, preserve Timeline source events, recovered creator and child `process.entity_id` values, the real-vs-visible parent PID mapping, command lines, signer/hash context, session/token context, and descendant process events.
117- If confirmed benign after preservation, reverse temporary containment and document the exact creator-child-visible-parent workflow, including stable creator and child identity, visible parent identity, signer, command context, session type, and `host.id` or `user.id` scope. Create an exception only after recurrence or outside confirmation proves the same workflow.
118- Apply reversible containment first: heightened monitoring, temporary user-session containment, or policy controls on affected `host.id` and `user.id`; use host isolation only when recovered lineage, abnormal token/session context, created-suspended evidence, or suspicious descendants indicate likely payload execution or spread.
119- If confirmed malicious after preservation, isolate the endpoint or affected account scope according to evidence; take credential action only when session or token evidence indicates account misuse. Terminate the malicious process tree only after recording creator and child entity IDs, command lines, visible parent, and descendant process evidence.
120- Remove the malicious launcher, spoofed child binary, and any payload artifacts identified during investigation; restore only confirmed configuration changes tied to the launch path, and remediate the entry vector. Delay destructive cleanup until scoping has captured the same creator, child, signer, or parent-selection pattern across related host and user alerts.
121- Post-incident hardening: restrict only the confirmed parent-selection path and retain endpoint process telemetry needed to compare the recovered real creator with the visible parent in future repeat alerts."""
122
123setup = """## Setup
124
125This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
126
127Setup instructions: https://ela.st/install-elastic-defend
128"""
129
130[rule.investigation_fields]
131field_names = [
132 "@timestamp",
133 "host.id",
134 "host.name",
135 "user.id",
136 "user.name",
137 "process.entity_id",
138 "process.pid",
139 "process.executable",
140 "process.command_line",
141 "process.Ext.token.integrity_level_name",
142 "process.parent.pid",
143 "process.parent.name",
144 "process.parent.executable",
145 "process.code_signature.subject_name",
146 "process.code_signature.trusted",
147]
148
149[transform]
150
151[[transform.investigate]]
152label = "File events for the spoofed child path"
153description = ""
154providers = [
155 [
156 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
157 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
158 { excluded = false, field = "file.path", queryType = "phrase", value = "{{process.executable}}", valueType = "string" }
159 ]
160]
161relativeFrom = "now-24h"
162relativeTo = "now"
163
164[[transform.investigate]]
165label = "Descendant process events for the spoofed child"
166description = ""
167providers = [
168 [
169 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
170 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
171 { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
172 ]
173]
174relativeFrom = "now-1h"
175relativeTo = "now"
176
177[[transform.investigate]]
178label = "Alerts associated with the user"
179description = ""
180providers = [
181 [
182 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
183 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
184 ]
185]
186relativeFrom = "now-48h/h"
187relativeTo = "now"
188
189[[transform.investigate]]
190label = "Alerts associated with the host"
191description = ""
192providers = [
193 [
194 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
195 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
196 ]
197]
198relativeFrom = "now-48h/h"
199relativeTo = "now"
200
201[[rule.threat]]
202framework = "MITRE ATT&CK"
203[[rule.threat.technique]]
204id = "T1134"
205name = "Access Token Manipulation"
206reference = "https://attack.mitre.org/techniques/T1134/"
207[[rule.threat.technique.subtechnique]]
208id = "T1134.004"
209name = "Parent PID Spoofing"
210reference = "https://attack.mitre.org/techniques/T1134/004/"
211
212[rule.threat.tactic]
213id = "TA0005"
214name = "Defense Evasion"
215reference = "https://attack.mitre.org/tactics/TA0005/"
216
217[[rule.threat]]
218framework = "MITRE ATT&CK"
219[[rule.threat.technique]]
220id = "T1134"
221name = "Access Token Manipulation"
222reference = "https://attack.mitre.org/techniques/T1134/"
223[[rule.threat.technique.subtechnique]]
224id = "T1134.004"
225name = "Parent PID Spoofing"
226reference = "https://attack.mitre.org/techniques/T1134/004/"
227
228[rule.threat.tactic]
229id = "TA0004"
230name = "Privilege Escalation"
231reference = "https://attack.mitre.org/tactics/TA0004/"
Triage and analysis
Investigating Parent Process PID Spoofing
Possible investigation steps
-
Which source events prove the real creator, spoofed child, and visible-parent mismatch?
- Focus: Timeline source events for shared
host.idanduser.id; record creator and childprocess.entity_id,process.pid,process.executable, and childprocess.parent.pidversusprocess.parent.Ext.real.pid. - Hint: the sequence alert may not expose
process.parent.Ext.real.pid; use the recovered child event. If absent, empty, or mapped to multiple creator candidates, treat recovery as unresolved, not benign. - Implication: escalate when
process.parent.Ext.real.pidmaps to the recovered creator while the child reports a different visible parent with no brokered-launch explanation; lower suspicion when both events resolve to one recognized broker, installer, support, or sensor-corrected path for the same product/user.
- Focus: Timeline source events for shared
-
Does the recovered creator look like a plausible spoofing initiator?
- Focus: creator
process.pe.original_file_name,process.executable,process.command_line,process.code_signature.exists, andprocess.code_signature.status. - Implication: higher concern when the creator is an Office process, script host, LOLBin, user-writable or .NET executable, or unsigned/bad-signature binary whose command line does not fit software deployment; lower suspicion when creator identity and command line fit the recognized updater, installer, EDR, or support component from step 1.
- Focus: creator
-
Is the spoofed child a credible target for cover or a likely payload?
- Focus: child
process.executable,process.pe.original_file_name,process.code_signature.subject_name,process.code_signature.trusted,process.Ext.relative_file_creation_time, and file events for the child path. $investigate_0 - Implication: escalate when the child is newly created, unsigned or untrusted, renamed, or launched from user-writable, temp, task, or unusual .NET paths; lower suspicion when path, signer, original file name, and file age match the same recognized product layout. Identity alone does not clear lineage manipulation.
- Focus: child
-
Is the visible parent credible for this child?
- Focus: child
process.parent.name,process.parent.executable,process.parent.command_line, andprocess.parent.pid, compared with recovered creatorprocess.entity_id. - Implication: stronger evidence of deliberate cover when the visible parent is a trusted system, shell, productivity, or management process with no command context or product relationship to the child; lower suspicion when a recognized service, compatibility layer, or broker mediates that exact child on this host.
- Focus: child
-
Does user, session, or token context raise severity?
- Focus:
user.id,user.domain, childprocess.Ext.session_info.logon_type, andprocess.Ext.token.integrity_level_name. - Implication: escalate faster when the chain runs under an unexpected account, remote or network session, service context, or higher integrity than the creator-child role explains; lower suspicion when user, session, integrity, and host pairing fit the recovered support or management workflow.
- Focus:
-
Did the spoofed child immediately continue execution in a way that matches payload launch or hollowing?
- Focus: recovered child
process.entity_idand descendants whereprocess.parent.entity_idmatches it, checkingprocess.Ext.created_suspended,process.command_line, and descendantprocess.executable. $investigate_1 - Implication: escalate when the child is created suspended, spawns shells, script hosts, credential tools, unusual binaries, or synthetic process-id/GUID-like command-line values; lower suspicion when descendants stay inside the recovered product workflow.
- Focus: recovered child
-
If local lineage remains suspicious or unresolved, do related alerts change scope?
- Focus: related alerts for the same
user.id: PPID spoofing, unusual parent-child, injection, suspicious launcher, or payload execution. $investigate_2 - Hint: if user scope is sparse or ambiguous, check the same
host.id. $investigate_3 - Implication: broaden scope when the same user or host shows related process manipulation or payload activity; keep local when related alerts are quiet and source-event evidence resolves to one recognized workflow.
- Focus: related alerts for the same
-
Escalate when source recovery, creator role, visible-parent mismatch, child identity, session/token context, or follow-on behavior indicates deliberate lineage manipulation or payload launch; close only when all recovered process evidence binds to one exact recognized brokered-launch workflow with no contradiction; preserve source events and escalate when evidence is mixed or incomplete.
False positive analysis
- Treat installers, updaters, application brokers, remote-support tools, and endpoint-security components as candidate explanations, not benign categories. Close only when one recovered creator-child-visible-parent tuple is internally consistent across creator and child
process.executable, visible parentprocess.parent.executable, signerprocess.code_signature.subject_name, command intentprocess.command_line, session typeprocess.Ext.session_info.logon_type, and the sameuser.idplushost.id. If telemetry cannot prove legitimacy, require outside confirmation for that exact activity before closing. - Before creating an exception, validate recurrence of the same recovered creator-child-visible-parent pattern for the same host or user cohort across prior alerts from this rule. Anchor on stable creator, child, and visible-parent executables,
process.code_signature.subject_name, session/integrity context, and relevanthost.idoruser.id; avoid exceptions onprocess.name, process IDs, or real-parent PID values alone.
Response and remediation
- Before containment reversal, isolation, process termination, or cleanup, preserve Timeline source events, recovered creator and child
process.entity_idvalues, the real-vs-visible parent PID mapping, command lines, signer/hash context, session/token context, and descendant process events. - If confirmed benign after preservation, reverse temporary containment and document the exact creator-child-visible-parent workflow, including stable creator and child identity, visible parent identity, signer, command context, session type, and
host.idoruser.idscope. Create an exception only after recurrence or outside confirmation proves the same workflow. - Apply reversible containment first: heightened monitoring, temporary user-session containment, or policy controls on affected
host.idanduser.id; use host isolation only when recovered lineage, abnormal token/session context, created-suspended evidence, or suspicious descendants indicate likely payload execution or spread. - If confirmed malicious after preservation, isolate the endpoint or affected account scope according to evidence; take credential action only when session or token evidence indicates account misuse. Terminate the malicious process tree only after recording creator and child entity IDs, command lines, visible parent, and descendant process evidence.
- Remove the malicious launcher, spoofed child binary, and any payload artifacts identified during investigation; restore only confirmed configuration changes tied to the launch path, and remediate the entry vector. Delay destructive cleanup until scoping has captured the same creator, child, signer, or parent-selection pattern across related host and user alerts.
- Post-incident hardening: restrict only the confirmed parent-selection path and retain endpoint process telemetry needed to compare the recovered real creator with the visible parent in future repeat alerts.
References
Related rules
- Command Obfuscation via Unicode Modifier Letters
- Potential Remote Install via MsiExec
- Suspicious Microsoft Diagnostics Wizard Execution
- Attempt to Install or Run Kali Linux via WSL
- Script Execution via Microsoft HTML Application