Windows’ PowerShell scripting utility has been abused by threat actors for decades. But cyber intelligence agencies from the U.S, the United Kingdom, and New Zealand say disabling the capability isn’t the solution.
Instead, they say in a report issued Wednesday, proper configuration and monitoring will allow reducing the likelihood of malicious actors using it undetected after gaining access to a victim’s network.
“Blocking PowerShell hinders defensive capabilities that current versions of PowerShell can provide,” says the advisory “and prevents components of the Windows operating system from running properly. Recent versions of PowerShell with improved capabilities and options can assist defenders in countering abuse of PowerShell.”
Window admins should start with installing PowerShell 7.2 if they haven’t already done so. In Windows 10+, with proper configuration, version 7.2 can fully integrate with and access all components created for version 5.1 (which comes in earlier versions of Windows 10 and Win11), allowing for continued use of existing scripts, modules, and commands.
The report urges admins to take advantage of these PowerShell capabilities:
–if remote access is allowed, use Windows Remote Management (WinRM). It uses Kerberos or New Technology LAN Manager (NTLM) as the default authentication protocols. These authentication protocols do not send the actual credentials to remote hosts, avoiding direct exposure of credentials and risk of theft through revealed credentials.
PowerShell 7 permits remote connections over Secure Shell (SSH) in addition to supporting WinRM connections. This allows for public key authentication and makes remote management of machines through PowerShell convenient and secure, the report adds. New SSH remoting capabilities in PowerShell can establish remote connections without requiring the use of Hypertext Transfer Protocol Secure (HTTPS) with Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates;
–Windows Firewall rules on endpoints should be configured appropriately to control permitted connections. Enabling PowerShell remoting on private networks will introduce a Windows Firewall rule to accept all connections. The permission requirement and Windows Firewall rules are customizable for restricting connections to only trusted endpoints and networks to reduce lateral movement opportunities;
–enable the Antimalware Scan Interface (AMSI), which allows scanning of in-memory and dynamic file contents using an approved anti-virus product such as Windows Defender, McAfee (now Trellix), and Symantec;
–configure AppLocker or Windows Defender Application Control (WDAC) to block actions on a Windows host. That will cause PowerShell to operate in Constrained Language Mode (CLM), restricting PowerShell operations unless allowed by administrator-defined policies;
The report also notes that logging PowerShell activities can record when cyber threats leverage PowerShell, and continuous monitoring of PowerShell logs can detect and alert about potential abuses. Unfortunately, Deep Script Block Logging, Module Logging, and Over-the-Shoulder transcription are disabled by default. The report recommends enabling the capabilities where feasible.
There are lots of other sources of information on securing PowerShell, including advice from the Center for Internet Security and Microsoft.
