Potential PowerShell Obfuscation via String Reordering
Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/04/03"
3integration = ["windows"]
4maturity = "production"
5updated_date = "2025/08/14"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation.
11These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan
12Interface (AMSI).
13"""
14from = "now-9m"
15language = "esql"
16license = "Elastic License v2"
17name = "Potential PowerShell Obfuscation via String Reordering"
18note = """ ## Triage and analysis
19
20> **Disclaimer**:
21> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
22
23### Investigating Potential PowerShell Obfuscation via String Reordering
24
25PowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like string reordering to evade detection. This involves rearranging strings and reconstructing them at runtime, bypassing static analysis and security measures. The detection rule identifies scripts with excessive length and specific patterns, flagging those with multiple occurrences of string format expressions, which are indicative of obfuscation attempts. By filtering out known benign patterns, it reduces false positives, focusing on genuine threats.
26
27### Possible investigation steps
28
29- Review the script block text by examining the powershell.file.script_block_text field to understand the nature of the obfuscation and identify any potentially malicious commands or patterns.
30- Check the file.path and file.name fields to determine the origin and context of the script, which can provide insights into whether the script is part of a legitimate application or a potential threat.
31- Investigate the host.name and user.id fields to identify the affected system and user, which can help in assessing the potential impact and scope of the incident.
32- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and history of the script, which may reveal additional suspicious activities or related scripts.
33- Correlate the alert with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.
34
35### False positive analysis
36
37- Scripts related to the Icinga Framework may trigger false positives due to their use of string formatting. To handle this, ensure that the file name "framework_cache.psm1" is excluded from the detection rule.
38- PowerShell scripts that include specific sentinel patterns, such as "sentinelbreakpoints" or paths like ":::::\\windows\\sentinel", combined with variables like "$local:Bypassed" or "origPSExecutionPolicyPreference", are known to be benign. These should be excluded to reduce noise.
39- Regularly review and update the exclusion list to include any new benign patterns that are identified over time, ensuring the rule remains effective without generating unnecessary alerts.
40- Consider implementing a whitelist of known safe scripts or script authors to further minimize false positives, especially in environments with frequent legitimate use of complex PowerShell scripts.
41
42### Response and remediation
43
44- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
45- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.
46- Conduct a thorough review of the PowerShell script block text flagged by the alert to understand the intent and potential impact of the obfuscated script.
47- Remove any malicious scripts or files identified during the investigation from the affected system to prevent re-execution.
48- Restore the system from a known good backup if the script has caused significant changes or damage to the system.
49- Update and strengthen endpoint protection measures, ensuring that AMSI and other security tools are fully operational and configured to detect similar obfuscation techniques.
50- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
51"""
52risk_score = 21
53rule_id = "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5"
54setup = """## Setup
55
56The 'PowerShell Script Block Logging' logging policy must be enabled.
57Steps to implement the logging policy with Advanced Audit Configuration:
Computer Configuration > Administrative Templates > Windows PowerShell > Turn on PowerShell Script Block Logging (Enable)
1
2Steps to implement the logging policy via registry:
reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
1"""
2severity = "low"
3tags = [
4 "Domain: Endpoint",
5 "OS: Windows",
6 "Use Case: Threat Detection",
7 "Tactic: Defense Evasion",
8 "Data Source: PowerShell Logs",
9 "Resources: Investigation Guide",
10]
11timestamp_override = "event.ingested"
12type = "esql"
13
14query = '''
15from logs-windows.powershell_operational* metadata _id, _version, _index
16| where event.code == "4104" and powershell.file.script_block_text like "*{0}*"
17
18// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
19| eval Esql.script_block_length = length(powershell.file.script_block_text)
20| where Esql.script_block_length > 500
21
22// replace the patterns we are looking for with the 🔥 emoji to enable counting them
23// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
24| eval Esql.script_block_tmp = replace(
25 powershell.file.script_block_text,
26 """((\{\d+\}){2,}["']\s?-f|::Format[^\{]+(\{\d+\}){2,})""",
27 "🔥"
28)
29
30// count how many patterns were detected by calculating the number of 🔥 characters inserted
31| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
32
33// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
34| keep
35 Esql.script_block_pattern_count,
36 Esql.script_block_length,
37 Esql.script_block_tmp,
38 powershell.file.script_block_text,
39 powershell.file.script_block_id,
40 file.path,
41 file.directory,
42 powershell.sequence,
43 powershell.total,
44 _id,
45 _index,
46 host.name,
47 agent.id,
48 user.id
49
50// Filter for scripts that match the pattern at least four times
51| where Esql.script_block_pattern_count >= 4
52
53// Exclude Noisy Patterns
54
55// Icinga Framework
56| where not file.directory == "C:\\Program Files\\WindowsPowerShell\\Modules\\icinga-powershell-framework\\cache"
57 // ESQL requires this condition, otherwise it only returns matches where file.directory exists.
58 or file.directory IS NULL
59
60| where not (powershell.file.script_block_text LIKE "*GitBranchStatus*" AND
61 powershell.file.script_block_text LIKE "*$s.BranchBehindStatusSymbol.Text*")
62| where not
63 // https://wtfbins.wtf/17
64 (
65 (powershell.file.script_block_text like "*sentinelbreakpoints*" or
66 powershell.file.script_block_text like "*:::::\\\\windows\\\\sentinel*")
67 and
68 (powershell.file.script_block_text like "*$local:Bypassed*" or
69 powershell.file.script_block_text like "*origPSExecutionPolicyPreference*")
70 )
71'''
72
73
74[[rule.threat]]
75framework = "MITRE ATT&CK"
76[[rule.threat.technique]]
77id = "T1027"
78name = "Obfuscated Files or Information"
79reference = "https://attack.mitre.org/techniques/T1027/"
80
81[[rule.threat.technique]]
82id = "T1140"
83name = "Deobfuscate/Decode Files or Information"
84reference = "https://attack.mitre.org/techniques/T1140/"
85
86
87[rule.threat.tactic]
88id = "TA0005"
89name = "Defense Evasion"
90reference = "https://attack.mitre.org/tactics/TA0005/"
91[[rule.threat]]
92framework = "MITRE ATT&CK"
93[[rule.threat.technique]]
94id = "T1059"
95name = "Command and Scripting Interpreter"
96reference = "https://attack.mitre.org/techniques/T1059/"
97[[rule.threat.technique.subtechnique]]
98id = "T1059.001"
99name = "PowerShell"
100reference = "https://attack.mitre.org/techniques/T1059/001/"
101
102
103
104[rule.threat.tactic]
105id = "TA0002"
106name = "Execution"
107reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Potential PowerShell Obfuscation via String Reordering
PowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like string reordering to evade detection. This involves rearranging strings and reconstructing them at runtime, bypassing static analysis and security measures. The detection rule identifies scripts with excessive length and specific patterns, flagging those with multiple occurrences of string format expressions, which are indicative of obfuscation attempts. By filtering out known benign patterns, it reduces false positives, focusing on genuine threats.
Possible investigation steps
- Review the script block text by examining the powershell.file.script_block_text field to understand the nature of the obfuscation and identify any potentially malicious commands or patterns.
- Check the file.path and file.name fields to determine the origin and context of the script, which can provide insights into whether the script is part of a legitimate application or a potential threat.
- Investigate the host.name and user.id fields to identify the affected system and user, which can help in assessing the potential impact and scope of the incident.
- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and history of the script, which may reveal additional suspicious activities or related scripts.
- Correlate the alert with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.
False positive analysis
- Scripts related to the Icinga Framework may trigger false positives due to their use of string formatting. To handle this, ensure that the file name "framework_cache.psm1" is excluded from the detection rule.
- PowerShell scripts that include specific sentinel patterns, such as "sentinelbreakpoints" or paths like ":::::\windows\sentinel", combined with variables like "$local:Bypassed" or "origPSExecutionPolicyPreference", are known to be benign. These should be excluded to reduce noise.
- Regularly review and update the exclusion list to include any new benign patterns that are identified over time, ensuring the rule remains effective without generating unnecessary alerts.
- Consider implementing a whitelist of known safe scripts or script authors to further minimize false positives, especially in environments with frequent legitimate use of complex PowerShell scripts.
Response and remediation
- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.
- Conduct a thorough review of the PowerShell script block text flagged by the alert to understand the intent and potential impact of the obfuscated script.
- Remove any malicious scripts or files identified during the investigation from the affected system to prevent re-execution.
- Restore the system from a known good backup if the script has caused significant changes or damage to the system.
- Update and strengthen endpoint protection measures, ensuring that AMSI and other security tools are fully operational and configured to detect similar obfuscation techniques.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
Related rules
- Dynamic IEX Reconstruction via Method String Access
- Potential Dynamic IEX Reconstruction via Environment Variables
- Potential PowerShell Obfuscation via High Numeric Character Proportion
- Potential PowerShell Obfuscation via Invalid Escape Sequences
- Potential PowerShell Obfuscation via Reverse Keywords