« Potential PowerShell Obfuscation via Special Character Overuse Windows Firewall Disabled via PowerShell »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential Process Injection via PowerShell

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

Potential Process Injection via PowerShell

edit

Detects PowerShell scripts that combine Win32 APIs for allocation, protection, process access, or dynamic resolution with injection or execution APIs. Attackers use these API chains for potential process injection or in-memory payload execution.

Rule type: query

Rule indices:

  • logs-windows.powershell*
  • 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: Defense Evasion
  • Tactic: Execution
  • Resources: Investigation Guide
  • Data Source: PowerShell Logs

Version: 219

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Process Injection via PowerShell

Possible investigation steps

  • Does the reconstructed script show an executable injection path or only isolated helper code?
  • Focus: reconstruct with powershell.file.script_block_id, powershell.sequence, and powershell.total, then review powershell.file.script_block_text and powershell.file.script_block_length. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the ordered script combines target access, memory allocation/protection, remote write, and thread/APC execution; lower concern when reconstruction proves only comments, imports, or unused helper functions in a bounded test script.
  • If endpoint process telemetry is available for this host, can you recover how PowerShell was launched?
  • Focus: same-host process starts for the PowerShell instance: process.command_line, process.parent.executable, process.parent.command_line, and process.entity_id. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","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"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: recover the matching process via host.id + process.pid before interpreting process.* or process.parent.*; if absent, expand the same-host window. Missing endpoint process telemetry is unresolved, not benign.
  • Implication: escalate when the launcher is a document, browser, remote-management tool, scheduled task, encoded command, or user-writable path that does not fit the user; lower concern when launch chain and script origin match the same recognized lab or validation workflow.
  • What payload style does the reconstructed script stage?
  • Why: Empire-style loaders commonly patch or reflectively load PE bytes before injection, so payload form changes what to preserve and how urgently to respond.
  • Focus: powershell.file.script_block_text for byte arrays, Base64 PE blobs, reflective loader names, Mimikatz or credential-dumping commands, and PE/DLL paths or URLs. If endpoint telemetry is available, recover same-PID file and network/DNS events surrounding @timestamp to validate writes, staging, or retrieval. Missing file or network/DNS telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for the PowerShell PID","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":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the script embeds or fetches shellcode/PE content, calls reflective loading, or references credential dumping; lower concern only when payload handling is absent and the code remains a controlled harness with no execution path.
  • Which target and access path does the script choose?
  • Focus: powershell.file.script_block_text for process-name or PID selectors, credential-rich or security-sensitive targets, token changes, broad access masks, and thread/APC primitives.
  • Implication: escalate when the script targets credential-rich, security-sensitive, user-facing, or many candidate processes and requests broad rights or debug privilege; lower concern when the target is one controlled lab process and the access path matches the recognized exercise.
  • Does the user, host, and script origin fit one controlled workflow?
  • Focus: user.id, user.domain, host.id, host.name, and file.path when present, interpreted with the reconstructed script and recovered launch chain.
  • Implication: escalate when the script is fileless or sourced from temp, profile, share, or staging paths under an unexpected account or host; lower concern only when user, host cohort, source path or fileless launcher pattern, target process, and payload choice all align with one controlled test or diagnostic workflow.
  • If local evidence remains suspicious or unresolved, does the same injection pattern appear elsewhere?
  • Focus: smallest stable suspicious pattern from powershell.file.script_block_text, such as loader function, target process, Mimikatz command, or distinctive payload string, plus user.id for actor scope. !{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"}}
  • Hint: run the host.id asset-scope check only after script logic, target/access path, and launch context remain suspicious or incomplete. !{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 when the same injection pattern or target selection appears on unrelated hosts or users; keep scope local when it stays confined to one recognized testing cohort or one unresolved host.
  • What disposition is supported?
  • Escalate on script logic plus payload, sensitive target, broad access, suspicious launcher, or spread; close only when telemetry proves one controlled workflow with no contradictory payload or target abuse; preserve artifacts and escalate when evidence is mixed or endpoint process recovery is unavailable.

False positive analysis

  • Authorized red-team, malware-analysis, or detection-validation exercises can trigger this rule when the reconstructed script injects only into controlled targets on lab or canary hosts. Require powershell.file.script_block_text, target process names, file.path when present, user.id, and host.id to align with the exercise. If endpoint process telemetry is available, recover via host.id + process.pid and require process.command_line plus process.parent.executable to align. Use calendars or change records only to document telemetry-aligned activity; do not close when script, target, or launcher evidence conflicts.
  • Security-product validation or compatibility harnesses are rare; do not close unless the script stays limited to the product’s expected target set and lacks embedded payloads, Mimikatz commands, privilege escalation, or broad target loops. If endpoint process telemetry is available, recover via host.id + process.pid and require process.parent.executable plus process.command_line to match the same controlled path or harness. Build exceptions only from the minimum confirmed pattern: stable script origin or distinctive harness substring, bounded target set, host.id or user.id, and recovered launcher when available; never exempt generic API names alone.

Response and remediation

  • If confirmed benign:
  • Document the reconstructed script, target process set, script origin, user.id, host.id, and the exercise or harness evidence that established the workflow before reversing temporary containment. If endpoint process telemetry was available and recovered via host.id + process.pid, include the recovered process.command_line and process.parent.executable. Build exceptions only from the minimum confirmed workflow pattern, not from generic API names.
  • If suspicious but unconfirmed:
  • Preserve the reconstructed powershell.file.script_block_text, every fragment tied to powershell.file.script_block_id, target process names or PIDs, payload strings, file.path when present, alert process.pid, user.id, and host.id before cleanup. If endpoint process telemetry was available and recovered via host.id + process.pid, also preserve process.entity_id, process.command_line, and process.parent.command_line.
  • Apply reversible containment such as temporary network restrictions, heightened monitoring, or access limits on the affected host.id and user.id; escalate to host isolation only when host criticality permits or payload execution, sensitive target selection, or spread evidence raises confidence.
  • If confirmed malicious:
  • Record the preserved evidence set and recovered process identifiers first when endpoint process telemetry was available. Then isolate the host when script logic, target selection, payload style, recovered launcher, or related-alert scope confirms malicious injection; if direct endpoint response is unavailable, hand off that evidence set to the team that can contain the host.
  • Block confirmed malicious payload file paths and infrastructure indicators found during investigation, then review related hosts and users for the same loader, payload, target process, or recovered launcher pattern before eradication. Do not block on generic API names.
  • Remove the malicious script, payload files, scheduled tasks, startup paths, or delivery artifacts identified during the investigation. Reset or investigate affected accounts when the payload, target process, or Mimikatz command indicates credential access, then remediate the path that launched PowerShell.
  • Post-incident hardening:
  • Keep Script Block logging and the endpoint process telemetry needed for host.id + process.pid recovery enabled on the affected host class.
  • Restrict PowerShell execution, Constrained Language Mode, or code-signing policy where appropriate for the host role, and record any telemetry gaps that limited reconstruction or process recovery.

Setup

edit

Setup

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). Setup instructions: https://ela.st/powershell-logging-setup

Rule query

edit
event.category:process and host.os.type:windows and
  powershell.file.script_block_text : (
   (VirtualAlloc or VirtualAllocEx or VirtualProtect or LdrLoadDll or LoadLibrary or LoadLibraryA or
      LoadLibraryEx or GetProcAddress or OpenProcess or OpenProcessToken or AdjustTokenPrivileges) and
   (WriteProcessMemory or CreateRemoteThread or NtCreateThreadEx or CreateThread or QueueUserAPC or
      SuspendThread or ResumeThread or GetDelegateForFunctionPointer)
  ) and not
  file.directory: (
    "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\SenseCM" or
    "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
  )

Framework: MITRE ATT&CKTM

« Potential PowerShell Obfuscation via Special Character Overuse Windows Firewall Disabled via PowerShell »