Security logging registry tampering
A registry value that governs a host's own security controls was written.
What it detects
A registry value that governs a host's own security controls was written. Each key below turns off, or loosens, something an investigation later depends on:
* PowerShell script-block / module / transcription logging — the record of what an attacker's PowerShell actually did * __PSLockdownPolicy and ExecutionPolicy — Constrained Language Mode and script restrictions * EnableLUA — User Account Control itself * Defender DisableAntiSpyware / DisableRealtimeMonitoring * Office AccessVBOM — unlocks programmatic access to the VBA project model, the prerequisite for macro-based self-modification
This is deliberately positioned at the top of an intrusion rather than the middle: logging is disabled BEFORE the noisy work, so this event is often the last thing recorded properly. Treat it as time-critical.
The rule fires on a write to the value regardless of the value written, because re-enabling a control is also worth an analyst's attention — an attacker restoring a setting to cover their tracks looks identical in the key name alone.
MITRE ATT&CK mapping
False positives and triage
Group Policy and endpoint-management tooling write several of these legitimately — that is exactly how an organisation ENABLES script-block logging. Two things separate policy from tampering.
First, the writing process: a GPO-driven change comes from svchost.exe (GPSvc) or your management agent. reg.exe, powershell.exe, or a binary in a user directory is the finding.
Second, the direction: read Details= in the event. 0 on an Enable* value, or 1 on a Disable* value, means a control was switched OFF. If your fleet is managed, baseline the expected writer once and treat anything else as an alert.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/windows/security_logging_registry_tampering.yaml, licensed under the Apache License 2.0.
id: windows.defense_evasion.security_logging_registry_tampering
version: 1.0.0
status: stable
severity: high
confidence: 0.8
platforms: [windows]
mitre_techniques: [T1562.001, T1562.002]
description: |
A registry value that governs a host's own security controls was written. Each key
below turns off, or loosens, something an investigation later depends on:
* PowerShell script-block / module / transcription logging — the record of what
an attacker's PowerShell actually did
* `__PSLockdownPolicy` and `ExecutionPolicy` — Constrained Language Mode and
script restrictions
* `EnableLUA` — User Account Control itself
* Defender `DisableAntiSpyware` / `DisableRealtimeMonitoring`
* Office `AccessVBOM` — unlocks programmatic access to the VBA project model,
the prerequisite for macro-based self-modification
This is deliberately positioned at the top of an intrusion rather than the middle:
logging is disabled BEFORE the noisy work, so this event is often the last thing
recorded properly. Treat it as time-critical.
The rule fires on a write to the value regardless of the value written, because
re-enabling a control is also worth an analyst's attention — an attacker restoring
a setting to cover their tracks looks identical in the key name alone.
match:
registry_path_contains_any:
- 'ScriptBlockLogging\EnableScriptBlockLogging'
- 'ModuleLogging\EnableModuleLogging'
- 'Transcription\EnableTranscripting'
- '__PSLockdownPolicy'
- 'PowerShell\ExecutionPolicy'
- 'Policies\System\EnableLUA'
- 'Windows Defender\DisableAntiSpyware'
- 'Real-Time Protection\DisableRealtimeMonitoring'
- 'Real-Time Protection\DisableBehaviorMonitoring'
- 'Real-Time Protection\DisableScriptScanning'
- 'Security\AccessVBOM'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
Group Policy and endpoint-management tooling write several of these legitimately —
that is exactly how an organisation ENABLES script-block logging. Two things
separate policy from tampering.
First, the writing process: a GPO-driven change comes from `svchost.exe`
(GPSvc) or your management agent. `reg.exe`, `powershell.exe`, or a binary in a
user directory is the finding.
Second, the direction: read `Details=` in the event. `0` on an `Enable*` value, or
`1` on a `Disable*` value, means a control was switched OFF. If your fleet is
managed, baseline the expected writer once and treat anything else as an alert.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.