Potential Malicious PowerShell Based on Alert Correlation

  1[metadata]
  2creation_date = "2025/04/16"
  3maturity = "production"
  4updated_date = "2026/02/09"
  5
  6[rule]
  7author = ["Elastic"]
  8description = """
  9Identifies PowerShell script blocks linked to multiple distinct PowerShell detections via the same ScriptBlock ID,
 10indicating compound suspicious behavior. Attackers often chain obfuscation, decoding, and execution within a single
 11script block.
 12"""
 13from = "now-9m"
 14language = "esql"
 15license = "Elastic License v2"
 16name = "Potential Malicious PowerShell Based on Alert Correlation"
 17note = """## Triage and analysis
 18
 19> **Disclaimer**:
 20> 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.
 21
 22### Investigating Potential Malicious PowerShell Based on Alert Correlation
 23
 24This alert groups multiple PowerShell-related detections that reference the same ScriptBlock identifier. When several independent detections fire on a single script block, it often indicates a single execution chain combining multiple suspicious behaviors. Treat the contributing alerts as the primary evidence and use this correlation to prioritize investigation and scoping.
 25
 26Investigation goals:
 27- Identify affected endpoints and users by pivoting to the contributing alerts.
 28- Recover the complete script content associated with the ScriptBlock identifier and understand its intent.
 29- Identify follow-on behavior (process, network, persistence) and scope the activity across the environment.
 30
 31#### Key alert fields to review
 32
 33- `Esql.script_block_id`: The ScriptBlock identifier used to correlate multiple alerts.
 34- `Esql.kibana_alert_rule_name_count_distinct`: The number of distinct PowerShell-related rule names that contributed to the correlation.
 35- `Esql.kibana_alert_rule_name_values`: The contributing rule names; use this list to quickly understand what detection logic was triggered.
 36- `Esql._id_values`: The contributing alert document IDs; pivot to these source alerts for full context and supporting evidence.
 37
 38#### Possible investigation steps
 39
 40- Understand what drove the correlation:
 41  - Review `Esql.kibana_alert_rule_name_count_distinct` to gauge overall confidence and urgency.
 42  - Review `Esql.kibana_alert_rule_name_values` and group the contributing detections by behavior (for example, obfuscation/encoding, suspicious execution, network retrieval, or persistence-related activity). Use this grouping to decide what evidence is most important to validate first.
 43
 44- Pivot to the contributing alerts and capture execution context:
 45  - Use `Esql._id_values` to open each contributing alert and collect the affected host and user context, along with the earliest and latest timestamps across the set.
 46  - Confirm the contributing alerts represent the same ScriptBlock ID and are not unrelated alerts that happen to share similar message content.
 47  - Identify whether the activity is limited to a single endpoint or appears on multiple endpoints. Multiple endpoints can indicate script reuse, distribution, or remote execution.
 48
 49- Reconstruct the full script block content:
 50  - Using `Esql.script_block_id`, locate all available records (alerts and/or underlying telemetry referenced by the contributing alerts) tied to the same identifier.
 51  - If the script content is split across multiple fragments, reconstruct it in the correct order before assessing intent.
 52  - Identify any decoded/deobfuscated output that the script generates during execution and capture it as evidence for scoping.
 53
 54- Assess intent and capability based on the recovered script:
 55  - Look for evidence of staged execution, such as multiple layers of decoding, dynamic code generation, or invocation of additional code.
 56  - Identify indicators that can be used for scoping (for example, external destinations, file locations, created services, or suspicious child process activity referenced by the contributing alerts).
 57
 58- Correlate with adjacent activity during the same timeframe:
 59  - Process activity: check for unusual parent-child relationships involving PowerShell and unexpected child processes following the script block execution.
 60  - Network activity: review outbound connections and DNS activity that align with the execution window, especially first-time or rare destinations.
 61  - File and registry activity: look for payload staging, configuration changes, or persistence artifacts created near the execution window.
 62  - Authentication activity: review for suspicious logons or account changes that coincide with the script execution, especially if activity spans multiple endpoints.
 63
 64- Scope and hunt for additional occurrences:
 65  - Search for other alerts containing the same `Esql.script_block_id` to determine if the script was reused or executed repeatedly.
 66  - Use indicators and behaviors observed in the contributing alerts to identify related activity in other alerts and telemetry sources, and establish first-seen/last-seen boundaries.
 67
 68### False positive analysis
 69
 70- Legitimate administrative automation can produce multiple detections if it uses dynamic script generation, embedded encoded content, or downloads content at runtime. Validate whether the affected hosts, users, and timing align with an approved maintenance activity.
 71- If the same ScriptBlock content repeatedly maps to a known benign workflow, document the expected behavior and tune upstream detections to better distinguish that workflow, rather than suppressing this correlation rule.
 72
 73### Response and remediation
 74
 75- If the activity is confirmed or strongly suspected to be malicious:
 76  - Contain impacted endpoints to prevent additional execution and follow-on actions.
 77  - Restrict, reset, or rotate credentials for involved accounts as appropriate, especially for privileged or shared accounts.
 78  - Remove identified artifacts and persistence mechanisms (for example, suspicious services or dropped binaries) and remediate any affected systems.
 79  - Block or monitor indicators identified from the contributing alerts (external destinations, file locations, or other observable artifacts) to prevent reinfection and support hunting.
 80
 81- Validation and recovery:
 82  - Use `Esql.script_block_id` and the contributing alert set in `Esql._id_values` to verify that the activity has ceased and to identify any additional impacted endpoints.
 83  - Continue monitoring for recurrence of the same ScriptBlock ID or the contributing behaviors to confirm remediation effectiveness.
 84
 85- Post-incident:
 86  - Preserve the recovered script content and the full set of contributing alerts as evidence.
 87  - Identify and address the initial execution mechanism indicated by the contributing alerts and improve preventative controls and logging coverage to reduce recurrence.
 88"""
 89risk_score = 73
 90rule_id = "f770ce79-05fd-4d74-9866-1c5d66c9b34b"
 91severity = "high"
 92tags = [
 93    "Domain: Endpoint",
 94    "OS: Windows",
 95    "Use Case: Threat Detection",
 96    "Tactic: Execution",
 97    "Rule Type: Higher-Order Rule",
 98    "Resources: Investigation Guide",
 99]
