PowerShell Logging and Detection for Texas IT Teams in 2026

Out of the box, Windows logs PowerShell process starts (Event ID 4688 if process auditing is on) but does NOT log: the actual commands run, the script content executed, the modules loaded, or the remote sessions opened. An attacker running Invoke-Mimikatz | Out-String generates the same default log entry as a legitimate admin running Get-Service — both show "powershell.exe started by user X."

This means default-configured Windows environments are blind to the most prevalent attack technique in modern intrusions. Closing this gap is the single highest-leverage detection improvement most Texas IT teams can make.

Layer 1: Module Logging (Event ID 4103)

Logs each PowerShell module member as it executes, including parameters and output objects. Useful for tracking which cmdlets ran but does not capture the script body.

Enable via Group Policy: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → "Turn on Module Logging" → Enabled. Module Names: *

Layer 2: Script Block Logging (Event ID 4104)

Logs the full deobfuscated script text as it is executed — including Base64-decoded payloads, encoded commands, and dynamically constructed strings. This is the single most valuable PowerShell log source. Captures everything an attacker actually runs, defeating most obfuscation.

Enable via Group Policy: Same path → "Turn on PowerShell Script Block Logging" → Enabled.

Layer 3: Transcription (text logs to disk)

Captures the full PowerShell session as a plain-text transcript on disk for every console session. Useful for forensics and compliance evidence — provides a human-readable record of exactly what was typed and what came back.

Enable via Group Policy: Same path → "Turn on PowerShell Transcription" → Enabled. Output directory: a write-once-only path the local user cannot modify (e.g., a network share with append-only permissions).

Layer 4: Over-the-Shoulder Transcription (Constrained Endpoint Logging)

For PowerShell remoting (PSRemoting / WinRM), enables transcription of the remote session at the endpoint. Captures lateral movement that doesn't touch the local console.

PowerShell 5.1 (Windows-built-in) supports all four logging layers. PowerShell 7+ (cross-platform, separate install) requires explicit configuration to honor the same Group Policy settings. Many environments have PowerShell 7 installed alongside but unconfigured — attackers can downgrade to PowerShell 2.0 (still present on many systems) or call PowerShell 7 directly to bypass logging.

Mitigations:

• Remove PowerShell 2.0 entirely (deprecated, no security benefit, common attacker downgrade target)
• Configure PowerShell 7 logging policies explicitly
• Block direct invocation of pwsh.exe outside approved paths via PAM application allowlisting

With Module + Script Block logging enabled and forwarded to your SIEM (Microsoft Sentinel — see our Sentinel deployment guide — or third-party), the following detection rules consistently catch real-world malicious activity:

• Encoded commands — powershell.exe -EncodedCommand usage outside known administrative scripts. Attackers Base64-encode payloads to hide intent from naive log review
• Suspicious .NET reflection — script blocks containing System.Reflection, Add-Type, or [Reflection.Assembly] in user-context PowerShell
• Credential extraction tools — script blocks matching Mimikatz signatures, including obfuscated variants
• WMI persistence — script blocks containing Register-WmiEvent or New-CimInstance with subscription
• Empire / Cobalt Strike Aggressor patterns — script blocks matching known C2 framework signatures
• DownloadString from non-approved domains — Invoke-WebRequest or Net.WebClient.DownloadString targeting non-Microsoft / non-approved CDNs
• Disable Defender — script blocks containing Set-MpPreference -DisableRealtimeMonitoring
• Bypass policy — -ExecutionPolicy Bypass usage outside known administrative scripts

Constrained Language Mode is the PowerShell equivalent of "default deny" — it restricts PowerShell to a safe subset of language features (no .NET reflection, no COM object creation, no Add-Type compilation). Attackers cannot run most offensive PowerShell tooling under CLM because the underlying primitives are blocked.

CLM is enforced via two paths:

• AppLocker / Windows Defender Application Control — PowerShell drops to CLM when the script runs from a non-allowlisted location. Native to Windows; requires Application Control to be configured.
• PAM with PowerShell-aware policy — a PAM platform with application allowlisting can enforce CLM for any PowerShell invocation outside approved administrative scripts (see our PAM tools comparison).

For Texas SMBs that have deployed PAM, layering CLM enforcement on top is a meaningful additional barrier against PowerShell-based attacks at minimal operational cost.

• Log volume. Script Block Logging on a busy file server can generate gigabytes of logs daily. Filter aggressively at the SIEM ingestion layer; retain raw logs separately for forensics
• Sensitive data in logs. PowerShell scripts often contain credentials, API keys, and PHI/PII. Restrict access to PowerShell logs as if they contained the most sensitive data your organization handles
• Breaking legitimate automation. CLM breaks many legitimate management scripts. Maintain an allowlist for known-good scripts that need full language mode
• Forgetting Linux/macOS PowerShell. PowerShell 7 runs cross-platform; Linux and macOS endpoints need the same logging configuration if PowerShell is in use

For Texas IT teams without comprehensive PowerShell logging: enable Module Logging + Script Block Logging via Group Policy in your standard endpoint baseline. The configuration takes 30 minutes; the visibility improvement is dramatic. Then forward Event ID 4103 + 4104 to your SIEM and enable the encoded-commands detection rule. Iterate on additional detection rules as your environment normalizes.

Related reading: Active Directory tiering, ITDR for Texas SMBs, cybersecurity services.

• Houston cybersecurity
• The Woodlands cybersecurity
• Sugar Land cybersecurity
• Austin cybersecurity