Loading

PowerShell Script Block Logging Disabled

Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal their activities in the host and evade detection.

Rule type: eql
Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.registry-*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-crowdstrike.fdr*

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

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: Microsoft Defender for Endpoint
  • Data Source: SentinelOne
  • Data Source: Crowdstrike

Version: 314
Rule authors:

  • Elastic

Rule license: Elastic License v2

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 alert indicates a registry modification that set EnableScriptBlockLogging to a disabled value (registry.data.strings of 0 or 0x00000000). Disabling Script Block Logging reduces visibility into PowerShell execution and is commonly used to evade detection, especially when followed by script-driven activity.

  • process.executable: The process responsible for modifying the registry value.
  • registry.value: The registry value name that was changed (EnableScriptBlockLogging).
  • registry.data.strings: The new data indicating the setting was disabled.
  • registry.path: The full registry path of the modified value.
  • 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.

  • Establish the affected endpoint and time window:

    • Use host.name, host.id, and @timestamp to identify the impacted endpoint and define a review window (include activity immediately before and after the change).
    • Prioritize based on endpoint role and criticality (for example, servers and admin workstations).

  • Validate the registry change and its scope:

    • Review registry.path, registry.value, and registry.data.strings to confirm the setting was disabled and to understand where it was applied.
    • Compare registry.path to common policy locations for Script Block Logging (for example, HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging).
    • Determine whether the change is likely machine-wide or user-scoped based on the hive reflected in registry.path, and assess the blast radius accordingly.
    • Check for repeated changes (toggling) to the same registry.path and registry.value around the alert time, which can indicate attempted evasion or policy enforcement conflicts.

  • Identify the modifying process and execution context:

    • Review process.executable for legitimacy (expected binary name, expected install path) and whether it typically performs configuration changes.
    • Pivoting using process.entity_id, review process.command_line to understand how the value was set and whether the command line suggests interactive administration, scripts, or automation.
    • Using nearby endpoint process telemetry on the same host, reconstruct the process tree to identify the initiating process (parent) and any immediate follow-on execution that may have benefited from reduced PowerShell logging.

  • Assess the user context and authorization:

    • Review user.name, user.domain, and user.id to determine whether the account is expected to manage logging or policy settings on this endpoint.
    • If the change is attributed to a service or system context, identify the associated service, scheduled activity, or management workflow that could have performed the modification.
    • Scope the user across other hosts for similar activity during the same window to identify potential credential misuse.

  • Hunt for related activity that may be masked by reduced logging:

    • Review host activity immediately before the change for suspicious behavior that could explain the need to disable Script Block Logging (initial access, privilege escalation, or tool staging).
    • Review host activity after the change for suspicious process launches, script interpreter activity, persistence attempts, credential access behavior, or lateral movement indicators.
    • Review network activity from the host around the change for connections consistent with payload retrieval, remote access, or command and control.
    • Review other registry changes around the same time that may further impair visibility or weaken defenses.

  • Scope and impact assessment across the environment:

    • Search for other instances where registry.value is EnableScriptBlockLogging and registry.data.strings indicates a disabled state to determine whether this is isolated or widespread.
    • Pivot on process.executable and user.id to identify other endpoints where the same process or account modified this setting.
    • Identify whether the setting was later restored on the same host by looking for subsequent changes to the same registry.path and registry.value.
  • Authorized policy, baseline, or hardening changes that intentionally modify PowerShell logging settings, supported by change records and consistent execution by expected accounts and tooling.
  • Provisioning or imaging workflows where configuration changes occur during early host lifecycle stages and are consistent across a known deployment batch.
  • Short-lived administrative troubleshooting where the setting is temporarily changed and promptly restored, with supporting documentation.

  • If the change is unexpected or suspicious:

    • Treat as potential defense evasion and escalate according to incident response procedures.
    • Contain the endpoint if there are indicators of follow-on malicious activity in the surrounding timeframe.
    • Preserve evidence related to the change, including process.executable, process.command_line, user context, and any correlated endpoint telemetry.

  • Restore and enforce PowerShell visibility:

    • Re-enable Script Block Logging using approved administrative processes and verify the setting persists through policy enforcement.
    • Monitor for repeated attempts to disable Script Block Logging, especially from the same user or originating process.

  • Remediate root cause and reduce recurrence:

    • Identify and remove unauthorized tooling or persistence associated with the modifying process.
    • Investigate potential account compromise for the associated user and take appropriate actions (credential reset and access review), prioritizing privileged accounts.
    • Hunt for additional endpoints impacted by the same user or process and remediate as needed.
    • Apply least-privilege controls to limit who can modify logging-related registry settings and improve alerting for additional defense impairment behaviors observed during the investigation window.
registry where host.os.type == "windows" and event.type == "change" and
    registry.value : "EnableScriptBlockLogging" and
    registry.data.strings : ("0", "0x00000000") and
    not process.executable : (
          "?:\\Windows\\System32\\svchost.exe",
          "?:\\Windows\\System32\\DeviceEnroller.exe",
          "?:\\Windows\\system32\\omadmclient.exe",
          "?:\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe",
          "?:\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe",

          /* Crowdstrike specific exclusion as it uses NT Object paths */
          "\\Device\\HarddiskVolume*\\Windows\\System32\\svchost.exe",
          "\\Device\\HarddiskVolume*\\Windows\\System32\\DeviceEnroller.exe",
          "\\Device\\HarddiskVolume*\\Windows\\system32\\omadmclient.exe",
          "\\Device\\HarddiskVolume*\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe",
          "\\Device\\HarddiskVolume*\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe"
    )

Framework: MITRE ATT&CK