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, and user.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.
  • Reconstruct the complete script block before making an assessment:

    • Review powershell.file.script_block_text and 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_id together with powershell.sequence and powershell.total to assemble the full script in the correct order. Confirm all sequence parts are present.
    • 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.
  • Determine the likely source of the script content:

    • 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.
    • If file.path is 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.path and file.name to identify other executions or duplicates of the same script across users and hosts.
  • 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_text across the environment. Start with the same user.id and host.id, then expand to other users and hosts.
    • 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.
    • If other endpoint telemetry is available, correlate around @timestamp on 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.name that could explain the session context (interactive use vs remote access).

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.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.
    • 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.
  • 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

to-top