Enable Maximum Windows Logging for SOC & Ransomware Detection

This One PowerShell Script Turns Windows Into a DFIR Machine

Picture this: a mid-size manufacturing company gets hit by ransomware on a Tuesday night. By Wednesday morning, the incident response team is called in — and the first thing they ask for is logs. What they find is a Security event log capped at 20 MB, PowerShell logging disabled, no Sysmon, and a Security channel that overwrote itself three times before anyone noticed the breach. The attacker's entire dwell time — the lateral movement, the credential dumping, the C2 beacons — is gone. Not encrypted. Not hidden. Just never recorded in the first place.

This is the single most common failure I see in SOC and DFIR engagements: organizations spend money on SIEM licenses and EDR agents, then feed them a Windows endpoint that was never configured to generate meaningful telemetry. Default Windows logging is built for troubleshooting, not for catching an attacker. If you want to detect PowerShell abuse, lateral movement, credential theft, or ransomware staging, you have to turn the visibility on yourself — and you have to do it before the incident, not during it.

Table of Contents

• What "Maximum Windows Logging" Actually Means
• Why Default Windows Logging Fails SOC Teams
• What This Telemetry Engine Enables
• Commands & Script Walkthrough
• Detection Use Cases Unlocked by Each Log Source
• Hardening Layer: Defender, ASR & AppLocker
• Expert Tips From the Field
• Related Reading
• FAQ
• Conclusion

What "Maximum Windows Logging" Actually Means

Windows ships with dozens of event log channels that are installed but sitting disabled — PowerShell Operational, Sysmon (once installed), AppLocker, AMSI, WMI-Activity, and more. Most admins never touch them because Event Viewer only shows the "classic" four: Application, Security, Setup, and System.

An enterprise telemetry strategy means systematically enabling every relevant operational and admin channel, sizing them so they don't roll over in hours, layering in Sysmon for process-level visibility, and tightening audit policy so the events that matter — logons, privilege use, process creation — are actually captured with the right level of detail.

Why Default Windows Logging Fails SOC Teams

Out of the box, a Windows 10/11 or Windows Server system has three blind spots that attackers exploit constantly:

• No command-line auditing. Event ID 4688 fires on process creation, but without "Include command line in process creation events" enabled via policy, you see that powershell.exe ran — not what it ran.
• PowerShell Script Block Logging is off by default. This is the single biggest gap for detecting fileless malware, obfuscated droppers, and living-off-the-land binaries (LOLBins).
• No Sysmon. Native Windows logging cannot reliably tell you which process made which outbound network connection. Sysmon Event ID 3 fills that exact gap — and it isn't installed by default on any Windows edition.

Layer on tiny default log sizes (often 20 MB for Security), and you get a system that overwrites its own evidence within hours on a busy endpoint — right when an incident responder needs it most.

What This Telemetry Engine Enables

A well-built Windows logging automation script should do more than flip a handful of switches. Here's what a proper enterprise-grade version enables, organized by category:

Category	Channels / Features
Core Windows	Security, System, Application, Setup
PowerShell Forensics	Windows PowerShell, Microsoft-Windows-PowerShell/Admin, Microsoft-Windows-PowerShell/Operational
Process Telemetry	Sysmon/Operational (with a community config)
Lateral Movement	SMBServer/Operational, SMBClient/Operational, TerminalServices (RDP) x3 channels
DNS Visibility	DNS-Client/Operational, DNSServer/Audit, DNSServer/Operational
Application Control	AppLocker (EXE/DLL, MSI/Script, Packaged app x2)
Malware Detection	AMSI Operational, Code Integrity/Operational, Windows Defender/Operational
Kernel & Network	Kernel-General, Kernel-Process, Kernel-File, Kernel-Network, TCPIP/Operational
Persistence Vectors	WMI-Activity/Operational, TaskScheduler/Operational, Bits-Client/Operational

On top of enabling these named channels, a smart script also does a second pass: it enumerates every event channel present on the system via wevtutil el and auto-enables any remaining Operational/Admin channel that isn't a Debug or Trace log. This catches vendor-specific and edition-specific channels you'd otherwise miss on a hardcoded list.

