PowerShell Security Hardening: Stop Attackers From Using Your Own Tools

PowerShell is the most powerful tool in a Windows administrator's arsenal — and for exactly that reason, it's also a favorite tool for attackers. Living-off-the-land attacks that abuse built-in system tools have surpassed traditional malware as the primary attack technique, and PowerShell sits at the center of nearly every such attack chain. The challenge for MSPs is hardening PowerShell without crippling the administrative capabilities your technicians depend on daily.

Constrained Language Mode and AppLocker

The most effective PowerShell hardening measure is Constrained Language Mode, which restricts access to sensitive .NET types, COM objects, and other powerful language features that attackers exploit. When combined with AppLocker or Windows Defender Application Control policies, you can allow your management scripts to run in Full Language Mode (because they're signed or in trusted paths) while forcing all other PowerShell execution into the constrained mode. This means your RMM scripts work normally, but an attacker who gains a PowerShell session gets a severely limited environment.

Logging and Monitoring

Enable PowerShell Script Block Logging, Module Logging, and Transcription across all managed endpoints. These logs capture the actual code being executed, including deobfuscated versions of encoded commands — which is invaluable for forensics and detection. Forward these logs to your SIEM and create detection rules for suspicious patterns: encoded commands, download cradles, AMSI bypass attempts, and execution of scripts from unusual directories. The combination of constrained execution and comprehensive logging gives you defense in depth: limit what attackers can do, and ensure you see everything they attempt.