Loading

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.

Rule type: eql
Rule indices:

  • logs-endpoint.events.process-*

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Data Source: Elastic Defend
  • Resources: Investigation Guide

Version: 111
Rule authors:

  • Elastic

Rule license: Elastic License v2

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

  • Which source events prove the real creator, spoofed child, and visible-parent mismatch?

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

  • 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, and process.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.

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

  • Is the visible parent credible for this child?

    • Focus: child process.parent.name, process.parent.executable, process.parent.command_line, and process.parent.pid, compared with recovered creator process.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.

  • Does user, session, or token context raise severity?

    • Focus: user.id, user.domain, child process.Ext.session_info.logon_type, and process.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.

  • Did the spoofed child immediately continue execution in a way that matches payload launch or hollowing?

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

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

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

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
/* This rule is compatible with Elastic Endpoint only */

sequence by host.id, user.id with maxspan=3m

 [process where host.os.type == "windows" and event.type == "start" and
  process.Ext.token.integrity_level_name != "system" and
  (
    process.pe.original_file_name : ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe", "eqnedt32.exe",
                                     "fltldr.exe", "mspub.exe", "msaccess.exe", "powershell.exe", "pwsh.exe",
                                     "cscript.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "msbuild.exe",
                                     "mshta.exe", "wmic.exe", "cmstp.exe", "msxsl.exe") or

    (process.executable : ("?:\\Users\\*.exe",
                           "?:\\ProgramData\\*.exe",
                           "?:\\Windows\\Temp\\*.exe",
                           "?:\\Windows\\Tasks\\*") and
      (process.code_signature.exists == false or process.code_signature.status : "errorBadDigest")) or

    process.executable : "?:\\Windows\\Microsoft.NET\\*.exe"
  ) and

  not process.executable :
             ("?:\\Windows\\System32\\WerFaultSecure.exe",
              "?:\\WINDOWS\\SysWOW64\\WerFaultSecure.exe",
              "?:\\Windows\\System32\\WerFault.exe",
              "?:\\Windows\\SysWOW64\\WerFault.exe")
  ] by process.pid
 [process where host.os.type == "windows" and event.type == "start" and
  process.parent.Ext.real.pid > 0 and

  /* process.parent.Ext.real.pid is only populated if the parent process pid doesn't match */
  not (process.name : "msedge.exe" and process.parent.name : "sihost.exe") and

   not process.executable :
             ("?:\\Windows\\System32\\WerFaultSecure.exe",
              "?:\\WINDOWS\\SysWOW64\\WerFaultSecure.exe",
              "?:\\Windows\\System32\\WerFault.exe",
              "?:\\Windows\\SysWOW64\\WerFault.exe")
 ] by process.parent.Ext.real.pid

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK