Privilege Escalation via Named Pipe Impersonation
Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by utilizing a framework such as Metasploit's meterpreter getsystem command.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/11/23"
3integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by
11utilizing a framework such as Metasploit's meterpreter getsystem command.
12"""
13from = "now-9m"
14index = [
15 "endgame-*",
16 "logs-crowdstrike.fdr*",
17 "logs-endpoint.events.process-*",
18 "logs-m365_defender.event-*",
19 "logs-sentinel_one_cloud_funnel.*",
20 "logs-system.security*",
21 "logs-windows.forwarded*",
22 "logs-windows.sysmon_operational-*",
23 "winlogbeat-*",
24]
25language = "eql"
26license = "Elastic License v2"
27name = "Privilege Escalation via Named Pipe Impersonation"
28references = [
29 "https://www.ired.team/offensive-security/privilege-escalation/windows-namedpipes-privilege-escalation",
30 "https://www.cobaltstrike.com/blog/what-happens-when-i-type-getsystem/",
31 "https://redcanary.com/blog/getsystem-offsec/",
32]
33risk_score = 73
34rule_id = "3ecbdc9e-e4f2-43fa-8cca-63802125e582"
35severity = "high"
36tags = [
37 "Domain: Endpoint",
38 "OS: Windows",
39 "Use Case: Threat Detection",
40 "Tactic: Privilege Escalation",
41 "Resources: Investigation Guide",
42 "Data Source: Elastic Endgame",
43 "Data Source: Elastic Defend",
44 "Data Source: Windows Security Event Logs",
45 "Data Source: Microsoft Defender XDR",
46 "Data Source: Sysmon",
47 "Data Source: SentinelOne",
48 "Data Source: Crowdstrike",
49 "Noise: Low",
50 "Performance: Normal",
51 "Rule Type: Event Correlation (EQL)",
52 "Platform: Windows",
53]
54timestamp_override = "event.ingested"
55type = "eql"
56
57query = '''
58process where host.os.type == "windows" and event.type == "start" and
59 (process.name : ("Cmd.Exe", "PowerShell.EXE") or ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE")) and
60 process.args : "echo" and process.args : ">" and process.args : "\\\\.\\pipe\\*"
61'''
62
63note = """## Triage and analysis
64
65### Investigating Privilege Escalation via Named Pipe Impersonation
66
67#### Possible investigation steps
68
69- Did the alert process act as a named-pipe client for a SYSTEM-token handoff?
70 - Why: GetSystem-style abuse pairs a service-context client with a named-pipe server so the server can impersonate the client token; the shell pipe-write is the client-side marker.
71 - Focus: `process.name`, `process.pe.original_file_name`, `process.command_line`, `host.id`, and `user.id`.
72 - Implication: escalate when cmd or PowerShell sends a short marker into a named pipe before token impersonation; lower suspicion only when the same pipe name, marker, host, and user match a stable validation pattern.
73- Does the parent and token context fit a service-driven impersonation attempt?
74 - Focus: `process.parent.name`, `process.parent.command_line`, broader process lineage when needed, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`. $investigate_0
75 - Implication: escalate when services.exe, service-creation command lines, or an unexplained launcher starts the pipe write under high or SYSTEM context; absent or ambiguous token context cannot close the alert without matching identity and follow-on evidence.
76- Is the launching binary the expected Windows shell or a masqueraded copy?
77 - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
78 - Implication: escalate when the shell runs from a user-writable or deceptive path, has an untrusted signer, or mismatches its original file name; signed System32 cmd or PowerShell confirms identity only and does not clear the pipe-write behavior.
79- Did the pipe writer launch or enable follow-on SYSTEM activity?
80 - Focus: child process events from `process.entity_id`; review `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. $investigate_1
81 - Implication: escalate when a shell, tool, service helper, or credential-access process follows under high or SYSTEM integrity; absence of child process evidence lowers only follow-on confidence when pipe syntax or service parentage remains suspicious.
82 - Hint: if `process.entity_id` is unavailable, use `host.id` plus `process.pid` in a tight alert-time window and treat matches as weaker.
83- Is this isolated, or part of repeated named-pipe impersonation behavior?
84 - Focus: process starts sharing `host.id` or `user.id`, marker behavior in `process.command_line`, and either `process.parent.name` or `process.hash.sha256`.
85 - $investigate_2
86 - $investigate_3
87 - Implication: escalate scope when repeats cross hosts, users, hashes, or parent chains; keep response local only when all repeats stay inside the same process-evidenced validation pattern.
88 - Range: start with the alert window; expand only if local evidence is suspicious or unresolved.
89- Escalate on suspicious pipe-write syntax, parent/token context, binary identity, follow-on process activity, or host/user scope; close only when all evidence matches a stable validation pattern with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete.
90
91### False positive analysis
92
93- Routine administration should not require shell echo redirection into a named pipe for privilege escalation. Controlled security validation is the narrow benign path; process evidence must prove the exact pattern:
94 - **Identity**: `process.executable`, `process.hash.sha256`, signer, and `process.parent.command_line` match the validation toolchain.
95 - **Pipe syntax**: `process.command_line` shows the expected pipe name, echo value, and wrapper syntax for that test.
96 - **Scope**: `host.id` and `user.id` stay inside the known test target and operator scope.
97 - **Follow-on**: child process starts do not show unexpected high or SYSTEM activity outside the test plan.
98 - If telemetry cannot prove the test scope or toolchain, outside confirmation can corroborate the case but cannot override contradictory process evidence; otherwise preserve and escalate.
99- Build exceptions only from the minimum confirmed validation pattern: stable `process.hash.sha256`, `process.executable`, `process.parent.command_line`, constrained `host.id` or `user.id`, and the specific pipe-write shape in `process.command_line`. Avoid exceptions on `process.name`, cmd or PowerShell alone, or a pipe name alone.
100
101### Response and remediation
102
103- If confirmed benign:
104 - Reverse any temporary containment and document the evidence that confirmed the validation workflow: pipe syntax, parent/token context, binary identity, `host.id`, `user.id`, and lack of unexpected follow-on SYSTEM activity.
105- If suspicious but unconfirmed:
106 - Preserve the alert, process tree, command lines, parent and child process records, `process.entity_id`, `process.pid`, hashes, and the named-pipe string before termination, cleanup, or credential actions.
107 - Apply reversible containment tied to the findings, such as isolating the endpoint after weighing host criticality or restricting the affected account/session while investigation continues.
108 - Do not terminate cmd, PowerShell, or child processes until the process identifiers, command lines, and any volatile state needed by responders are captured.
109- If confirmed malicious:
110 - Isolate the endpoint after preservation when parent/token, identity, or follow-on process evidence confirms unauthorized SYSTEM activity.
111 - Suspend or terminate the pipe writer and follow-on processes only after recording their entity IDs, PIDs, command lines, hashes, and parent relationships.
112 - Reset credentials or revoke sessions for affected users only when process/session evidence indicates account misuse or credential exposure.
113 - Eradicate only malicious tools, service definitions, binaries, scripts, and configuration changes confirmed during the investigation, then remediate the entry vector that allowed the named-pipe impersonation attempt.
114- Post-incident hardening:
115 - Restrict local admin and service-creation rights that allow untrusted tooling to create SYSTEM service clients.
116 - Retain command-line, parent/child process, and token-integrity telemetry because those fields distinguish testing from GetSystem abuse.
117 - Document the confirmed benign validation pattern or malicious artifact set so future analysts can separate repeat testing from repeat abuse.
118"""
119
120setup = """## Setup
121
122This 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.
123
124Setup instructions: https://ela.st/install-elastic-defend
125
126### Additional data sources
127
128This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
129
130- [CrowdStrike](https://ela.st/crowdstrike-integration)
131- [Microsoft Defender XDR](https://ela.st/m365-defender)
132- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
133- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
134- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
135"""
136
137[rule.investigation_fields]
138field_names = [
139 "@timestamp",
140 "host.id",
141 "user.id",
142 "process.entity_id",
143 "process.pid",
144 "process.executable",
145 "process.command_line",
146 "process.args",
147 "process.pe.original_file_name",
148 "process.code_signature.subject_name",
149 "process.code_signature.trusted",
150 "process.hash.sha256",
151 "process.Ext.token.integrity_level_name",
152 "process.parent.executable",
153 "process.parent.command_line",
154]
155
156[transform]
157
158[[transform.investigate]]
159label = "Process starts on the host near the pipe write"
160description = ""
161providers = [
162 [
163 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
164 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
165 ]
166]
167relativeFrom = "now-1h"
168relativeTo = "now"
169
170[[transform.investigate]]
171label = "Child process starts from the pipe writer"
172description = ""
173providers = [
174 [
175 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
176 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
177 { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
178 ],
179 [
180 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
181 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
182 { excluded = false, field = "process.parent.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
183 ]
184]
185relativeFrom = "now-1h"
186relativeTo = "now"
187
188[[transform.investigate]]
189label = "Alerts associated with the host"
190description = ""
191providers = [
192 [
193 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
194 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
195 ]
196]
197relativeFrom = "now-48h/h"
198relativeTo = "now"
199
200[[transform.investigate]]
201label = "Alerts associated with the user"
202description = ""
203providers = [
204 [
205 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
206 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
207 ]
208]
209relativeFrom = "now-48h/h"
210relativeTo = "now"
211
212[[rule.threat]]
213framework = "MITRE ATT&CK"
214
215[[rule.threat.technique]]
216id = "T1134"
217name = "Access Token Manipulation"
218reference = "https://attack.mitre.org/techniques/T1134/"
219
220[[rule.threat.technique.subtechnique]]
221id = "T1134.001"
222name = "Token Impersonation/Theft"
223reference = "https://attack.mitre.org/techniques/T1134/001/"
224
225[rule.threat.tactic]
226id = "TA0004"
227name = "Privilege Escalation"
228reference = "https://attack.mitre.org/tactics/TA0004/"
Triage and analysis
Investigating Privilege Escalation via Named Pipe Impersonation
Possible investigation steps
- Did the alert process act as a named-pipe client for a SYSTEM-token handoff?
- Why: GetSystem-style abuse pairs a service-context client with a named-pipe server so the server can impersonate the client token; the shell pipe-write is the client-side marker.
- Focus:
process.name,process.pe.original_file_name,process.command_line,host.id, anduser.id. - Implication: escalate when cmd or PowerShell sends a short marker into a named pipe before token impersonation; lower suspicion only when the same pipe name, marker, host, and user match a stable validation pattern.
- Does the parent and token context fit a service-driven impersonation attempt?
- Focus:
process.parent.name,process.parent.command_line, broader process lineage when needed,process.Ext.token.integrity_level_name, andprocess.Ext.token.elevation_level. $investigate_0 - Implication: escalate when services.exe, service-creation command lines, or an unexplained launcher starts the pipe write under high or SYSTEM context; absent or ambiguous token context cannot close the alert without matching identity and follow-on evidence.
- Focus:
- Is the launching binary the expected Windows shell or a masqueraded copy?
- Focus:
process.executable,process.hash.sha256,process.pe.original_file_name,process.code_signature.subject_name, andprocess.code_signature.trusted. - Implication: escalate when the shell runs from a user-writable or deceptive path, has an untrusted signer, or mismatches its original file name; signed System32 cmd or PowerShell confirms identity only and does not clear the pipe-write behavior.
- Focus:
- Did the pipe writer launch or enable follow-on SYSTEM activity?
- Focus: child process events from
process.entity_id; reviewprocess.name,process.command_line, andprocess.Ext.token.integrity_level_name. $investigate_1 - Implication: escalate when a shell, tool, service helper, or credential-access process follows under high or SYSTEM integrity; absence of child process evidence lowers only follow-on confidence when pipe syntax or service parentage remains suspicious.
- Hint: if
process.entity_idis unavailable, usehost.idplusprocess.pidin a tight alert-time window and treat matches as weaker.
- Focus: child process events from
- Is this isolated, or part of repeated named-pipe impersonation behavior?
- Focus: process starts sharing
host.idoruser.id, marker behavior inprocess.command_line, and eitherprocess.parent.nameorprocess.hash.sha256.- $investigate_2
- $investigate_3
- Implication: escalate scope when repeats cross hosts, users, hashes, or parent chains; keep response local only when all repeats stay inside the same process-evidenced validation pattern.
- Range: start with the alert window; expand only if local evidence is suspicious or unresolved.
- Focus: process starts sharing
- Escalate on suspicious pipe-write syntax, parent/token context, binary identity, follow-on process activity, or host/user scope; close only when all evidence matches a stable validation pattern with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete.
False positive analysis
- Routine administration should not require shell echo redirection into a named pipe for privilege escalation. Controlled security validation is the narrow benign path; process evidence must prove the exact pattern:
- Identity:
process.executable,process.hash.sha256, signer, andprocess.parent.command_linematch the validation toolchain. - Pipe syntax:
process.command_lineshows the expected pipe name, echo value, and wrapper syntax for that test. - Scope:
host.idanduser.idstay inside the known test target and operator scope. - Follow-on: child process starts do not show unexpected high or SYSTEM activity outside the test plan.
- If telemetry cannot prove the test scope or toolchain, outside confirmation can corroborate the case but cannot override contradictory process evidence; otherwise preserve and escalate.
- Identity:
- Build exceptions only from the minimum confirmed validation pattern: stable
process.hash.sha256,process.executable,process.parent.command_line, constrainedhost.idoruser.id, and the specific pipe-write shape inprocess.command_line. Avoid exceptions onprocess.name, cmd or PowerShell alone, or a pipe name alone.
Response and remediation
- If confirmed benign:
- Reverse any temporary containment and document the evidence that confirmed the validation workflow: pipe syntax, parent/token context, binary identity,
host.id,user.id, and lack of unexpected follow-on SYSTEM activity.
- Reverse any temporary containment and document the evidence that confirmed the validation workflow: pipe syntax, parent/token context, binary identity,
- If suspicious but unconfirmed:
- Preserve the alert, process tree, command lines, parent and child process records,
process.entity_id,process.pid, hashes, and the named-pipe string before termination, cleanup, or credential actions. - Apply reversible containment tied to the findings, such as isolating the endpoint after weighing host criticality or restricting the affected account/session while investigation continues.
- Do not terminate cmd, PowerShell, or child processes until the process identifiers, command lines, and any volatile state needed by responders are captured.
- Preserve the alert, process tree, command lines, parent and child process records,
- If confirmed malicious:
- Isolate the endpoint after preservation when parent/token, identity, or follow-on process evidence confirms unauthorized SYSTEM activity.
- Suspend or terminate the pipe writer and follow-on processes only after recording their entity IDs, PIDs, command lines, hashes, and parent relationships.
- Reset credentials or revoke sessions for affected users only when process/session evidence indicates account misuse or credential exposure.
- Eradicate only malicious tools, service definitions, binaries, scripts, and configuration changes confirmed during the investigation, then remediate the entry vector that allowed the named-pipe impersonation attempt.
- Post-incident hardening:
- Restrict local admin and service-creation rights that allow untrusted tooling to create SYSTEM service clients.
- Retain command-line, parent/child process, and token-integrity telemetry because those fields distinguish testing from GetSystem abuse.
- Document the confirmed benign validation pattern or malicious artifact set so future analysts can separate repeat testing from repeat abuse.
References
Related rules
- Active Directory Discovery using AdExplorer
- Bypass UAC via Event Viewer
- Code Signing Policy Modification Through Built-in tools
- Enumerating Domain Trusts via DSQUERY.EXE
- Execution via TSClient Mountpoint