9.6 KiB
Scoped Windows PowerShell event logging
powershell-logging audits, plans and explicitly enables selected Windows PowerShell 5.1 module or script-block logging. This is separate from text transcription, advanced Security audit profiles, 4688 command-line capture and the broader configure command. It changes no channel, execution policy, service, invocation-logging preference, audit mask or transcript setting. Sysmon is excluded.
# Read-only inventory of machine/current-user Windows PowerShell policy,
# PowerShell Core policy, protected-event policy and the Operational channel.
./WELA.ps1 powershell-logging -ResultsPath new-audit.json
# Select exactly the requested controls and module names.
./WELA.ps1 powershell-logging -PowerShellLoggingAction Plan `
-PowerShellLoggingControl Module,ScriptBlock `
-PowerShellLoggingModuleName Microsoft.PowerShell.Utility -ResultsPath new-plan.json
./WELA.ps1 powershell-logging -PowerShellLoggingAction Configure `
-PowerShellLoggingControl Module,ScriptBlock `
-PowerShellLoggingModuleName Microsoft.PowerShell.Utility -DryRun
# After reviewing existing module names and the before-state:
./WELA.ps1 powershell-logging -PowerShellLoggingAction Configure `
-PowerShellLoggingControl Module,ScriptBlock `
-PowerShellLoggingModuleName Microsoft.PowerShell.Utility `
-Auto -BackupPath C:\WELA-Recovery\new-run -ResultsPath new-result.json
Use a native 64-bit Windows PowerShell 5.1 or PowerShell 7 host. The actual process SID, Windows role, build, patch and installed Windows PowerShell engine are read; impersonated callers are refused and caller role/build overrides are refused. Reviewed families are Windows 11 builds 22000, 22621, 22631, 26100 and 26200, and Server 2022/2025 builds 20348/26100. Native client, joined-member, DC and AD CS acceptance remains separate from hosted standalone-server tests. Winmgmt and EventLog must already run; the command starts no service. Configure requires elevation and a fresh recovery directory. Plan and Configure require explicit controls; there is no implicit enable-everything selection. Audit without selection inventories existing policy only.
The array examples are PowerShell syntax. When launching powershell.exe -File from another shell, use a reviewed PowerShell wrapper to bind multiple array elements correctly. Literal module names can contain ASCII letters, digits, dots, underscores and hyphens, up to 128 characters each. Up to 32 unique names can be selected. Paths and wildcard patterns are refused; the exact * value is accepted only when explicitly supplied to request all modules. Installation and execution of arbitrary selected modules are not performed or asserted.
Requested values and preserved scope
Under HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell:
| Selection | Requested values |
|---|---|
ScriptBlock |
ScriptBlockLogging\EnableScriptBlockLogging = DWORD 1 |
Module |
An explicit REG_SZ entry under ModuleLogging\ModuleNames for each selected module (name and data both equal the selected literal), then ModuleLogging\EnableModuleLogging = DWORD 1 |
An existing matching module entry is retained. The command does not delete or replace other module names: enabling Module logging also activates the existing configured module list, which can already include * or broader patterns. Review the entire Plan.Before.Machine tree, not just the newly selected names. A collision between a selected value name and different existing data is refused. Unknown DWORD values, incorrect selected types, and non-string/empty existing module entries block the complete preflight. Unselected existing values and key access descriptors are preserved. Missing selected keys may be created below the existing Microsoft Windows policy parent; their absence is recorded in the original snapshot.
Microsoft documents machine policy precedence over user policy, module pipeline logging, script-block logging, and the additional volume generated by invocation start/stop logging in Windows PowerShell Group Policy settings. The ADMX mapping documents the ModuleLogging registry location. This command offers explicit source controls; it does not import a Microsoft/CIS/ASD baseline or claim complete compliance with one.
SOFTWARE\Policies is shared across registry views. Both views are compared before a native-view write; no literal Wow6432Node policy tree is created. Snapshots include the Windows PowerShell machine and current-user policy trees, each bounded to 64 keys, eight levels, 128 values per key and one Mi character serialized data. Incomplete, denied, unstable or excessive trees are refused. Preflight projects all selected additions and refuses predictable key/value-count or serialized-value growth beyond these limits before any journal or write. New keys' inherited descriptor sizes remain subject to native readback. Existing owner/group/DACL observations are recorded; these snapshots do not claim registry SACL enumeration or effective access for other principals.
PowerShell 7 has separate PowerShell Core settings and an optional Windows-policy fallback. Its registry policy trees are observed and preserved; powershell.config.json, session behavior and fallback selection are not assessed. A PowerShell 7 deployment using that fallback may inherit changes to Windows PowerShell policy. Running WELA under PowerShell 7 does not establish PowerShell 7 event coverage. Existing sessions are not restarted or asserted to adopt the changes.
Script-block and module event content can include command arguments and script text. Existing protected-event settings are observed and preserved; the command does not provision encryption certificates, decrypt events, change event-reader permissions or assess whether a collector can read the resulting content.
Journals, drift and recovery
Every changed value has an original before.jsonl entry containing the full typed observed state, requested value and source fingerprints before its native setter runs. Module entries are added before the enable DWORD. The shared configuration runner handles DryRun, declined changes, immediate readback and final verification. The command compares host/engine/source hashes, channel metadata and all observed policy trees again after approval and journaling, then validates that only the one requested value and required new ancestor keys changed. Failed reads, partial writes, wrong readback or unrelated drift stop later operations. Available original/results evidence remains; no automatic rollback overwrites later policy.
This is not an atomic registry transaction. Another administrator or GPO can change state between observations. Local registry compliance does not identify the current authoritative GPO/MDM source, prove persistence after refresh or imply provider event generation. -Auto skips ordinary per-value prompts only. No group-policy refresh is invoked. A skipped/dry-run result is not configuration evidence; failures produce a nonzero exit. Each explicit ResultsPath must be a new file and is created without overwrite; protect the recovery parent and resulting host/policy evidence.
For manual recovery, compare the original journal, confirmed results and current state. Restore only each proven changed value, using its original registry type/data or removing that exact value when it was absent. Preserve other module names and all unrelated values. Remove a newly created key only when it was originally absent and remains empty. Never delete the whole PowerShell policy tree or restore old full descriptors. Determine whether a newer authoritative policy has superseded the recorded state before restoration.
Native validation and limits
The focused suite covers explicit selection, exact types, module-name collisions, preservation, journal-before-write, missing-key creation, inventory-capacity boundaries, idempotence, dry runs, refused output reuse, partial failures and approval-time drift. Public CLI tests reject unrelated/profile/role options before dispatch.
The opt-in disposable Server 2022/2025 matrix runs WELA under Windows PowerShell 5.1 and PowerShell 7. It saves native state, prepares selected disabled values, exercises the public Audit/Plan/DryRun/Configure path, checks original journals and idempotence, then launches a new fixed native Windows PowerShell 5.1 utility command with a unique benign marker. Native Operational event XML must match the owned child PID, provider GUID/name, actual SID, computer, record boundary and measured process-lifetime interval; script-block evidence additionally matches the exact script path/text and complete fragment counts. Only the fixture prepares policy or generates events. Wrong-type refusal and exact typed policy/key, channel and all-59-mask cleanup are required. Native event artifacts must be reviewed before claiming a matrix run passed.
These are configuration and local benign-event checks, not a Sigma rule match. Windows 11, managed clients, DC/CA hosts, x86 Windows PowerShell, PowerShell 7 event generation, forwarding, backend normalization/queries, retention and volume remain separate acceptance. Reports retain ReadyRuleCredit=0; issues #364, #366 and #387 remain open for their broader requirements.