PowerShell Tool Under 100MB

Commands & Script Walkthrough

Here's how the enable logic works under the hood, using safe, idempotent commands.

Step 1: Confirm Administrator Context

$CurrentUser = New-Object Security.Principal.WindowsPrincipal(
    [Security.Principal.WindowsIdentity]::GetCurrent()
)
if (-not $CurrentUser.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Write-Host "Please run PowerShell as Administrator"
    Exit
}

What it does: Verifies the script has elevated privileges before touching any event log configuration. When to use it: At the top of any script that modifies `wevtutil` settings, since non-admin execution silently fails on most channels. Expected output: Script exits immediately with a warning if not elevated.

Step 2: Enable and Size a Log Channel

wevtutil sl "Microsoft-Windows-PowerShell/Operational" /e:true
wevtutil sl "Microsoft-Windows-PowerShell/Operational" /ms:536870912

What it does: Enables the channel (/e:true) and sets its maximum size to 512 MB (/ms: value in bytes). When to use it: On any high-value forensic channel — Security and Sysmon typically get 1 GB, PowerShell/SMB/DNS/RDP/Defender get 512 MB, everything else gets 256 MB as a baseline. Expected output: No console output on success; the channel becomes visible and populated in Event Viewer within seconds.

Step 3: Enable PowerShell Script Block Logging (Registry Method)

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f

What it does: Forces PowerShell to log the full de-obfuscated content of every script block executed, generating Event ID 4104. When to use it: On every endpoint you want visibility into — this is the highest-value single logging change you can make for catching fileless attacks. Expected output: Event ID 4104 entries appear under Microsoft-Windows-PowerShell/Operational on the next script execution.

Step 4: Install Sysmon With a Community Config

Invoke-WebRequest "https://live.sysinternals.com/Sysmon64.exe" -OutFile "$env:TEMP\Sysmon64.exe" -UseBasicParsing
Invoke-WebRequest "https://raw.githubusercontent.com/olafhartong/sysmon-modular/master/sysmonconfig.xml" -OutFile "$env:TEMP\sysmonconfig.xml" -UseBasicParsing
Start-Process "$env:TEMP\Sysmon64.exe" -ArgumentList "-accepteula -i `"$env:TEMP\sysmonconfig.xml`"" -Wait

What it does: Downloads Sysmon directly from Microsoft Sysinternals and installs it with the well-maintained olafhartong/sysmon-modular configuration, which covers process creation, network connections, registry changes, DLL loads, and named pipe activity out of the box. When to use it: On any endpoint that needs process-level and network-level correlation, since native Windows logs can't reliably answer "which process made this connection." Expected output: A new Microsoft-Windows-Sysmon/Operational channel populated with Event IDs 1 (process create), 3 (network connect), 11 (file create), and more.

⚠️ Warning: Never run unattended logging/hardening scripts like this in production without testing in a lab first. Enabling every Operational/Admin channel plus 1 GB Security logs significantly increases disk usage and SIEM ingestion volume. Always validate CPU and storage impact on a representative endpoint before enterprise-wide deployment.

Detection Use Cases Unlocked by Each Log Source

• Event ID 4104 (PowerShell Script Block): Catches encoded/obfuscated PowerShell, Invoke-Expression download cradles, and known offensive frameworks like Cobalt Strike loaders.
• Sysmon Event ID 1 + 4688 correlation: Confirms parent-child process chains — e.g., winword.exe spawning powershell.exe is a classic macro-based initial access indicator.
• Sysmon Event ID 3 (Network Connect): Ties a suspicious process directly to a destination IP and port, giving you a pivot point for network-layer threat hunting.
• SMB Server/Client Operational logs: Surfaces SMB1 usage and file-share enumeration patterns consistent with ransomware propagation across a network.
• AppLocker Audit logs: Even in audit-only mode, these reveal which unsigned or unapproved binaries would have been blocked — invaluable for baselining before enforcement.
• RDP Terminal Services channels: Help reconstruct RDP brute-force attempts and successful remote session hijacking, a top ransomware initial-access vector per multiple industry incident reports.

Hardening Layer: Defender, ASR & AppLocker

Logging tells you what happened. Attack Surface Reduction (ASR) rules try to stop it from happening at all. A solid baseline includes rules that block credential stealing from LSASS, block executable content from email clients and webmail, and block Office applications from creating child processes — all configurable via Add-MpPreference -AttackSurfaceReductionRules_Ids.

Pair this with Defender's cloud-delivered protection, PUA protection, and network protection enabled via Set-MpPreference, and you've closed several of the same gaps attackers rely on when native logging alone would only tell you after the fact.

Expert Tips From the Field

• Always set log retention to non-overwrite (wevtutil sl Security /rt:true) on servers holding domain controller or file server roles — you don't want your most critical evidence source silently rolling over during an active incident.
• Forward every enabled channel to a central collector (Windows Event Forwarding or your SIEM agent) — a log that only exists locally on a compromised host can be tampered with or deleted by the attacker.
• Don't enable everything blindly on low-spec endpoints. Kernel and kernel-network channels in particular can generate significant volume — pilot on a small group first.
• Document a revert plan before deployment. Any script that changes log sizes, audit policy, and service startup types should have a documented (ideally scripted) rollback path for endpoints where the change causes unexpected issues.

Related Cybersecurity Topics You Should Explore

• OpenBin.ai & OpenAPK.ai Review: Free AI Reverse Engineering Tool
  
• Grok Zero-Click Hack Steals Your Chats — No Click Needed
  
• head Command in Linux: Fast Log Triage for SOC Analysts
  
• Elementor Pro Bug Lets Hackers Upload PHP — No Login Needed
  
• tac Command Tutorial: Reverse Logs Fast for Faster Threat Detection
  
• ToxicPanda 2.0: The Android Trojan Now Hacking 349 Banks
  
• Windows 11 24H2 Support Ends Oct 13 — Are You at Risk?
  
• Cat Command in Linux: The SOC Analyst's Secret Weapon
  
• How a Fake VNC Login Turned Into Full Root Access on macOS
  
• reconFTW Tutorial: The Recon Tool That Found My Hidden Bounty
  
• TP-Link Router Flaw Lets Hackers Skip Login Entirely — Here's What's at Risk
  
• This subfinder Fork Cuts Recon Time in Half — subfaster Review
  
• 737 Fake VPN Extensions Are Spying on Chrome Users Right Now
  
• GhostDesk Spyware Alert: Fake CCleaner Steals Passwords & Crypto
  
• Zoomsday Flaw: Hackers Hijack Zoom Users With Zero Clicks

FAQ

Does enabling maximum Windows logging slow down a system?

On modern hardware, the CPU overhead is minimal, but disk I/O and log storage usage increase noticeably. Test on representative endpoints before wide rollout.

Do I need Sysmon if I already collect standard Windows Event Logs?

Yes. Sysmon provides process-to-network correlation and registry/file telemetry that native Windows logging simply doesn't capture with the same fidelity.

Is PowerShell Script Block Logging safe to enable everywhere?

Generally yes — it's one of the highest-value, lowest-risk logging changes available. The main consideration is log volume on very PowerShell-heavy automation servers.

What's the difference between AppLocker audit mode and enforcement mode?

Audit mode logs what would have been blocked without actually blocking it — ideal for baselining before you risk breaking legitimate applications in enforcement mode.

Can these changes be reverted if something breaks?

Yes, but only if you scripted a rollback in advance. Log sizes, audit policies, and service startup types should always be backed up or documented before mass deployment.

Does this replace a SIEM or EDR solution?

No. This maximizes the raw telemetry available on the endpoint. You still need a SIEM, EDR, or log forwarding solution to actually collect, correlate, and alert on that telemetry.

Conclusion

Visibility is the foundation every other SOC capability is built on. You can't hunt threats you never logged, and you can't investigate an incident whose evidence was overwritten before anyone noticed. Enabling enterprise-grade Windows telemetry — PowerShell forensics, Sysmon, AppLocker auditing, and properly sized retention — turns a default, blind endpoint into a system that actually works with your SOC instead of against it.

Have you deployed something similar in your environment? Drop your logging checklist or questions in the comments — and if this helped, share it with a fellow SOC analyst who's still fighting 20 MB Security logs.