What Do the New Security Guidelines for PowerShell Mean for You?

Cybersecurity agencies in the US, UK, and New Zealand have issued new recommendations for securing Windows PowerShell. Let’s see how different these guidelines are from existing CIS and STIG benchmarks, and how you can put them to action. 

To reduce cybercrime risk, the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), the New Zealand National Cyber Security Centre (NZ NCSC), and the United Kingdom National Cyber Security Centre (NCSC-UK) created a new set of recommendations for using and configuring PowerShell.

PowerShell is the scripting language and command line tool that is included with Microsoft Windows. The latest versions are also available for Linux distributions. This powerful utility helps administrators automate common tasks. Due to its capabilities, many cyber intrusions, like ransomware, have used PowerShell as a post-exploitation tool (a means of manipulating a system once it’s hacked) to attack Windows.

These are the international team’s recommendations, grouped into three categories:

PowerShell methods to reduce abuse

• Credential protection during PowerShell remoting
• Network protection of PowerShell remoting
• Antimalware Scan Interface (AMSI) integration
• Constrained PowerShell with Application Control

PowerShell methods to detect abuse

• Deep Script Block Logging (DSBL) and module logging
• Over-the-Shoulder (OTS) transcription

PowerShell procedures to provide authentication

• Remoting over SSH

Most of the guidelines are familiar but the list does include one big surprise (which I’ll get to). The recommendations are strong but it’s disappointing that they don’t actually describe how best to configure PowerShell. They leave a lot to the reader to self-study and interpret. 

To help, I’ll compare the new recommendations with existing CIS and STIG compliance benchmarks, highlight the differences, and translate principles into action.

Remove PowerShell Version 2

The guideline recommends uninstalling PowerShell Version 2 to prevent attackers from using the outdated version. CIS Windows benchmarks do not include this check, while STIG Windows does. 

➢ It’s worth noting that PowerShell Version 2 has been deprecated since 2017. I hope you’re not still using it—newer versions are also way more fun to work with. 

To quickly check for this vulnerability, open PowerShell and run:

Get-WindowsFeature | Where Name -eq PowerShell-v2

Or use Mondoo Shell:

windows.feature("PowerShell-V2").installed == false:

Antimalware Scan Interface (AMSI)

Although neither CIS Windows nor STIG Windows benchmarks validate that AMSI is active, this is an important security check; malware often tries to disable or bypass AMSI. It’s a per-user setting that you can quickly verify: Open the Windows Registry Editor and, for each user,  ensure that the value for AmsiEnable is set to 0:

HKEY_USERS\${SID}\Software\Microsoft\Windows 
Script\Settings\AmsiEnable

Mondoo allows you to quickly verify that AMSI is enabled for all users by querying:

users.where(sid == /^S-1-5-21-[0-9]+-[0-9]+-[0-9]+-[0-9]{3,}$/ && enabled == 
true).list {
  registrykey.property(path: 'HKEY_USERS\' + sid + 
'\Software\Microsoft\Windows Script\Settings', name: 'AmsiEnable') {
  value != 0
  }
}

Configure Windows Application Control (WDAC or AppLocker)

While STIG Windows benchmarks recommend setting up AppLocker, CIS Windows guidelines do not require AppLocker or Windows Defender Application Control (WDAC, previously called DeviceGuard) configuration. 

WDAC policies apply to the whole computer and therefore affect all users. WDAC rules can be defined based on:

•  Code signing certificates, which are used to sign an application, its binaries, or PowerShell scripts
• Attributes from the binaries’ metadata
• The process that initiated the installation or launched the application
• And more

The initial setup up of AppLocker and WDAC is very easy, but a complete and correct configuration requires careful configuration and a lot of testing before being rolled out across your whole fleet. We recommend AppLocker only for environments that need full lockdown.

Constrained PowerShell with Application Control

Neither CIS nor STIG Windows benchmarks verify for Constrained Language Mode (CLM) in PowerShell. CLM mode ships with a lot of restrictions for PowerShell scripts, which makes it an expensive task to validate that all your existing scripts are compatible. If you code-sign all your PowerShell scripts, you can configure AppLocker to allow your signed scripts. In order to prevent attackers from circumventing the Windows application control policies, you must ensure that PowerShell Version 2 is uninstalled, since WDAC only supports Windows PowerShell version 5.1. 

While this recommended configuration makes the system more secure, we find it a rather impractical approach for a few reasons:

• It puts the burden on the administrator to ensure everything keeps working. 
• It severely limits end users’ capabilities.
• Errors in setup and configuration are common..

We can only recommend this approach for environments that truly require this level of protection. To learn more about CLM and the configuration with AppLocker, read Increase PowerShell security with help from AppLocker on TechTarget.

Install SSH on Windows

Here’s the surprise! Recommending SSH for Windows is a big and positive shock for me because SSH is not required by either STIG Windows or CIS Windows benchmarks.

I love SSH for Windows and fully recommend it. By default, it’s way more secure. And I’ve seen very few people set up HTTPS for WinRM properly. Therefore the move to SSH will probably make secure transfer easier.

Ansible added experimental support for SSH in version 2.8. The additional benefit is that you can now reach Windows from Linux and macOS as well:

Start making these positive changes now

The new international cybersecurity guideline provides a very strong baseline to secure your PowerShell environment. Wise IT teams will implement most of the recommendations right away. However, PowerShell CLM and AppLocker require more preparation and need to be carefully rolled out. I strongly recommend trying SSH for Windows, since we at Mondoo have had only great experiences so far.

Mondoo is here to help you follow these recommendations and many more important security practices. We released an NSA PowerShell policy that automatically assesses the state for each individual control and provides a quick overview of your PowerShell security posture.

With Mondoo, you can also quickly assess your Windows Machine via SSH in minutes. Get a glimpse of our NSA PowerShell policy in action below: