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/05/03"
  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]
 50timestamp_override = "event.ingested"
 51type = "eql"
 52
 53query = '''
 54process where host.os.type == "windows" and event.type == "start" and
 55 (process.name : ("Cmd.Exe", "PowerShell.EXE") or ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE")) and
 56 process.args : "echo" and process.args : ">" and process.args : "\\\\.\\pipe\\*"
 57'''
 58
 59note = """## Triage and analysis
 60
 61### Investigating Privilege Escalation via Named Pipe Impersonation
 62
 63#### Possible investigation steps
 64
 65- Did the alert process act as a named-pipe client for a SYSTEM-token handoff?
 66  - 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.
 67  - Focus: `process.name`, `process.pe.original_file_name`, `process.command_line`, `host.id`, and `user.id`.
 68  - 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.
 69- Does the parent and token context fit a service-driven impersonation attempt?
 70  - 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
 71  - 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.
 72- Is the launching binary the expected Windows shell or a masqueraded copy?
 73  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
 74  - 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.
 75- Did the pipe writer launch or enable follow-on SYSTEM activity?
 76  - Focus: child process events from `process.entity_id`; review `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. $investigate_1
 77  - 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.
 78  - Hint: if `process.entity_id` is unavailable, use `host.id` plus `process.pid` in a tight alert-time window and treat matches as weaker.
 79- Is this isolated, or part of repeated named-pipe impersonation behavior?
 80  - Focus: process starts sharing `host.id` or `user.id`, marker behavior in `process.command_line`, and either `process.parent.name` or `process.hash.sha256`.
 81    - $investigate_2
 82    - $investigate_3
 83  - 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.
 84  - Range: start with the alert window; expand only if local evidence is suspicious or unresolved.
 85- 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.
 86
 87### False positive analysis
 88
 89- 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:
 90  - **Identity**: `process.executable`, `process.hash.sha256`, signer, and `process.parent.command_line` match the validation toolchain.
 91  - **Pipe syntax**: `process.command_line` shows the expected pipe name, echo value, and wrapper syntax for that test.
 92  - **Scope**: `host.id` and `user.id` stay inside the known test target and operator scope.
 93  - **Follow-on**: child process starts do not show unexpected high or SYSTEM activity outside the test plan.
 94  - 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.
 95- 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.
 96
 97### Response and remediation
 98
 99- If confirmed benign:
100  - 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.
101- If suspicious but unconfirmed:
102  - 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.
103  - 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.
104  - Do not terminate cmd, PowerShell, or child processes until the process identifiers, command lines, and any volatile state needed by responders are captured.
105- If confirmed malicious:
106  - Isolate the endpoint after preservation when parent/token, identity, or follow-on process evidence confirms unauthorized SYSTEM activity.
107  - Suspend or terminate the pipe writer and follow-on processes only after recording their entity IDs, PIDs, command lines, hashes, and parent relationships.
108  - Reset credentials or revoke sessions for affected users only when process/session evidence indicates account misuse or credential exposure.
109  - 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.
110- Post-incident hardening:
111  - Restrict local admin and service-creation rights that allow untrusted tooling to create SYSTEM service clients.
112  - Retain command-line, parent/child process, and token-integrity telemetry because those fields distinguish testing from GetSystem abuse.
113  - Document the confirmed benign validation pattern or malicious artifact set so future analysts can separate repeat testing from repeat abuse.
114"""
115
116setup = """## Setup
117
118This 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.
119
120Setup instructions: https://ela.st/install-elastic-defend
121
122### Additional data sources
123
124This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
125
126- [CrowdStrike](https://ela.st/crowdstrike-integration)
127- [Microsoft Defender XDR](https://ela.st/m365-defender)
128- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
129- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
130- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
131"""
132
133[rule.investigation_fields]
134field_names = [
135    "@timestamp",
136    "host.id",
137    "user.id",
138    "process.entity_id",
139    "process.pid",
140    "process.executable",
141    "process.command_line",
142    "process.args",
143    "process.pe.original_file_name",
144    "process.code_signature.subject_name",
145    "process.code_signature.trusted",
146    "process.hash.sha256",
147    "process.Ext.token.integrity_level_name",
148    "process.parent.executable",
149    "process.parent.command_line",
150]
151
152[transform]
153
154[[transform.investigate]]
155label = "Process starts on the host near the pipe write"
156description = ""
157providers = [
158  [
159    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
160    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
161  ]
162]
163relativeFrom = "now-1h"
164relativeTo = "now"
165
166[[transform.investigate]]
167label = "Child process starts from the pipe writer"
168description = ""
169providers = [
170  [
171    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
172    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
173    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
174  ],
175  [
176    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
177    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
178    { excluded = false, field = "process.parent.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
179  ]
180]
181relativeFrom = "now-1h"
182relativeTo = "now"
183
184[[transform.investigate]]
185label = "Alerts associated with the host"
186description = ""
187providers = [
188  [
189    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
190    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
191  ]
192]
193relativeFrom = "now-48h/h"
194relativeTo = "now"
195
196[[transform.investigate]]
197label = "Alerts associated with the user"
198description = ""
199providers = [
200  [
201    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
202    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
203  ]
204]
205relativeFrom = "now-48h/h"
206relativeTo = "now"
207
208[[rule.threat]]
209framework = "MITRE ATT&CK"
210
211[[rule.threat.technique]]
212id = "T1134"
213name = "Access Token Manipulation"
214reference = "https://attack.mitre.org/techniques/T1134/"
215
216[[rule.threat.technique.subtechnique]]
217id = "T1134.001"
218name = "Token Impersonation/Theft"
219reference = "https://attack.mitre.org/techniques/T1134/001/"
220
221[rule.threat.tactic]
222id = "TA0004"
223name = "Privilege Escalation"
224reference = "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, and user.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, and process.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.
  • 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, and process.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.
  • Did the pipe writer launch or enable follow-on SYSTEM activity?
    • Focus: child process events from process.entity_id; review process.name, process.command_line, and process.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_id is unavailable, use host.id plus process.pid in a tight alert-time window and treat matches as weaker.
  • Is this isolated, or part of repeated named-pipe impersonation behavior?
    • Focus: process starts sharing host.id or user.id, marker behavior in process.command_line, and either process.parent.name or process.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.
  • 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, and process.parent.command_line match the validation toolchain.
    • Pipe syntax: process.command_line shows the expected pipe name, echo value, and wrapper syntax for that test.
    • Scope: host.id and user.id stay 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.
  • 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.

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.
  • 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.
  • 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

to-top