« Potential PowerShell Obfuscation via Special Character Overuse Suspicious Execution from a Mounted Device »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.16

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 combines Win32 APIs for allocation/protection or process access (for example, VirtualAlloc/VirtualProtect/OpenProcess/AdjustTokenPrivileges/LoadLibrary/GetProcAddress) with injection or execution APIs (WriteProcessMemory/CreateRemoteThread/NtCreateThreadEx/QueueUserAPC/ResumeThread). Attackers use these API chains to inject code into remote processes and execute payloads in memory for defense evasion.

Rule type: query

Rule indices:

  • winlogbeat-*
  • logs-windows.powershell*

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: 217

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Disclaimer: This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.

Investigating Potential Process Injection via PowerShell

This rule Detects PowerShell scripts that references a combination of Win32 APIs commonly used to open a target process, allocate or change memory protections, write data into another process, and execute it via a remote thread or APC. This behavior is frequently associated with process injection and in-memory payload execution on Windows hosts.

Key alert fields to review

  • user.name, user.domain, user.id: Account execution context for correlation, prioritization, and scoping.
  • host.name, host.id: Host execution context for correlation, prioritization, and scoping.
  • powershell.file.script_block_text: Script block content that matched the detection logic.
  • powershell.file.script_block_id, powershell.sequence, powershell.total: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
  • file.path, file.directory, file.name: File-origin context when the script block is sourced from an on-disk file.
  • powershell.file.script_block_length: Script block length (size) context.

Possible investigation steps

  • Review and preserve the script content:
  • Inspect powershell.file.script_block_text for the full API chain and surrounding logic (function definitions, payload construction, and execution flow).
  • If the content is split across multiple events, reconstruct it by grouping on powershell.file.script_block_id, ordering by powershell.sequence, and validating completeness with powershell.total. Preserve the reconstructed content for follow-up analysis.
  • Use powershell.file.script_block_length to help gauge whether the script is a small launcher or a larger framework with embedded payloads.
  • Identify the injection technique and likely target:
  • Determine which execution primitive is being used (for example, CreateRemoteThread, NtCreateThreadEx, QueueUserAPC, or thread SuspendThread/ResumeThread patterns) and whether it suggests immediate or deferred execution.
  • Look for how the target process is selected (process name strings, PID variables, or process enumeration logic) and capture any referenced process names or IDs for scoping.
  • Note any privilege manipulation via OpenProcessToken and AdjustTokenPrivileges, which can indicate attempts to access protected processes.
  • Assess how native APIs are being invoked:
  • Identify dynamic resolution patterns such as LoadLibrary*/LdrLoadDll with GetProcAddress, which are commonly used to avoid static imports and hinder analysis.
  • If GetDelegateForFunctionPointer is present, review the surrounding text for delegate definitions and indirect invocation logic.
  • Validate execution context and script provenance:
  • Review user.name, user.domain, and user.id for signs of unusual execution (unexpected account type, first-time observation on the host, or activity outside expected administrative workflows).
  • Review host.name and host.id to understand the asset impacted and whether the behavior aligns with the host’s role in your environment.
  • If file.path, file.directory, or file.name are populated, assess whether the script originated from a controlled location and naming convention, or from a user-writable or temporary location.
  • Scope related PowerShell activity:
  • On the same host.id and user.id, review additional script block events near @timestamp to identify staging actions that commonly bracket injection attempts (download, decode/decrypt, reflective loading, or cleanup).
  • Search for repeated use of distinctive substrings from powershell.file.script_block_text across other hosts or users to determine prevalence and potential reuse.
  • Correlate with adjacent host telemetry (if available in your environment):
  • Pivot from host.name and @timestamp to process activity to identify the PowerShell host process, its parent process, and any processes that may have been targeted for injection.
  • Review network activity from the same host.name around the alert time for potential payload retrieval, command-and-control, or lateral movement.
  • Review file activity related to file.path (when present) and for any new or modified scripts or binaries referenced by the script block.
  • Make a disposition:
  • Treat as higher risk when the script combines process access (OpenProcess), memory modification (VirtualAlloc*/VirtualProtect), and execution (CreateRemoteThread/NtCreateThreadEx/QueueUserAPC), especially when coupled with privilege adjustment or dynamic API resolution.
  • Treat as lower risk only when there is a clear, documented administrative or testing justification tied to the same user.id, host.id, and script origin.

False positive analysis

  • Legitimate PowerShell can use Win32 API interop for diagnostics, automation, or compatibility work; however, the combination of remote memory operations and remote execution APIs is uncommon in routine administration.
  • Developer tooling or monitoring frameworks may load libraries or resolve symbols dynamically; validate that the script content aligns with expected tool behavior and that the script origin (file.path/file.name) is consistent and controlled.

Response and remediation

  • If the activity is confirmed or strongly suspected malicious:
  • Contain the affected host to prevent follow-on actions and lateral movement.
  • Preserve evidence by retaining the reconstructed powershell.file.script_block_text (and associated powershell.file.script_block_id) and recording the alert context (user.*, host.*, and file.* where present).
  • Identify the intended injection target from the script content and investigate that process and its recent activity for signs of compromise or anomalous behavior.
  • Review the associated user account activity for additional suspicious behavior on the same host and other hosts, and take appropriate account actions if compromise is suspected.
  • Hunt for the same script patterns across the environment using stable substrings from powershell.file.script_block_text and common file.path/file.name values, and remediate any additional impacted systems.
  • If the activity is verified as benign:
  • Document the script purpose, owner, expected execution context (hosts and accounts), and expected script origin (file.path/file.name).
  • Consider controlled rule tuning using stable, high-confidence identifiers from the verified benign workflow to reduce repeat alerts while maintaining coverage for new or unauthorized variants.

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 Suspicious Execution from a Mounted Device »