Potential PowerShell Obfuscation via Reverse Keywords
Identifies PowerShell scripts that use reversed strings 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/14"
3integration = ["windows"]
4maturity = "production"
5updated_date = "2025/08/14"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade
11static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
12"""
13from = "now-9m"
14language = "esql"
15license = "Elastic License v2"
16name = "Potential PowerShell Obfuscation via Reverse Keywords"
17note = """ ## Triage and analysis
18
19> **Disclaimer**:
20> 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.
21
22### Investigating Potential PowerShell Obfuscation via Reverse Keywords
23
24PowerShell, a powerful scripting language in Windows environments, is often targeted by adversaries for obfuscation to bypass security measures like AMSI. Attackers reverse keywords in scripts to evade static analysis. The detection rule identifies such obfuscation by searching for reversed keywords, replacing them with a unique marker, and counting occurrences. This helps in flagging scripts with multiple obfuscated elements, indicating potential malicious activity.
25
26### Possible investigation steps
27
28- Review the `powershell.file.script_block_text` field to understand the context and content of the script that triggered the alert. Look for any suspicious or unexpected behavior in the script logic.
29- Examine the `file.path` field to determine the location of the script on the system. This can provide insights into whether the script is part of a legitimate application or potentially malicious.
30- Check the `powershell.file.script_block_id` and `powershell.sequence` fields to identify if the script is part of a larger sequence of commands. This can help in understanding the full scope of the script's execution.
31- Investigate the `agent.id` field to identify the specific endpoint where the script was executed. This can help in correlating with other alerts or logs from the same machine.
32- Assess the `count` field to determine the extent of obfuscation. A higher count may indicate a more heavily obfuscated script, suggesting a higher likelihood of malicious intent.
33
34### False positive analysis
35
36- Scripts with legitimate administrative functions may use reversed keywords for benign purposes, such as custom logging or debugging. Review the context of the script to determine if the usage is intentional and non-malicious.
37- Automated scripts generated by legitimate software tools might include reversed keywords as part of their normal operation. Identify these tools and create exceptions for their known script patterns to prevent unnecessary alerts.
38- Developers or IT personnel might use reversed keywords in test environments to simulate obfuscation techniques. Ensure these environments are well-documented and excluded from production monitoring to avoid false positives.
39- PowerShell scripts used in educational or training settings may intentionally include obfuscation techniques for learning purposes. Exclude these scripts by identifying their unique characteristics or file paths.
40- Regularly update the list of excluded scripts or patterns as new legitimate use cases are identified, ensuring the detection rule remains effective without generating excessive false positives.
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 halt ongoing malicious activity.
46- Conduct a thorough review of the script block text and associated files to understand the scope and intent of the obfuscation.
47- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.
48- Restore affected systems from a known good backup if malicious activity has altered system integrity.
49- Update endpoint protection and security tools to recognize and block similar obfuscation techniques in the future.
50- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and monitoring of potential lateral movement or additional threats.
51"""
52risk_score = 21
53rule_id = "f38633f4-3b31-4c80-b13d-e77c70ce8254"
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"
17
18// Filter for scripts that contains these keywords using MATCH, boosts the query performance,
19// match will ignore the | and look for the individual words
20| where powershell.file.script_block_text : "rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod"
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 """(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\.|:vne$|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)""",
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_tmp,
37 powershell.file.script_block_text,
38 powershell.file.script_block_id,
39 file.path,
40 powershell.sequence,
41 powershell.total,
42 _id,
43 _index,
44 agent.id
45
46// Filter for scripts that match the pattern at least twice
47| where Esql.script_block_pattern_count >= 2
48'''
49
50
51[[rule.threat]]
52framework = "MITRE ATT&CK"
53[[rule.threat.technique]]
54id = "T1027"
55name = "Obfuscated Files or Information"
56reference = "https://attack.mitre.org/techniques/T1027/"
57
58[[rule.threat.technique]]
59id = "T1140"
60name = "Deobfuscate/Decode Files or Information"
61reference = "https://attack.mitre.org/techniques/T1140/"
62
63
64[rule.threat.tactic]
65id = "TA0005"
66name = "Defense Evasion"
67reference = "https://attack.mitre.org/tactics/TA0005/"
68[[rule.threat]]
69framework = "MITRE ATT&CK"
70[[rule.threat.technique]]
71id = "T1059"
72name = "Command and Scripting Interpreter"
73reference = "https://attack.mitre.org/techniques/T1059/"
74[[rule.threat.technique.subtechnique]]
75id = "T1059.001"
76name = "PowerShell"
77reference = "https://attack.mitre.org/techniques/T1059/001/"
78
79
80
81[rule.threat.tactic]
82id = "TA0002"
83name = "Execution"
84reference = "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 Reverse Keywords
PowerShell, a powerful scripting language in Windows environments, is often targeted by adversaries for obfuscation to bypass security measures like AMSI. Attackers reverse keywords in scripts to evade static analysis. The detection rule identifies such obfuscation by searching for reversed keywords, replacing them with a unique marker, and counting occurrences. This helps in flagging scripts with multiple obfuscated elements, indicating potential malicious activity.
Possible investigation steps
- Review the
powershell.file.script_block_text
field to understand the context and content of the script that triggered the alert. Look for any suspicious or unexpected behavior in the script logic. - Examine the
file.path
field to determine the location of the script on the system. This can provide insights into whether the script is part of a legitimate application or potentially malicious. - Check the
powershell.file.script_block_id
andpowershell.sequence
fields to identify if the script is part of a larger sequence of commands. This can help in understanding the full scope of the script's execution. - Investigate the
agent.id
field to identify the specific endpoint where the script was executed. This can help in correlating with other alerts or logs from the same machine. - Assess the
count
field to determine the extent of obfuscation. A higher count may indicate a more heavily obfuscated script, suggesting a higher likelihood of malicious intent.
False positive analysis
- Scripts with legitimate administrative functions may use reversed keywords for benign purposes, such as custom logging or debugging. Review the context of the script to determine if the usage is intentional and non-malicious.
- Automated scripts generated by legitimate software tools might include reversed keywords as part of their normal operation. Identify these tools and create exceptions for their known script patterns to prevent unnecessary alerts.
- Developers or IT personnel might use reversed keywords in test environments to simulate obfuscation techniques. Ensure these environments are well-documented and excluded from production monitoring to avoid false positives.
- PowerShell scripts used in educational or training settings may intentionally include obfuscation techniques for learning purposes. Exclude these scripts by identifying their unique characteristics or file paths.
- Regularly update the list of excluded scripts or patterns as new legitimate use cases are identified, ensuring the detection rule remains effective without generating excessive false positives.
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 halt ongoing malicious activity.
- Conduct a thorough review of the script block text and associated files to understand the scope and intent of the obfuscation.
- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.
- Restore affected systems from a known good backup if malicious activity has altered system integrity.
- Update endpoint protection and security tools to recognize and block similar obfuscation techniques in the future.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and monitoring of potential lateral movement or additional threats.
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 String Reordering