PowerShell Script Block Logging Disabled
ELASTIC detection rule by Elastic · Elastic License v2
Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal
their activities in the host and evade detection.
[metadata]
creation_date = "2022/01/31"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"
[rule]
author = ["Elastic"]
description = """
Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal
their activities in the host and evade detection.
"""
from = "now-9m"
index = [
"winlogbeat-*",
"logs-endpoint.events.registry-*",
"logs-windows.sysmon_operational-*",
"endgame-*",
"logs-m365_defender.event-*",
"logs-sentinel_one_cloud_funnel.*",
"logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "PowerShell Script Block Logging Disabled"
note = """## 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.
"""
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
### Additional data sources
This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
"""
references = [
"https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.PowerShell::EnableScriptBlockLogging",
]
risk_score = 47
rule_id = "818e23e6-2094-4f0e-8c01-22d30f3506c6"
severity = "medium"
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 XDR",
"Data Source: SentinelOne",
"Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
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"
)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.002"
name = "Disable Windows Event Logging"
reference = "https://attack.mitre.org/techniques/T1562/002/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
"@timestamp",
"registry.path",
"registry.value",
"registry.data.strings",
"process.executable",
"process.entity_id",
"host.name",
"host.id",
"user.name",
"user.id",
"user.domain"
]