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
PowerShell methods to detect abuse
PowerShell procedures to provide authentication
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.
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:
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
}
}
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:
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.
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:
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.
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:
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: