How to Enable PowerShell Script Block, Module, and Transcription Logging
A secure PowerShell logging rollout covering script blocks, modules, transcripts, protected event forwarding, sensitive data, capacity, tests, and tamper signals.
PowerShell provides complementary logging layers. Script Block Logging records parsed code; Module Logging records pipeline execution for selected modules; transcription captures a text record of host input/output. Enabling all of them without protecting storage can collect credentials and business data into a new high-value target. Define detection purpose, scope, transport, access, and retention before rollout.
Understand what each source observes
Script Block Logging emits events such as 4104 in the Microsoft-Windows-PowerShell/Operational channel and can capture deobfuscated script blocks as PowerShell interprets them. Multi-part messages need message-number/path reconstruction. Some suspicious content may be logged automatically by modern Windows PowerShell behavior, but enterprise visibility should use explicit supported policy.
Module Logging records command/pipeline details for configured module names. Wildcarding every module increases volume and sensitive data exposure; select high-value modules and validate what their events contain. Transcription writes human-readable session output and can include headers and invocation details depending on policy, but native processes or alternate hosts may not be represented as expected.
These controls are not an execution block. Attackers with sufficient administrative authority may disable policy, stop services, clear logs, or use another interpreter. Collect changes and gaps as detections and forward events off host promptly.
Apply supported policy centrally
Use the PowerShell Group Policy administrative template or MDM policy appropriate to managed Windows. Configure Turn on PowerShell Script Block Logging, selected Module Logging, and Turn on PowerShell Transcription with an approved output directory. Windows PowerShell 5.1 and PowerShell 7 have overlapping but distinct policy/configuration behavior; consult the exact product/version documentation.
For transcripts, use a protected central path only if authentication, availability, offline behavior, and filename collision are handled. A user-writable share lets a monitored user alter evidence. A central share can also expose every transcript to one compromised collector account. Restrict create/write/read rights, segment by host/user where supported, encrypt transport/storage, and monitor access.
Event logs integrate naturally with WEF. Size the operational channel so outages do not overwrite relevant records before forwarding. If Protected Event Logging is used, manage the encryption certificate and recovery/decryption process; a certificate without retained private-key recovery can make collected evidence unusable.
Minimize secret collection
Train script authors not to place plaintext secrets in command strings, variables printed to verbose/debug streams, or SecureString conversions that expose text. Prefer managed identity, certificate authentication, Windows credential facilities, and secret stores. Logging policy is not permission to retain passwords indefinitely.
Document legal/privacy basis, administrator access, retention, incident hold, and deletion. Redaction at ingestion can reduce exposure but may destroy detection context; test rules against representative commands and preserve integrity/auditability of transformations.
Verify with known fixtures
On a test endpoint, execute a harmless script block with a unique marker, import/invoke a selected test module, and start a session that should produce a transcript. Confirm the expected event IDs/fields and transcript arrive in protected central storage. Then test a nonselected module, constrained endpoint, remoting session, PowerShell 7, endpoint offline, collector unavailable, log full, and policy removal.
Monitor policy-registry changes through supported configuration management, event-log clear events, sudden loss of 4104 volume, transcript-share failures, and forwarding lag. The finished deployment creates useful code-level evidence with known blind spots while making that evidence harder—not easier—for ordinary users and intruders to read or erase.
Related:
- How to Apply Microsoft Security Baselines Without Overwriting Business Requirements
- ALPC on Windows: The Message Transport Behind Local System Services
Sources: