« Unusual Process Network Connection Potential Evasion via Filter Manager »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Unusual Child Process from a System Virtual Process

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

Unusual Child Process from a System Virtual Process

edit

Identifies a suspicious child process of the Windows virtual system process, which could indicate code injection.

Rule type: eql

Rule indices:

  • endgame-*
  • 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: None

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • 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
  • Resources: Investigation Guide

Version: 319

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Unusual Child Process from a System Virtual Process

Possible investigation steps

  • Does the alert prove a real PID 4 child outside normal System-process exclusions?
  • Focus: alert-local process.parent.pid, process.parent.name, process.parent.executable, process.executable, and process.command_line.
  • Implication: escalate when PID 4 spawned a non-standard user-mode child whose path or command does not fit a signed system helper; lower suspicion only when identity and context fit one recognized boot, servicing, driver, security, or virtualization helper.
  • Is the child binary identity consistent with the claimed system component?
  • Focus: process.executable, process.hash.sha256, process.pe.original_file_name, process.code_signature.subject_name, and process.code_signature.trusted.
  • Implication: escalate when path, hash, original file name, or signer conflicts with the claimed binary, especially from user-writable or unusual system paths; lower suspicion only when signer, hash history, and path converge on one recognized product.
  • Does the child show drop, rename, or hollowing clues at start?
  • Focus: process.Ext.relative_file_creation_time, process.Ext.relative_file_name_modify_time, process.Ext.created_suspended, and process.command_line. !{investigate{"description":"","label":"File events for the child executable path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the executable is newly created or renamed, starts suspended, or invokes script/LOLBins; older stable timing and a product-consistent command lower concern but do not clear abnormal parentage alone.
  • Which account, session, and token context owned the child?
  • Focus: user.id, process.Ext.authentication_id, process.Ext.session_info.logon_type, and process.Ext.token.integrity_level_name.
  • Implication: escalate when a PID 4 child appears in an interactive, remote, or unexpected user context, or carries a token that does not fit the helper role; service or boot context lowers concern only when identity and behavior align.
  • Did the child launch follow-on processes that reveal intent?
  • Why: injected code can use a trusted or privileged process as a launcher, so the child process’s descendants may be the first visible operator action.
  • Focus: child process events from process.entity_id, reading process.executable, process.command_line, and process.Ext.ancestry. !{investigate{"description":"","label":"Process descendants spawned by the System-spawned child","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.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when descendants are scripting engines, admin tools, renamed binaries, or commands that do not fit the child identity; no descendants lowers urgency but does not clear abnormal identity, session, or timing.
  • If local evidence remains suspicious or unresolved, does the same child identity appear outside this host?
  • Focus: same-host related alerts plus process starts for process.hash.sha256, process.executable, and process.code_signature.subject_name. !{investigate{"description":"","label":"Process starts for the same child identity","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host in the last 48h","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"}}
  • Implication: broaden scope when the same child identity, signer mismatch, or descendant pattern appears on unrelated hosts; keep localized only when confined to one clean workflow on one host.
  • Escalate on abnormal or contradictory parentage, identity, start-state, session/token, descendant, or scope evidence; close only when all support one signed workflow; preserve and escalate when mixed or incomplete.

False positive analysis

  • Endpoint security, virtualization, hardware, driver, servicing, or boot workflows can legitimately spawn signed helpers from PID 4. Confirm process.executable, process.hash.sha256, process.code_signature.subject_name, session/token context, command line, start-state timing, and descendants all align with the same product or Microsoft servicing sequence. Use inventory or change records only after telemetry matches; if unavailable, require the same stable child identity and bounded descendant pattern to recur for the same host.id across prior alerts from this rule before exceptioning.
  • Before creating an exception, require recurrence for the same host.id plus stable process.hash.sha256, process.executable, process.code_signature.subject_name, and command or descendant pattern. Avoid exceptions on process.parent.pid, process.name, or the System parent condition alone.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the signed maintenance, security, driver, virtualization, or servicing workflow that matched the child identity, session/token context, command line, and descendant process pattern. Create an exception only after the same bounded pattern recurs.
  • If suspicious but unconfirmed, preserve the alert event, child and parent entity IDs, binary identity, command line, signer, session/token context, and descendant process events before containment. Apply reversible containment first; isolate only if the host role can tolerate it and the child or descendants show active suspicious behavior.
  • If confirmed malicious, isolate the host when process identity, session/token context, start-state clues, or descendant behavior establish unauthorized activity. Before termination, record the child and descendant process identifiers, command lines, hashes, signer details, and timeline evidence. Terminate the malicious child and descendants only after preservation, then remove only confirmed malicious artifacts or persistence changes identified during response and scope other hosts for the same child identity.
  • Post-incident hardening should determine why the System process spawned the child, review the responsible driver, service, security product, or exploit path, retain process telemetry needed for PID 4 parentage and descendant analysis, and document any adjacent blind spots for follow-up.

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.parent.pid == 4 and process.executable : "?*" and
  not process.executable : ("Registry", "MemCompression", "?:\\Windows\\System32\\smss.exe", "HotPatch")

Framework: MITRE ATT&CKTM

« Unusual Process Network Connection Potential Evasion via Filter Manager »