Defending Against PowerShell Attacks

PowerShell Team

[Updated Feb 20th, 2020 with latest guidance]

The security industry is ablaze with news about how PowerShell is being used by both commodity malware and attackers alike. Surely there’s got to be a way to defend yourself against these attacks!

There absolutely is. PowerShell is – by far – the most securable and security-transparent shell, scripting language, or programming language available.

Our recommendations are:

1. Deploy PowerShell v5.1 (or newer), built into Windows 10. Alternatively, you can deploy the Windows Management Framework, available down to and including Windows 7 / Windows Server 2008r2.
2. Enable, and collect PowerShell logs, optionally including Protected Event Logging. Incorporate these logs into your signatures, hunting, and incident response workflows.
3. Implement Just Enough Administration on high-value systems to eliminate or reduce unconstrained administrative access to those systems.
4. Deploy Device Guard / Application Control policies to allow pre-approved administrative tasks to use the full capability of the PowerShell language, while limiting interactive and unapproved use to a limited subset of the PowerShell language.
5. Deploy Windows 10 to give your antivirus provider full access to all content (including content generated or de-obfuscated at runtime) processed by Windows Scripting Hosts including PowerShell.

Some security professionals recommend disabling PowerShell as a method of risk mitigation. Microsoft’s guidance on this falls into two areas:

1. Client systems. After initial infection (by a macro-enabled document or user double-clicking a malicious executable), malware sometimes uses PowerShell as one component of its attack chain. Microsoft’s recommendation is not to block PowerShell completely, as PowerShell is required for many operating system and system management tasks. Microsoft’s recommendation is to limit PowerShell to authorized users and administrators to mitigate the use by commodity malware, as described by point #4 above (“Deploy Device Guard / Application Control Policies”). If Windows Defender Application Control is not an option, security products that block PowerShell from unknown parent processes (such as Word, Excel) are a reasonable middle ground.
2. Server systems. Microsoft does not recommend blocking PowerShell on server systems. PowerShell is the most secure remote management technology, and disabling PowerShell exposes the server to significant risks of credential theft enabled by other remote management technologies (such as Remote Desktop). PowerShell is also the primary management technology for server systems, so blocking PowerShell completely causes an unacceptable administrative burden using tools with little to no security transparency. Additionally, malicious post-exploitation use of PowerShell on a server system is primarily associated with an active adversary, rather than the static approach used by commodity malware on client systems. Without Application Control (as described by point #4 above), active adversaries simply use other scripting languages or custom tooling.

For further information about these steps and solutions, please see the much more detailed presentation: “Defending Against PowerShell Attacks“.

You can also download the slide deck used for this video: Defending-Against-PowerShell-Attacks.

For further details about PowerShell’s Security features, please see our post: PowerShell ♥ the Blue Team. For further details about implementing Just Enough Administration, please see http://aka.ms/jeadocs.

Lee Holmes [MSFT] Lead Security Architect Azure Management

PowerShell Team PowerShell Team, PowerShell

Follow