PowerShell Security for Enterprises in 2026: The Configuration Every Windows Shop Needs

# PowerShell security for enterprises in 2026: the configuration every Windows shop needs

Name the last Windows-targeted breach that didn't use PowerShell.

Go ahead, try. Scattered Spider uses it. LockBit uses it. Volt Typhoon uses it. Every Cobalt Strike loader since 2016 uses it. Every "living-off-the-land" campaign you've read about in the last five years opened with powershell.exe at some point in the kill chain.

The reason is simple. PowerShell is pre-installed on every Windows box. It's signed by Microsoft so endpoint protection treats it as trusted. It's allowed to run by default. And it can do everything from network reconnaissance to in-memory payload execution without ever writing a file to disk.

You can't disable it. IT needs it. The real defense is configuring PowerShell so attacker usage gets constrained and logged while your admins keep working. Microsoft publishes the guidance. Most enterprises implement it incompletely. This post is the 2026 enterprise PowerShell configuration we check on every Windows audit.

#What PowerShell gives attackers

I've been running engagements on this for a few years now. The shortcut you'd expect to exist doesn't.

Raw capabilities PowerShell brings that make it the attacker's preferred tool:

• In-memory execution. Invoke-Expression, Invoke-Command, [System.Reflection.Assembly]::Load all allow running code without writing to disk
• Native Windows API access via [DllImport] and reflection. No need to drop an EXE
• Remoting via WinRM. Execute on remote machines with valid credentials
• Full Active Directory, Exchange, Intune, Azure automation via built-in modules
• Obfuscation. Encoded commands, base64, string replacement, variable substitution, AST manipulation
• AMSI bypass techniques (mostly patched but new ones surface)
• Credential theft via Get-Credential prompts, Mimikatz loaded in-memory, COM object abuse

The same capabilities make it invaluable for administrators. The defense isn't to disable but to observe.

#The enterprise configuration

#1. Upgrade to PowerShell 5.1 (or 7.x) tenant-wide

PowerShell 2.0 has no meaningful logging and should be disabled. On Windows 10/11 and Server 2019+, PowerShell 2.0 is an optional component. Disable it via Group Policy:

Computer Configuration > Administrative Templates > Windows Components >
Turn on Windows PowerShell 2.0 → Disabled

Or via DISM:

DISM /Online /Disable-Feature:MicrosoftWindowsPowerShellV2

Attackers sometimes deliberately invoke powershell.exe -version 2 to downgrade to the un-logged version. Disabling V2 blocks this.

PowerShell 7.x is cross-platform and has improved logging. Worth deploying for administration. Most automation can target 5.1 for compatibility.

#2. Enable Module Logging

Module Logging records every command invocation from specified PowerShell modules. Configure:

Computer Configuration > Administrative Templates > Windows Components >
Windows PowerShell > Turn on Module Logging → Enabled
Module Names → *

The wildcard logs all modules. This produces significant log volume but catches obfuscated commands once they resolve to module calls.

#3. Enable Script Block Logging

Script Block Logging captures the full content of executed PowerShell code after decoding. This is the single most valuable PowerShell logging feature. It sees the deobfuscated script content.

Computer Configuration > Administrative Templates > Windows Components >
Windows PowerShell > Turn on PowerShell Script Block Logging → Enabled
Log script block invocation start / stop events → Enabled (optional, verbose)

Script block events land in Microsoft-Windows-PowerShell/Operational event log, event IDs 4104 (execution) and 4103 (module).

#4. Enable PowerShell Transcription

Transcription writes to a text file capturing every PowerShell session:

Computer Configuration > Administrative Templates > Windows Components >
Windows PowerShell > Turn on PowerShell Transcription → Enabled
Transcript output directory → \\\\logserver\\transcripts$\\%COMPUTERNAME%
Include invocation headers → Enabled

The output directory should be a network location the user can't modify, so adversaries can't tamper with the log.

Transcription captures everything including command output. Useful for forensics. High volume.

#5. Configure Constrained Language Mode for non-admins

Constrained Language Mode (CLM) restricts what PowerShell scripts can do. Script signing, AppLocker, and Windows Defender Application Control (WDAC) work together to enforce CLM.

Effect: non-admin users can't use PowerShell to load arbitrary.NET assemblies, invoke Win32 APIs directly, or abuse COM objects. Scripts signed by approved publishers still run in Full Language Mode.

Deployment: via WDAC / AppLocker policies. This is invasive. Test thoroughly before production rollout. It breaks many legitimate admin scripts that rely on advanced PowerShell features.

#6. Restrict PowerShell Remoting

WinRM (PowerShell Remoting) is a frequent attack path. Controls:

• Disable PowerShell Remoting on workstations (only servers should accept remote sessions)
• Use Just Enough Administration (JEA) for constrained remote execution. Users get a limited command set than full shell access
• Require Kerberos authentication (not NTLM) for remoting
• Log remoting via both source and destination machines

#7. Enable AMSI (Antimalware Scan Interface)

AMSI exposes PowerShell script content to whatever antimalware engine is installed (Defender, CrowdStrike, SentinelOne). The engine scans before execution.

AMSI is on by default in modern Windows, but:

• Ensure EDR is consuming AMSI events (Defender does by default. Third-party varies)
• Enable AMSI Providers for advanced PowerShell in Windows 10 20H2+

Attackers routinely bypass AMSI. The bypass techniques are patched but new ones emerge. Still, AMSI catches the large majority of commodity scripts (Empire, Meterpreter, most off-the-shelf tools).

#8. Integrate logs into SIEM

Script block logs are useless if no one reads them. Forward the Microsoft-Windows-PowerShell/Operational log to your SIEM:

• Splunk: Universal Forwarder with Windows_Inputs add-on
• Sentinel: Log Analytics agent or Azure Monitor Agent
• Elastic: Winlogbeat
• Sumo Logic: Windows Event Log Source
• Chronicle: Forwarder

Retention: 90+ days for script block logs. Storage cost matters at scale. Balance against investigation value.

#Detection rules that catch real attacks

SIEM detection rules that repeatedly hit on incidents:

#Rule 1: Encoded commands

PowerShell accepts -EncodedCommand . Attackers use this to avoid command-line argument detection.

# Splunk SPL (example)
source="WinEventLog:Microsoft-Windows-PowerShell/Operational" EventCode=4104
| where match(ScriptBlockText, "(?i)-enc(odedcommand)?\\\\s+[A-Za-z0-9+/=]{20,}")

Legitimate use of -EncodedCommand is rare. Benign uses exist (Intune / SCCM deploy scripts). Whitelist known-good encoded strings and alert on unknown.

#Rule 2: Download cradles

IEX (New-Object Net.WebClient).DownloadString('http://...') is the classic download-and-execute pattern. Variants include Invoke-WebRequest | Invoke-Expression, [ScriptBlock]::Create(...), Invoke-RestMethod.

# Look for network download chained with execution
where ScriptBlockText matches "(?i)(IEX|Invoke-Expression|\\\\.Create\\\\().*?(Net\\\\.WebClient|Invoke-WebRequest|iwr|Invoke-RestMethod|irm)"

#Rule 3: AMSI bypass attempts

Known AMSI bypass strings. List is public and updated. Some specific patterns:

• System.Management.Automation.AmsiUtils
• amsiInitFailed
• [Ref].Assembly.GetType
• Base64 encoded variants of the above

#Rule 4: Suspicious cmdlet combinations

Mimikatz-style credential theft:

• Invoke-Mimikatz
• sekurlsa::logonpasswords
• Get-Wmi...Win32_OperatingSystem + Win32_ShadowCopy
• Reading LSASS memory: MiniDump or OpenProcess on lsass

BloodHound collection:

• SharpHound, Invoke-BloodHound
• Rapid LDAP queries enumerating all users / groups

AD attack techniques:

• Get-ADUser with SPN filter (Kerberoasting prep)
• Add-ADGroupMember -Identity 'Domain Admins'
• Set-ADAccountPassword on privileged accounts

#Rule 5: PowerShell from unusual parent processes

PowerShell spawned by:

• winword.exe, excel.exe, outlook.exe → document macro execution
• w3wp.exe → web shell on IIS
• java.exe, node.exe → application compromise
• explorer.exe via Run dialog on kiosk or service accounts → interactive compromise

EDR telemetry catches this; SIEM rules on process tree can too.

#Rule 6: PowerShell with suspended execution policy

where ScriptBlockText matches "(?i)(Set-ExecutionPolicy|-ExecutionPolicy)\\\\s+Bypass"

Legitimate use exists (IT scripts) but combined with other indicators points to attack.

#What we assess in a PowerShell audit

Our PowerShell hygiene review covers:

1. PowerShell versions installed across the environment (v2 eradication)
2. Module Logging and Script Block Logging enablement per GPO
3. Transcription configuration and log retention
4. AMSI functionality validation (test against known payloads)
5. AppLocker / WDAC policy review for Constrained Language Mode
6. PowerShell Remoting configuration (who, from where, to what)
7. JEA role configuration (if deployed)
8. SIEM integration and detection rule coverage
9. Historic PowerShell log review for indicators of past compromise
10. Attack simulation. We run representative adversary tradecraft and verify detection fires

Typical engagement: 2-3 weeks for a 500-2000 endpoint environment.

#The bigger picture

PowerShell security is one component of endpoint security hygiene. Related controls that matter alongside it:

• EDR deployment on every endpoint. AMSI is a supplement, not a replacement
• Application allowlisting (AppLocker, WDAC) for production servers
• Constrained admin practices per Active Directory tier model
• Just-in-time elevation via PIM or Privileged Access Management
• Microsoft Defender for Identity (formerly Azure ATP) for AD attack detection
• Microsoft Defender for Endpoint with attack surface reduction rules enabled

None of these replace PowerShell hardening. All of them multiply its value.

#Resources

• Microsoft PowerShell security documentation: https://learn.microsoft.com/en-us/powershell/scripting/security
• Daniel Bohannon's Revoke-Obfuscation research
• SpecterOps research on PowerShell attack patterns
• MITRE ATT&CK T1059.001 (PowerShell) technique documentation
• Sigma rules repository (SOC Prime, Florian Roth) for portable detection rules
• Windows Security Baselines (via Microsoft Security Compliance Toolkit)

#Hire Valtik Studios

PowerShell hygiene audits are part of our standard endpoint security reviews. If you run Windows infrastructure at any meaningful scale, this is low-effort-high-value work. Gaps in PowerShell logging are gaps in detection coverage. Most enterprises have 50-70% of what they need but miss the specific configurations that matter most.

Reach us at valtikstudios.com.