100timestamp_override = "event.ingested"
101type = "esql"
102
103query = '''
104from .alerts-security.* metadata _id
105
106// Filter for PowerShell related alerts
107| where kibana.alert.rule.name like "*PowerShell*"
108
109// as alerts don't have non-ECS fields, parse the script block ID using grok
110| grok message "ScriptBlock ID: (?<Esql.script_block_id>.+)"
111| where Esql.script_block_id is not null
112
113// keep relevant fields for further processing
114| keep kibana.alert.rule.name, Esql.script_block_id, _id
115
116// count distinct alerts and filter for matches above the threshold
117| stats
118    Esql.kibana_alert_rule_name_count_distinct = count_distinct(kibana.alert.rule.name),
119    Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),
120    Esql._id_values = values(_id)
121  by Esql.script_block_id
122
123// Apply detection threshold
124| where Esql.kibana_alert_rule_name_count_distinct >= 5
125'''
126
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130[[rule.threat.technique]]
131id = "T1059"
132name = "Command and Scripting Interpreter"
133reference = "https://attack.mitre.org/techniques/T1059/"
134[[rule.threat.technique.subtechnique]]
135id = "T1059.001"
136name = "PowerShell"
137reference = "https://attack.mitre.org/techniques/T1059/001/"
138
139
140
141[rule.threat.tactic]
142id = "TA0002"
143name = "Execution"
144reference = "https://attack.mitre.org/tactics/TA0002/"
145
146[rule.investigation_fields]
147field_names = [
148    "Esql.script_block_id",
149    "Esql._id_values",
150    "Esql.kibana_alert_rule_name_values",
151    "Esql.kibana_alert_rule_name_count_distinct"
152]