Potential PowerShell HackTool Script by Author
Identifies PowerShell script block content containing known offensive-tool author handles or attribution strings (for example, public tool author names). Attackers often run public PowerShell tooling with minimal changes, leaving author artifacts in comments or headers.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/05/08"
3integration = ["windows"]
4maturity = "production"
5updated_date = "2026/02/09"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies PowerShell script block content containing known offensive-tool author handles or attribution strings (for
11example, public tool author names). Attackers often run public PowerShell tooling with minimal changes, leaving author
12artifacts in comments or headers.
13"""
14from = "now-9m"
15index = ["winlogbeat-*", "logs-windows.powershell*"]
16language = "kuery"
17license = "Elastic License v2"
18name = "Potential PowerShell HackTool Script by Author"
19note = """## Triage and analysis
20
21> **Disclaimer**:
22> 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.
23
24### Investigating Potential PowerShell HackTool Script by Author
25
26This rule Detects PowerShell scripts that contains attribution strings commonly found in publicly available offensive PowerShell tooling. These artifacts are often present in headers or comment blocks but may also appear within embedded modules or minimally modified scripts. Use the script block content and metadata to reconstruct what ran, determine the likely source, and scope related activity across hosts and users.
27
28#### Key alert fields to review
29
30- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
31- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
32- `powershell.file.script_block_text`: Script block content that matched the detection logic.
33- `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.
34- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
35- `powershell.file.script_block_length`: Script block length (size) context.
36
37#### Possible investigation steps
38
39- Capture basic context and triage priority:
40 - Record `@timestamp`, `host.name`/`host.id`, and `user.name`/`user.domain`/`user.id`.
41 - Use host and identity context (asset owner, role, and expected admin activity) to determine whether this execution is likely authorized for the alerted user and endpoint.
42
43- Reconstruct the complete script block before making an assessment:
44 - Review `powershell.file.script_block_text` and identify the specific author handle or attribution string and its surrounding lines.
45 - If the content appears truncated or the event indicates multiple parts, use `powershell.file.script_block_id` together with `powershell.sequence` and `powershell.total` to assemble the full script in the correct order. Confirm all sequence parts are present.
46 - Use `powershell.file.script_block_length` as additional context (for example, to distinguish short snippets from large modules) and preserve the reconstructed content for evidence and hunting.
47
48- Determine the likely source of the script content:
49 - If `file.path`/`file.name` (and `file.directory`) are present, treat this as file-backed execution and note whether the location and filename align with approved script storage or deployment paths for that host.
50 - If `file.path` is a network share (UNC) or otherwise unusual for the host, treat it as higher risk until validated.
51 - If file fields are absent, treat the script block as inline, interactive, or dynamically generated content. Prioritize review for scripts that fetch, decode, or build additional code at runtime.
52 - If a file path is present, pivot on `file.path` and `file.name` to identify other executions or duplicates of the same script across users and hosts.
53
54- Assess intent from the content and extract observables:
55 - Determine whether the match is limited to comments/metadata or is accompanied by functional code.
56 - Look for behaviors that commonly accompany offensive PowerShell tooling, such as broad host or domain discovery, credential access helpers, privilege manipulation, remote execution primitives, persistence logic, or payload delivery mechanisms.
57 - Extract and record observables embedded in `powershell.file.script_block_text` (for example, domains, IPs, URLs, hostnames, usernames, file paths, or registry paths) and use them to pivot for additional activity.
58
59- Scope and correlate related activity:
60 - Search for additional script block events containing the same author handle within `powershell.file.script_block_text` across the environment. Start with the same `user.id` and `host.id`, then expand to other users and hosts.
61 - On the same `host.name`, review other script block events from the same `user.name` in the minutes before and after the alert to identify setup actions (module imports, function definitions) and follow-on execution.
62 - If other endpoint telemetry is available, correlate around `@timestamp` on the same host to identify:
63 - The PowerShell host process and any parent process responsible for launching it.
64 - Network connections, file writes, or registry changes consistent with the script content and extracted observables.
65 - Authentication activity for `user.name` that could explain the session context (interactive use vs remote access).
66
67### False positive analysis
68
69- Legitimate administrative scripts may incorporate third-party modules that include author headers; these are typically file-backed and executed from expected locations or managed repositories.
70- False positives are more likely when the author string is isolated within comments and there is minimal additional script functionality; they are less likely when the script implements operational capabilities aligned with offensive tooling.
71
72### Response and remediation
73
74- If activity is unauthorized or suspicious:
75 - Preserve the full reconstructed script content (all parts) and retain supporting context: `powershell.file.script_block_id`, `host.id`, `host.name`, `user.id`, `user.name`, `user.domain`, and `@timestamp`.
76 - Scope impact by searching for the same author handle and extracted observables across PowerShell script block logs to identify additional affected hosts and accounts.
77 - If `file.path` is present, locate and quarantine the referenced script per your procedures and review the endpoint for other copies that share the same `file.name`.
78 - Apply containment measures appropriate to the risk (for example, isolate the endpoint from the network) if the content indicates credential access, remote execution, or payload delivery.
79 - Review the initiating account for compromise and take credential and access control actions consistent with your incident response process.
80
81- If activity is authorized:
82 - Document the activity (owner, timeframe, intended hosts) and validate alignment with change management or testing approvals.
83 - Ensure the SOC has an up-to-date list of approved users and endpoints for testing. Consider environment-specific tuning to reduce recurring noise while preserving coverage elsewhere.
84
85- Post-incident hardening:
86 - Verify PowerShell logging coverage and retention are sufficient to reconstruct multi-part scripts during future investigations.
87 - Use observed handles and extracted observables to perform retrospective searches for earlier executions and related activity patterns in historical script block logs.
88"""
89references = [
90 "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md",
91]
92risk_score = 73
93rule_id = "2553a9af-52a4-4a05-bb03-85b2a479a0a0"
94setup = """## Setup
95
96PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
97Setup instructions: https://ela.st/powershell-logging-setup
98"""
99severity = "high"
100tags = [
101 "Domain: Endpoint",
102 "OS: Windows",
103 "Use Case: Threat Detection",
104 "Tactic: Execution",
105 "Data Source: PowerShell Logs",
106 "Resources: Investigation Guide",
107]
108timestamp_override = "event.ingested"
109type = "query"
110
111query = '''
112host.os.type:windows and event.category:process and
113 powershell.file.script_block_text : (
114 "mattifestation" or "JosephBialek" or
115 "harmj0y" or "ukstufus" or
116 "SecureThisShit" or "Matthew Graeber" or
117 "secabstraction" or "mgeeky" or
118 "oddvarmoe" or "am0nsec" or
119 "obscuresec" or "sixdub" or
120 "darkoperator" or "funoverip" or
121 "rvrsh3ll" or "kevin_robertson" or
122 "dafthack" or "r4wd3r" or
123 "danielhbohannon" or "OneLogicalMyth" or
124 "cobbr_io" or "xorrior" or
125 "PetrMedonos" or "citronneur" or
126 "eladshamir" or "RastaMouse" or
127 "enigma0x3" or "FuzzySec" or
128 "424f424f" or "jaredhaight" or
129 "fullmetalcache" or "Hubbl3" or
130 "curi0usJack" or "Cx01N" or
131 "itm4n" or "nurfed1" or
132 "cfalta" or "Scott Sutherland" or
133 "_nullbind" or "_tmenochet" or
134 "jaredcatkinson" or "ChrisTruncer" or
135 "monoxgas" or "TheRealWover" or
136 "splinter_code"
137 ) and
138 not powershell.file.script_block_text : ("Get-UEFIDatabaseSigner" or "Posh-SSH")
139'''
140
141
142[[rule.threat]]
143framework = "MITRE ATT&CK"
144[[rule.threat.technique]]
145id = "T1059"
146name = "Command and Scripting Interpreter"
147reference = "https://attack.mitre.org/techniques/T1059/"
148[[rule.threat.technique.subtechnique]]
149id = "T1059.001"
150name = "PowerShell"
151reference = "https://attack.mitre.org/techniques/T1059/001/"
152
153
154
155[rule.threat.tactic]
156id = "TA0002"
157name = "Execution"
158reference = "https://attack.mitre.org/tactics/TA0002/"
159
160[rule.investigation_fields]
161field_names = [
162 "@timestamp",
163 "user.name",
164 "user.id",
165 "user.domain",
166 "powershell.file.script_block_text",
167 "powershell.file.script_block_id",
168 "powershell.sequence",
169 "powershell.total",
170 "file.path",
171 "file.directory",
172 "file.name",
173 "process.pid",
174 "host.name",
175 "host.id",
176 "powershell.file.script_block_length"
177]
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 PowerShell HackTool Script by Author
This rule Detects PowerShell scripts that contains attribution strings commonly found in publicly available offensive PowerShell tooling. These artifacts are often present in headers or comment blocks but may also appear within embedded modules or minimally modified scripts. Use the script block content and metadata to reconstruct what ran, determine the likely source, and scope related activity across hosts and users.
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 basic context and triage priority:
- Record
@timestamp,host.name/host.id, anduser.name/user.domain/user.id. - Use host and identity context (asset owner, role, and expected admin activity) to determine whether this execution is likely authorized for the alerted user and endpoint.
- Record
-
Reconstruct the complete script block before making an assessment:
- Review
powershell.file.script_block_textand identify the specific author handle or attribution string and its surrounding lines. - If the content appears truncated or the event indicates multiple parts, use
powershell.file.script_block_idtogether withpowershell.sequenceandpowershell.totalto assemble the full script in the correct order. Confirm all sequence parts are present. - Use
powershell.file.script_block_lengthas additional context (for example, to distinguish short snippets from large modules) and preserve the reconstructed content for evidence and hunting.
- Review
-
Determine the likely source of the script content:
- If
file.path/file.name(andfile.directory) are present, treat this as file-backed execution and note whether the location and filename align with approved script storage or deployment paths for that host. - If
file.pathis a network share (UNC) or otherwise unusual for the host, treat it as higher risk until validated. - If file fields are absent, treat the script block as inline, interactive, or dynamically generated content. Prioritize review for scripts that fetch, decode, or build additional code at runtime.
- If a file path is present, pivot on
file.pathandfile.nameto identify other executions or duplicates of the same script across users and hosts.
- If
-
Assess intent from the content and extract observables:
- Determine whether the match is limited to comments/metadata or is accompanied by functional code.
- Look for behaviors that commonly accompany offensive PowerShell tooling, such as broad host or domain discovery, credential access helpers, privilege manipulation, remote execution primitives, persistence logic, or payload delivery mechanisms.
- Extract and record observables embedded in
powershell.file.script_block_text(for example, domains, IPs, URLs, hostnames, usernames, file paths, or registry paths) and use them to pivot for additional activity.
-
Scope and correlate related activity:
- Search for additional script block events containing the same author handle within
powershell.file.script_block_textacross the environment. Start with the sameuser.idandhost.id, then expand to other users and hosts. - On the same
host.name, review other script block events from the sameuser.namein the minutes before and after the alert to identify setup actions (module imports, function definitions) and follow-on execution. - If other endpoint telemetry is available, correlate around
@timestampon the same host to identify:- The PowerShell host process and any parent process responsible for launching it.
- Network connections, file writes, or registry changes consistent with the script content and extracted observables.
- Authentication activity for
user.namethat could explain the session context (interactive use vs remote access).
- Search for additional script block events containing the same author handle within
False positive analysis
- Legitimate administrative scripts may incorporate third-party modules that include author headers; these are typically file-backed and executed from expected locations or managed repositories.
- False positives are more likely when the author string is isolated within comments and there is minimal additional script functionality; they are less likely when the script implements operational capabilities aligned with offensive tooling.
Response and remediation
-
If activity is unauthorized or suspicious:
- Preserve the full reconstructed script content (all parts) and retain supporting context:
powershell.file.script_block_id,host.id,host.name,user.id,user.name,user.domain, and@timestamp. - Scope impact by searching for the same author handle and extracted observables across PowerShell script block logs to identify additional affected hosts and accounts.
- If
file.pathis present, locate and quarantine the referenced script per your procedures and review the endpoint for other copies that share the samefile.name. - Apply containment measures appropriate to the risk (for example, isolate the endpoint from the network) if the content indicates credential access, remote execution, or payload delivery.
- Review the initiating account for compromise and take credential and access control actions consistent with your incident response process.
- Preserve the full reconstructed script content (all parts) and retain supporting context:
-
If activity is authorized:
- Document the activity (owner, timeframe, intended hosts) and validate alignment with change management or testing approvals.
- Ensure the SOC has an up-to-date list of approved users and endpoints for testing. Consider environment-specific tuning to reduce recurring noise while preserving coverage elsewhere.
-
Post-incident hardening:
- Verify PowerShell logging coverage and retention are sufficient to reconstruct multi-part scripts during future investigations.
- Use observed handles and extracted observables to perform retrospective searches for earlier executions and related activity patterns in historical script block logs.
References
Related rules
- Potential Process Injection via PowerShell
- PowerShell Share Enumeration Script
- PowerShell Suspicious Discovery Related Windows API Functions
- Suspicious .NET Reflection via PowerShell
- Potential PowerShell Obfuscation via Special Character Overuse