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@timestampto 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).
- Use
-
Validate the registry change and its scope:
- Review
registry.path,registry.value, andregistry.data.stringsto confirm the setting was disabled and to understand where it was applied. - Compare
registry.pathto 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.pathandregistry.valuearound the alert time, which can indicate attempted evasion or policy enforcement conflicts.
- Review
-
Identify the modifying process and execution context:
- Review
process.executablefor legitimacy (expected binary name, expected install path) and whether it typically performs configuration changes. - Pivoting using
process.entity_id, reviewprocess.command_lineto 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.
- Review
-
Assess the user context and authorization:
- Review
user.name,user.domain, anduser.idto 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.
- Review
-
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.valueisEnableScriptBlockLoggingandregistry.data.stringsindicates a disabled state to determine whether this is isolated or widespread. - Pivot on
process.executableanduser.idto 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.pathandregistry.value.
- Search for other instances where
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
- Command Execution via ForFiles
- Potential System Tampering via File Modification
- Command Obfuscation via Unicode Modifier Letters
- DNS Global Query Block List Modified or Disabled
- Disabling Lsa Protection via Registry Modification