« Potential Escalation via Vulnerable MSI Repair Suspicious Print Spooler Point and Print DLL »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.24

Privilege Escalation via Named Pipe Impersonation

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Privilege Escalation via Named Pipe Impersonation

edit

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.

Rule type: eql

Rule indices:

  • endgame-*
  • logs-crowdstrike.fdr*
  • logs-endpoint.events.process-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-system.security*
  • logs-windows.forwarded*
  • logs-windows.sysmon_operational-*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Privilege Escalation
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Windows Security Event Logs
  • Data Source: Microsoft Defender XDR
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Crowdstrike

Version: 319

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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{"description":"","label":"Process starts on the host near the pipe write","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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{"description":"","label":"Child process starts from the pipe writer","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
process where host.os.type == "windows" and event.type == "start" and
 (process.name : ("Cmd.Exe", "PowerShell.EXE") or ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE")) and
 process.args : "echo" and process.args : ">" and process.args : "\\\\.\\pipe\\*"

Framework: MITRE ATT&CKTM

« Potential Escalation via Vulnerable MSI Repair Suspicious Print Spooler Point and Print DLL »