Detect disabled PowerShell script block logging by monitoring configuration changes and policy updates that stop script content from being recorded. Alert when logging is turned off, reduced, or excluded on hosts that normally enforce it, and verify whether the change was authorised. Treat logging suppression as suspicious when it occurs near script execution, obfuscation, or other defence evasion.
What to watch in Windows policy and audit state
script block logging is usually disabled through policy changes, registry edits, or security tooling that alters how Windows records PowerShell content. The key signal is not just that logging stopped, but that a host which normally produces these records suddenly changes its audit posture. That change is often more important than the absence of a single event.
Monitor for edits to the PowerShell logging policy path, changes to Group Policy settings, and tampering with related audit or event forwarding configuration. On managed systems, a deviation from the expected baseline should be treated as an alertable configuration drift, especially if the host is within a tier where PowerShell is routinely used for administration.
Because PowerShell logging is one layer in a broader visibility stack, it is best understood alongside other Windows telemetry. NHIMG’s PowerShell Security Guide covers the control set around script block logging, transcription, AMSI, constrained language mode, and common abuse patterns that often appear when logging is being suppressed.
How attackers and administrators change the signal
Attackers suppressing script block logging are usually trying to remove visibility into obfuscated commands, encoded payloads, in-memory activity, or post-compromise automation. If logging disappears near script execution, suspicious parent-child process chains, or known defence-evasion techniques, that timing matters more than the isolated configuration change.
Administrators can also turn logging off for legitimate reasons, such as troubleshooting, legacy application compatibility, or performance concerns. The detection problem is therefore one of context: a logged change is not automatically malicious, but a change that weakens visibility on a sensitive host, or that is not backed by an approved maintenance action, deserves follow-up.
Cross-check the change against surrounding Windows activity. The broader event trail in Windows Event Log Guide helps correlate audit-policy changes, service activity, log clearing, and other state changes that often accompany attempts to reduce detection coverage.
Building a reliable detection rule
A practical rule should combine configuration monitoring with behavioural context. Alert when script block logging is turned off, reduced, or excluded on a host that is expected to enforce it, then enrich the alert with the user, process, host role, and any recent PowerShell execution. The strongest detections are those that distinguish planned policy change from unauthorised suppression.
Look for related indicators such as scheduled task creation, service changes, registry edits, or other persistence and evasion actions occurring in the same window. If the change precedes lateral movement, payload staging, or remote administration activity, the logging change is likely part of a broader intrusion sequence rather than an isolated hardening exception.
When the host role is important to your environment, compare it with common persistence patterns and execution-hiding techniques described in the Persistence Techniques Guide. That context helps analysts separate benign admin work from a deliberate attempt to reduce telemetry around long-running access.
Risk and Threat Considerations
When script block logging is disabled, defenders lose one of the clearest records of what PowerShell actually executed. That creates an exposure window for obfuscated commands, fileless tradecraft, and hands-on-keyboard activity that would otherwise leave a durable audit trail.
Failure mechanism: The control fails when policy drift, registry tampering, or local privilege abuse suppresses script content logging while PowerShell remains available for execution. That breaks both detection and after-the-fact reconstruction.
Impact: Incident responders may be unable to reconstruct command history, identify the initial payload, or prove whether an admin change was legitimate. In practice, that raises dwell time and makes compromise validation much harder.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1562.002 — Impair Defenses: Disable or Modify Tools | Script block logging suppression is a defense-evasion pattern. |
| Recommendation — Map logging suppression to defense evasion and alert on telemetry impairment. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detecting logging disablement depends on audit log coverage and change visibility. |
| Recommendation — Monitor audit settings and alert on unauthorized log-control changes. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Generation | Script block logging is an audit-generation control for PowerShell activity. |
| CM-5 — Access Restrictions for Change | Disabling logging is a security-relevant configuration change that needs control. | |
| SI-4 — System Monitoring | The answer is about detecting a telemetry suppression condition. | |
| Recommendation — Verify audit generation remains enabled for PowerShell on in-scope hosts. Restrict who can alter logging policy and review every change. Correlate policy changes with monitoring alerts for suspicious host activity. | ||
Practitioner Guidance
What to verify: Confirm the expected baseline for each host group, then verify whether the logging change coincides with approved maintenance, gold image drift, or a broader hardening exception. If you cannot tie the change to a change record, treat it as a security event rather than a configuration nuisance.
Decision rule: If PowerShell logging is disabled on a system that can reach sensitive data, privileged administration paths, or remote execution tooling, prioritise containment and provenance checking before assuming the change is benign. If the same host also shows obfuscation, encoded commands, or log-clearing behaviour, escalate immediately.
Practitioner takeaway: The important question is not simply whether logging was turned off, but whether a previously visible execution path was intentionally made opaque at the same time other attacker-like behaviours appeared.