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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2022/01/31"
  3integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/02/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal
 11their activities in the host and evade detection.
 12"""
 13from = "now-9m"
 14index = [
 15    "winlogbeat-*",
 16    "logs-endpoint.events.registry-*",
 17    "logs-windows.sysmon_operational-*",
 18    "endgame-*",
 19    "logs-m365_defender.event-*",
 20    "logs-sentinel_one_cloud_funnel.*",
 21    "logs-crowdstrike.fdr*",
 22]
 23language = "eql"
 24license = "Elastic License v2"
 25name = "PowerShell Script Block Logging Disabled"
 26note = """## Triage and analysis
 27
 28> **Disclaimer**:
 29> 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.
 30
 31### Investigating PowerShell Script Block Logging Disabled
 32
 33This 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.
 34
 35#### Key alert fields to review
 36
 37- `process.executable`: The process responsible for modifying the registry value.
 38- `registry.value`: The registry value name that was changed (`EnableScriptBlockLogging`).
 39- `registry.data.strings`: The new data indicating the setting was disabled.
 40- `registry.path`: The full registry path of the modified value.
 41- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
 42- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
 43
 44#### Possible investigation steps
 45
 46- Establish the affected endpoint and time window:
 47  - 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).
 48  - Prioritize based on endpoint role and criticality (for example, servers and admin workstations).
 49
 50- Validate the registry change and its scope:
 51  - Review `registry.path`, `registry.value`, and `registry.data.strings` to confirm the setting was disabled and to understand where it was applied.
 52  - Compare `registry.path` to common policy locations for Script Block Logging (for example, `HKEY_LOCAL_MACHINE\\Software\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\\EnableScriptBlockLogging`).
 53  - 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.
 54  - 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.
 55
 56- Identify the modifying process and execution context:
 57  - Review `process.executable` for legitimacy (expected binary name, expected install path) and whether it typically performs configuration changes.
 58  - 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.
 59  - 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.
 60
 61- Assess the user context and authorization:
 62  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to manage logging or policy settings on this endpoint.
 63  - 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.
 64  - Scope the user across other hosts for similar activity during the same window to identify potential credential misuse.
 65
 66- Hunt for related activity that may be masked by reduced logging:
 67  - 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).
 68  - Review host activity after the change for suspicious process launches, script interpreter activity, persistence attempts, credential access behavior, or lateral movement indicators.
 69  - Review network activity from the host around the change for connections consistent with payload retrieval, remote access, or command and control.
 70  - Review other registry changes around the same time that may further impair visibility or weaken defenses.
 71
 72- Scope and impact assessment across the environment:
 73  - 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.
 74  - Pivot on `process.executable` and `user.id` to identify other endpoints where the same process or account modified this setting.
 75  - Identify whether the setting was later restored on the same host by looking for subsequent changes to the same `registry.path` and `registry.value`.
 76
 77### False positive analysis
 78
 79- Authorized policy, baseline, or hardening changes that intentionally modify PowerShell logging settings, supported by change records and consistent execution by expected accounts and tooling.
 80- Provisioning or imaging workflows where configuration changes occur during early host lifecycle stages and are consistent across a known deployment batch.
 81- Short-lived administrative troubleshooting where the setting is temporarily changed and promptly restored, with supporting documentation.
 82
 83### Response and remediation
 84
 85- If the change is unexpected or suspicious:
 86  - Treat as potential defense evasion and escalate according to incident response procedures.
 87  - Contain the endpoint if there are indicators of follow-on malicious activity in the surrounding timeframe.
 88  - Preserve evidence related to the change, including `process.executable`, `process.command_line`, user context, and any correlated endpoint telemetry.
 89
 90- Restore and enforce PowerShell visibility:
 91  - Re-enable Script Block Logging using approved administrative processes and verify the setting persists through policy enforcement.
 92  - Monitor for repeated attempts to disable Script Block Logging, especially from the same user or originating process.
 93
 94- Remediate root cause and reduce recurrence:
 95  - Identify and remove unauthorized tooling or persistence associated with the modifying process.
 96  - Investigate potential account compromise for the associated user and take appropriate actions (credential reset and access review), prioritizing privileged accounts.
 97  - Hunt for additional endpoints impacted by the same user or process and remediate as needed.
 98  - 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.
 99"""
100references = [
101    "https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.PowerShell::EnableScriptBlockLogging",
102]
103risk_score = 47
104rule_id = "818e23e6-2094-4f0e-8c01-22d30f3506c6"
105severity = "medium"
106tags = [
107    "Domain: Endpoint",
108    "OS: Windows",
109    "Use Case: Threat Detection",
110    "Tactic: Defense Evasion",
111    "Resources: Investigation Guide",
112    "Data Source: Elastic Endgame",
113    "Data Source: Elastic Defend",
114    "Data Source: Sysmon",
115    "Data Source: Microsoft Defender for Endpoint",
116    "Data Source: SentinelOne",
117    "Data Source: Crowdstrike",
118]
119timestamp_override = "event.ingested"
120type = "eql"
121
122query = '''
123registry where host.os.type == "windows" and event.type == "change" and
124    registry.value : "EnableScriptBlockLogging" and
125    registry.data.strings : ("0", "0x00000000") and
126    not process.executable : (
127          "?:\\Windows\\System32\\svchost.exe",
128          "?:\\Windows\\System32\\DeviceEnroller.exe",
129          "?:\\Windows\\system32\\omadmclient.exe",
130          "?:\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe",
131          "?:\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe",
132          
133          /* Crowdstrike specific exclusion as it uses NT Object paths */
134          "\\Device\\HarddiskVolume*\\Windows\\System32\\svchost.exe",
135          "\\Device\\HarddiskVolume*\\Windows\\System32\\DeviceEnroller.exe",
136          "\\Device\\HarddiskVolume*\\Windows\\system32\\omadmclient.exe",
137          "\\Device\\HarddiskVolume*\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe",
138          "\\Device\\HarddiskVolume*\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe"
139    )
140'''
141
142
143[[rule.threat]]
144framework = "MITRE ATT&CK"
145[[rule.threat.technique]]
146id = "T1112"
147name = "Modify Registry"
148reference = "https://attack.mitre.org/techniques/T1112/"
149
150[[rule.threat.technique]]
151id = "T1562"
152name = "Impair Defenses"
153reference = "https://attack.mitre.org/techniques/T1562/"
154[[rule.threat.technique.subtechnique]]
155id = "T1562.002"
156name = "Disable Windows Event Logging"
157reference = "https://attack.mitre.org/techniques/T1562/002/"
158
159
160
161[rule.threat.tactic]
162id = "TA0005"
163name = "Defense Evasion"
164reference = "https://attack.mitre.org/tactics/TA0005/"
165
166[rule.investigation_fields]
167field_names = [
168    "@timestamp",
169    "registry.path",
170    "registry.value",
171    "registry.data.strings",
172    "process.executable",
173    "process.entity_id",
174    "host.name",
175    "host.id",
176    "user.name",
177    "user.id",
178    "user.domain"
179]

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 PowerShell Script Block Logging Disabled

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.

Key alert fields to review

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

Possible investigation steps

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

False positive analysis

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

Response and remediation

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

References

Related rules

to-top