Suspicious Portable Executable Encoded in Powershell Script
Detects PowerShell scripts that includes a base64-encoded portable executable (PE) header, indicating an embedded binary payload. Attackers embed PEs in scripts to load payloads in memory and avoid writing executables to disk.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/10/15"
3integration = ["windows"]
4maturity = "production"
5updated_date = "2026/02/09"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects PowerShell scripts that includes a base64-encoded portable executable (PE) header, indicating an embedded
11binary payload. Attackers embed PEs in scripts to load payloads in memory and avoid writing executables to disk.
12"""
13from = "now-9m"
14index = ["winlogbeat-*", "logs-windows.powershell*"]
15language = "kuery"
16license = "Elastic License v2"
17name = "Suspicious Portable Executable Encoded in Powershell Script"
18note = """## Triage and analysis
19
20> **Disclaimer**:
21> 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.
22
23### Investigating Suspicious Portable Executable Encoded in Powershell Script
24
25This alert indicates PowerShell Script Block Logging captured script content that contains a base64-encoded Portable Executable (PE) header pattern, suggesting an embedded Windows binary payload. This technique is commonly used to stage executables for in-memory loading or later execution while minimizing on-disk artifacts.
26
27#### Key alert fields to review
28
29- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
30- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
31- `powershell.file.script_block_text`: Script block content that matched the detection logic.
32- `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.
33- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
34- `powershell.file.script_block_length`: Script block length (size) context.
35
36#### Possible investigation steps
37
38- Capture and reconstruct the full script content:
39 - Review `powershell.file.script_block_text` in full to identify the encoded blob boundaries and any surrounding helper logic (string concatenation, chunking, decryption, decompression, or obfuscation).
40 - If `powershell.file.script_block_id` is present, collect all related events for that ID and use `powershell.sequence` and `powershell.total` to reconstruct the complete script when content is split across multiple records.
41 - Confirm reconstruction completeness by ensuring the sequence range is consistent with `powershell.total` and that the combined content is coherent.
42 - Use `powershell.file.script_block_length` to help prioritize unusually large script blocks that are more likely to contain full payloads or staged components.
43- Determine the script origin and execution context:
44 - Use `user.name`, `user.domain`, and `user.id` to identify the initiating account and whether this activity is expected for that user (approved automation vs. unusual interactive activity).
45 - Use `host.name` and `host.id` to identify the affected asset, its owner/role, and whether PowerShell automation is typical for this host.
46 - If `file.path`, `file.directory`, or `file.name` are present, treat the alert as file-sourced script execution:
47 - Validate whether the path and name align with approved administrative tooling and distribution locations.
48 - Prioritize investigation when scripts are sourced from user-writable locations, temporary directories, or uncommon paths for your environment.
49- Identify likely payload handling behavior within the script:
50 - Look for logic that transforms the encoded content into executable bytes and how it is consumed (written to disk, loaded as an assembly, reflectively invoked, or mapped into memory).
51 - Note any secondary behaviors in the same script block that increase risk, such as staged downloads, persistence-related actions, or attempts to reduce visibility.
52 - Identify whether the script constructs multiple encoded blobs, and document which blob is ultimately used for execution.
53- Scope the activity using alert pivots:
54 - Search for additional script block events for the same `host.id` and `user.id` around `@timestamp` to identify lead-up actions and follow-on behavior.
55 - Search across hosts for the same `powershell.file.script_block_text` patterns (the encoded header and any unique strings nearby) to identify other potentially affected systems.
56 - If a script file is indicated by `file.path`/`file.name`, search for the same path/name across your environment to determine distribution and reuse.
57- Correlate with adjacent telemetry (if available):
58 - Pivot on `host.id`/`host.name` and `@timestamp` into process telemetry to identify the PowerShell session and any processes that appear shortly after the script ran, which may indicate payload execution outcomes.
59 - Pivot on `host.id`/`host.name` and `@timestamp` into network telemetry to identify outbound connections that could indicate payload retrieval or command-and-control activity shortly before or after script execution.
60 - Review authentication activity for the same `user.id` around the alert time to identify unusual logons (unexpected host, timing, or access pattern) that could explain how the execution context was obtained.
61- Analyze the embedded payload in an isolated workflow (when permitted):
62 - Decode the base64 content and validate whether it forms a legitimate PE.
63 - Derive stable indicators (hashes, unique strings, and high-level metadata) and use them to widen the scope across endpoints and historical telemetry.
64 - Preserve decoded artifacts and analysis notes according to your incident handling and evidence retention procedures.
65
66### False positive analysis
67
68- Approved administrative or deployment automation that embeds executables in PowerShell scripts for distribution in tightly controlled environments.
69- Vendor-provided installers, updaters, or management tooling that stages binaries through PowerShell as part of legitimate maintenance activity.
70- Authorized security testing or adversary emulation that intentionally uses embedded payloads or in-memory loading techniques.
71- False positives are more likely when `file.path` points to known software distribution locations and the executing `user.id` is an approved automation account; validate against change records and expected tooling.
72
73### Response and remediation
74
75- If the activity is unexpected or malicious:
76 - Contain the affected host(s) based on criticality to prevent further execution or lateral movement.
77 - Preserve evidence by saving the full reconstructed script content (using `powershell.file.script_block_id` plus all fragments, if split) and recording the associated `@timestamp`, `host.id`, `host.name`, and `user.id` for timeline reconstruction.
78- Assess scope and impact:
79 - Hunt for the same script patterns across other hosts and users, and expand scoping using any indicators derived from payload analysis.
80 - Review the initiating account for signs of compromise; apply credential hygiene actions per policy (reset credentials, revoke sessions, and review access).
81- Eradicate and recover:
82 - Remove or remediate the script source indicated by `file.path` (if present) and any persistence mechanisms identified during triage (for example, suspicious or newly introduced services).
83 - If a PE payload is confirmed, follow malware incident procedures to determine whether host reimaging or deeper forensic review is required.
84- Post-incident improvements:
85 - Review PowerShell governance for the affected population (script approval processes, least privilege, and monitoring of script block content) to reduce recurrence.
86 - Document validated benign patterns and trusted automation paths to streamline future triage and reduce alert fatigue.
87"""
88references = [
89 "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md",
90]
91risk_score = 47
92rule_id = "ad84d445-b1ce-4377-82d9-7c633f28bf9a"
93setup = """## Setup
94
95PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
96Setup instructions: https://ela.st/powershell-logging-setup
97"""
98severity = "medium"
99tags = [
100 "Domain: Endpoint",
101 "OS: Windows",
102 "Use Case: Threat Detection",
103 "Tactic: Execution",
104 "Tactic: Defense Evasion",
105 "Resources: Investigation Guide",
106 "Data Source: PowerShell Logs",
107]
108timestamp_override = "event.ingested"
109type = "query"
110
111query = '''
112event.category:process and host.os.type:windows and
113 powershell.file.script_block_text : (
114 TVqQAAMAAAAEAAAA
115 ) and not user.id : "S-1-5-18"
116'''
117
118
119[[rule.threat]]
120framework = "MITRE ATT&CK"
121[[rule.threat.technique]]
122id = "T1059"
123name = "Command and Scripting Interpreter"
124reference = "https://attack.mitre.org/techniques/T1059/"
125[[rule.threat.technique.subtechnique]]
126id = "T1059.001"
127name = "PowerShell"
128reference = "https://attack.mitre.org/techniques/T1059/001/"
129
130
131
132[rule.threat.tactic]
133id = "TA0002"
134name = "Execution"
135reference = "https://attack.mitre.org/tactics/TA0002/"
136[[rule.threat]]
137framework = "MITRE ATT&CK"
138[[rule.threat.technique]]
139id = "T1055"
140name = "Process Injection"
141reference = "https://attack.mitre.org/techniques/T1055/"
142
143
144[rule.threat.tactic]
145id = "TA0005"
146name = "Defense Evasion"
147reference = "https://attack.mitre.org/tactics/TA0005/"
148
149[rule.investigation_fields]
150field_names = [
151 "@timestamp",
152 "user.name",
153 "user.id",
154 "user.domain",
155 "powershell.file.script_block_text",
156 "powershell.file.script_block_id",
157 "powershell.sequence",
158 "powershell.total",
159 "file.path",
160 "file.directory",
161 "file.name",
162 "process.pid",
163 "host.name",
164 "host.id",
165 "powershell.file.script_block_length"
166]
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 Suspicious Portable Executable Encoded in Powershell Script
This alert indicates PowerShell Script Block Logging captured script content that contains a base64-encoded Portable Executable (PE) header pattern, suggesting an embedded Windows binary payload. This technique is commonly used to stage executables for in-memory loading or later execution while minimizing on-disk artifacts.
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
- Capture and reconstruct the full script content:
- Review
powershell.file.script_block_textin full to identify the encoded blob boundaries and any surrounding helper logic (string concatenation, chunking, decryption, decompression, or obfuscation). - If
powershell.file.script_block_idis present, collect all related events for that ID and usepowershell.sequenceandpowershell.totalto reconstruct the complete script when content is split across multiple records. - Confirm reconstruction completeness by ensuring the sequence range is consistent with
powershell.totaland that the combined content is coherent. - Use
powershell.file.script_block_lengthto help prioritize unusually large script blocks that are more likely to contain full payloads or staged components.
- Review
- Determine the script origin and execution context:
- Use
user.name,user.domain, anduser.idto identify the initiating account and whether this activity is expected for that user (approved automation vs. unusual interactive activity). - Use
host.nameandhost.idto identify the affected asset, its owner/role, and whether PowerShell automation is typical for this host. - If
file.path,file.directory, orfile.nameare present, treat the alert as file-sourced script execution:- Validate whether the path and name align with approved administrative tooling and distribution locations.
- Prioritize investigation when scripts are sourced from user-writable locations, temporary directories, or uncommon paths for your environment.
- Use
- Identify likely payload handling behavior within the script:
- Look for logic that transforms the encoded content into executable bytes and how it is consumed (written to disk, loaded as an assembly, reflectively invoked, or mapped into memory).
- Note any secondary behaviors in the same script block that increase risk, such as staged downloads, persistence-related actions, or attempts to reduce visibility.
- Identify whether the script constructs multiple encoded blobs, and document which blob is ultimately used for execution.
- Scope the activity using alert pivots:
- Search for additional script block events for the same
host.idanduser.idaround@timestampto identify lead-up actions and follow-on behavior. - Search across hosts for the same
powershell.file.script_block_textpatterns (the encoded header and any unique strings nearby) to identify other potentially affected systems. - If a script file is indicated by
file.path/file.name, search for the same path/name across your environment to determine distribution and reuse.
- Search for additional script block events for the same
- Correlate with adjacent telemetry (if available):
- Pivot on
host.id/host.nameand@timestampinto process telemetry to identify the PowerShell session and any processes that appear shortly after the script ran, which may indicate payload execution outcomes. - Pivot on
host.id/host.nameand@timestampinto network telemetry to identify outbound connections that could indicate payload retrieval or command-and-control activity shortly before or after script execution. - Review authentication activity for the same
user.idaround the alert time to identify unusual logons (unexpected host, timing, or access pattern) that could explain how the execution context was obtained.
- Pivot on
- Analyze the embedded payload in an isolated workflow (when permitted):
- Decode the base64 content and validate whether it forms a legitimate PE.
- Derive stable indicators (hashes, unique strings, and high-level metadata) and use them to widen the scope across endpoints and historical telemetry.
- Preserve decoded artifacts and analysis notes according to your incident handling and evidence retention procedures.
False positive analysis
- Approved administrative or deployment automation that embeds executables in PowerShell scripts for distribution in tightly controlled environments.
- Vendor-provided installers, updaters, or management tooling that stages binaries through PowerShell as part of legitimate maintenance activity.
- Authorized security testing or adversary emulation that intentionally uses embedded payloads or in-memory loading techniques.
- False positives are more likely when
file.pathpoints to known software distribution locations and the executinguser.idis an approved automation account; validate against change records and expected tooling.
Response and remediation
- If the activity is unexpected or malicious:
- Contain the affected host(s) based on criticality to prevent further execution or lateral movement.
- Preserve evidence by saving the full reconstructed script content (using
powershell.file.script_block_idplus all fragments, if split) and recording the associated@timestamp,host.id,host.name, anduser.idfor timeline reconstruction.
- Assess scope and impact:
- Hunt for the same script patterns across other hosts and users, and expand scoping using any indicators derived from payload analysis.
- Review the initiating account for signs of compromise; apply credential hygiene actions per policy (reset credentials, revoke sessions, and review access).
- Eradicate and recover:
- Remove or remediate the script source indicated by
file.path(if present) and any persistence mechanisms identified during triage (for example, suspicious or newly introduced services). - If a PE payload is confirmed, follow malware incident procedures to determine whether host reimaging or deeper forensic review is required.
- Remove or remediate the script source indicated by
- Post-incident improvements:
- Review PowerShell governance for the affected population (script approval processes, least privilege, and monitoring of script block content) to reduce recurrence.
- Document validated benign patterns and trusted automation paths to streamline future triage and reduce alert fatigue.
References
Related rules
- Potential Process Injection via PowerShell
- Suspicious .NET Reflection via PowerShell
- Potential PowerShell HackTool Script by Function Names
- PowerShell PSReflect Script
- Potential PowerShell HackTool Script by Author