PowerShell Logging and Detection for Texas IT Teams

Living-off-the-land is the dominant intrusion style in 2026, and PowerShell is the flagship of the technique. Instead of dropping a custom malware binary that endpoint protection might flag, an attacker abuses a signed, whitelisted Microsoft interpreter that is already present and already trusted. The appeal is obvious:

• It is everywhere. Every supported Windows client and server has PowerShell installed.
• It is trusted. The executable is signed by Microsoft, so application-allowlisting tools wave it through.
• It is fileless. Commands can be Base64-encoded, piped in from memory, or pulled from a remote URL, leaving little forensic residue on disk.
• It reaches everything. From Active Directory to Microsoft 365 to local WMI, PowerShell can touch the entire environment.

That same reach is exactly why disciplined logging matters. The goal is not to block PowerShell -- your own admins depend on it -- but to record enough detail that malicious use stands out from legitimate use.

Windows offers three distinct PowerShell logging capabilities, and each answers a different question. Turn on all three; they complement rather than replace one another.

Module Logging

Module logging records pipeline execution events -- which cmdlets ran and with what parameters. It writes Event ID 4103 to the Microsoft-Windows-PowerShell/Operational log. It is the lightest of the three and gives you a coarse activity trail, but on its own it can miss the obfuscated substance of what a script actually did.

Script Block Logging

Script block logging is the single most valuable setting. It captures the full, de-obfuscated text of every script block PowerShell compiles, logged as Event ID 4104. Because the engine records the code after it has been decoded, Base64 and string-concatenation tricks are unwound for you -- you see the real intent. Enable it via Group Policy under Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging. This is the log that turns a fileless attack into a readable transcript.

Transcription

Over-the-shoulder transcription writes a plain-text record of everything typed and returned in a session to a file. Point it at a protected, write-only network share so an attacker on the endpoint cannot simply delete the evidence. Transcripts are gold during incident response because they capture output, not just input.

All of the logging above lives in modern PowerShell. The legacy Windows PowerShell 2.0 engine predates script block logging entirely, and attackers deliberately invoke it with powershell.exe -version 2 to downgrade around your visibility. If the v2 engine is still installed, your careful logging has a trapdoor under it. Remove the optional feature everywhere, and alert on any process that requests version 2 -- there is almost never a legitimate reason for it in a 2026 environment.

Local logs protect nothing if the machine they live on is compromised. The first thing a competent intruder does is clear event logs. Centralize aggressively:

• Windows Event Forwarding (WEF) is the free, built-in path -- endpoints push events to a collector you control.
• A SIEM such as Microsoft Sentinel gives you correlation, retention, and alerting across the fleet. We cover a right-sized rollout in our guide to Microsoft Sentinel deployment at SMB scale.
• Tamper-resistant retention matters for compliance. Frameworks that Texas businesses face -- from PCI DSS to CMMC -- expect audit logs to survive the very incident they document.

Log forwarding should be one of the first things a managed IT services provider stands up, because it is the foundation every later detection depends on.

Once the logs are flowing, you need to know what to hunt for. High-signal indicators in Event ID 4104 include:

• Encoded commands: the -EncodedCommand or -enc flag carrying a Base64 blob is a classic obfuscation tell.
• Hidden and non-interactive execution: -WindowStyle Hidden, -NonInteractive, and -ExecutionPolicy Bypass together signal automation meant to stay unseen.
• In-memory download cradles: IEX (New-Object Net.WebClient).DownloadString(...) and Invoke-WebRequest piped straight into execution.
• Credential and AD reconnaissance: bursts of Get-ADUser, Get-ADComputer, or calls into Mimikatz-style functions.
• Version downgrades: any -version 2 request, as noted above.

None of these is malicious in isolation -- your backup scripts and onboarding automation use some of them daily. Detection is about context: an encoded, hidden command spawned by a Word document at 2 a.m. from a user who never scripts is a very different event from your scheduled maintenance job.

Detection tells you what happened; hardening reduces what can happen. Two native controls pair well with logging:

• Constrained Language Mode restricts PowerShell to a safe subset of the language, blocking the arbitrary .NET calls that most in-memory attacks depend on. Enforced through application control, it neuters a huge class of tradecraft.
• Just Enough Administration (JEA) gives admins role-limited endpoints so day-to-day tasks never require full, unconstrained shells. This is the same least-privilege principle behind privileged access management and our Active Directory tiering model guidance.

Collecting 4104 events is necessary but not sufficient -- someone has to look. Build a small set of high-confidence detections first, then expand:

• Alert on any use of the v2 engine.
• Alert on encoded commands originating from Office applications or browsers (a strong macro-to-PowerShell signal).
• Alert on download cradles combined with hidden window style.
• Baseline your own admin scripts and suppress them, so the alerts that remain are worth a human's attention.

This tuning loop is exactly the work that continuous attack surface management and a mature insider threat program depend on. PowerShell telemetry also feeds the network-layer picture your NAC deployment and SASE architecture build out.

If you do only one thing this week, enable PowerShell Script Block Logging via Group Policy across every endpoint and confirm the 4104 events are forwarding to a central collector. That single change gives you a de-obfuscated record of code execution on every Windows machine -- the difference between finding out about an intrusion in minutes versus months. From there, remove PowerShell v2, stand up transcription to a protected share, and write your first three detection rules. If your team does not have the bandwidth to build and tune this, a co-managed or fully outsourced IT partner can deploy the whole pipeline in a matter of days.

LayerLogix helps IT and security teams across Texas turn PowerShell from a liability into a detection advantage. We support businesses in Houston, The Woodlands, Austin, Dallas, and San Antonio with logging deployment, SIEM onboarding, and 24/7 automated monitoring. Talk to our team about hardening your Windows fleet.