Unusual Executable File Creation by a System Critical Process

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

Unusual Executable File Creation by a System Critical Process

edit

Identifies an unexpected executable file being created or modified by a Windows system critical process, which may indicate activity related to remote code execution or other forms of exploitation.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.file-*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-crowdstrike.fdr*

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
  • Tactic: Execution
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: Microsoft Defender XDR
  • Data Source: SentinelOne
  • Data Source: Crowdstrike

Version: 318

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Unusual Executable File Creation by a System Critical Process

Possible investigation steps

  • What exact critical-process write did the alert preserve?
  • Focus: process.name, process.executable, file.path, file.extension, and event.action; writer should match a critical-process name in the query.
  • Implication: escalate faster when it writes an EXE or DLL in user-writable, startup, temp, or other non-servicing paths; lower concern only for protected OS servicing paths or a repaired vendor product tree.
  • Is the writer the expected protected Windows binary, not a masquerade or tampered copy?
  • Why: exploitation for defense evasion can preserve a genuine protected-process identity while changing what that process writes.
  • Focus: process.executable, process.code_signature.subject_name, and process.code_signature.trusted; recover process.hash.sha256 and process.pe.original_file_name from matching process-start events on host.id and process.entity_id when absent. !{investigate{"description":"","label":"Process start for the writing process","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when path, signer, hash, or original file name conflicts with the expected critical process; if identity is the expected Microsoft binary, continue because exploitation can still force a genuine process to write attacker-controlled content.
  • What launch and user context led to the write?
  • Why: client-side or service exploitation often appears as Office, browser, script, archive, or user-profile ancestry before an abnormal critical-process file write.
  • Focus: matching process-start event: process.command_line, process.parent.executable, process.parent.command_line, process.Ext.ancestry, and user.id.
  • Implication: escalate when the chain traces to Office, browser, script, archive, LOLBin, or user-profile activity before the critical-process write; lower concern only when parentage and user context align with OS servicing or one bounded product repair.
  • Does the written artifact look staged or renamed rather than serviced?
  • Focus: file.path, file.Ext.original.path, file.Ext.original.extension, file.Ext.header_bytes, and file.Ext.windows.zone_identifier. !{investigate{"description":"","label":"File activity for the written path on this host","providers":[[{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when content is renamed into an executable extension, lands in a deceptive or writable path, carries internet provenance, or header bytes do not fit the file name.
  • Did the written file become an execution target or command-line dependency?
  • Focus: same-writer file activity on host.id and process.entity_id, plus later process starts from file.path. !{investigate{"description":"","label":"Events for the writing process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: for EXE reuse, inspect later process starts where process.executable equals file.path; for DLL writes, search process.command_line for the path and treat a quiet result as unresolved, not benign. !{investigate{"description":"","label":"Process starts from the written file path on this host","providers":[[{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{file.path}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","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.command_line","queryType":"phrase","value":"{{file.path}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the artifact executes or is referenced by follow-on commands; if the same-process file view is quiet, use the EXE or DLL recovery cue before lowering urgency.
  • If local evidence remains suspicious or unresolved, does the artifact pattern recur on this host or other hosts?
  • Focus: related alerts for the same written file.path; add writer process.executable only after alert or identity confirms it. !{investigate{"description":"","label":"Alerts associated with the written file path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: compare related alerts for the same host.id and host.name before broadening to other assets. !{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"}}
  • Implication: broaden scope when the same artifact path, writer identity, or follow-on execution appears on multiple hosts or repeats on the same host; localize when evidence stays limited to one short-lived, well-bounded servicing chain.
  • Escalate for abnormal identity, exploit-like lineage, staged content, execution/reference, or recurrence; close only when identity, lineage, artifact, and scope bind one servicing or vendor-maintenance workflow with no contradictions; preserve artifacts and escalate when evidence stays mixed or incomplete.

False positive analysis

  • Windows servicing/component repair or product/security-agent upgrade can replace binaries in protected OS or vendor paths. Confirm writer identity (process.executable, process.code_signature.subject_name, process.hash.sha256, process.pe.original_file_name), lineage (process.parent.executable, process.Ext.ancestry), and file.path all match one servicing or product workflow on the same host.id; for vendor repair, also require the path to stay inside the vendor directory and no user-writable staging, staged rename, or later execution from that path. If maintenance records are unavailable, use prior alerts from this rule for the same host and require the same protected path pattern without staged rename or later execution.
  • Before creating an exception, require recurrence for the same host.id plus stable process.executable, process.code_signature.subject_name, parent context, and protected file.path pattern. Avoid exceptions on process.name, file.extension, or the whole critical-process list alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the servicing or vendor-maintenance evidence: writer identity, parent context, written path, content indicators, and host scope. Create an exception only after the bounded pattern recurs.
  • If suspicious but unconfirmed, export the alert file event and matching process-start event, preserve a copy of the written file when safe, and record the writer process.entity_id, process.command_line, process.parent.executable, file.path, and recovered process.hash.sha256 before containment. Apply reversible containment first, such as heightened monitoring or temporary host isolation when host criticality allows, and avoid deleting the artifact until scope is clearer.
  • If confirmed malicious, isolate the host when writer identity, lineage, artifact, or execution evidence establishes unauthorized activity. Record process.entity_id, process.executable, process.command_line, file.path, and recovered hashes before killing processes or deleting files; then terminate the offending process if still active and quarantine only the executable or DLL artifacts identified during investigation.
  • Post-incident hardening should verify why a critical process could write executable content, restore affected files from trusted media when replacement occurred, retain process and file telemetry that supported the case, and document artifact-path or lineage variants in the incident record for future triage.

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
file where host.os.type == "windows" and event.type != "deletion" and
  file.extension : ("exe", "dll") and
  process.name : ("smss.exe",
                  "autochk.exe",
                  "csrss.exe",
                  "wininit.exe",
                  "services.exe",
                  "lsass.exe",
                  "winlogon.exe",
                  "userinit.exe",
                  "LogonUI.exe") and
  not (
    process.name : "smss.exe" and
    file.path : (
      "?:\\Windows\\System32\\wpbbin.exe",
      "\\Device\\HarddiskVolume*\\Windows\\System32\\wpbbin.exe"
    )
  ) and
  not (
    process.name : "lsass.exe" and
    file.path : (
      "?:\\Windows\\System32\\eac_usermode_*.dll",
      "\\Device\\HarddiskVolume*\\Windows\\System32\\eac_usermode_*.dll"
    )
  )

Framework: MITRE ATT&CKTM