Cybersecurity agencies: You don’t have to delete PowerShell to secure it

Microsoft’s PowerShell is a useful, flexible tool that is as popular with criminals as it is with admins. Cybercrooks like it becasue PowerShell is powerful, available almost everywhere, and doesn’t look out of place running on a company network.

In most places it isn’t practical to block PowerShell completely, which raises the question: How do you stop the bad stuff without disrupting the good stuff?

Cybersecurity authorities from the United States, New Zealand, and the United Kingdom have released a joint Cybersecurity Information Sheet (CIS) on PowerShell that attempts to answer that question.

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) hope that “these recommendations will help defenders detect and prevent abuse by threat actors, while enabling legitimate use by administrators and defenders.”

PowerShell

Although it’s closely associated with the world of Windows administration, PowerShell is a cross-platform (Windows, Linux, and macOS) automation and configuration tool which, by design, is optimized for dealing with structured data. Initially a Windows component only, known as Windows PowerShell, it was made open-source and cross-platform on 18 August 2016 with the introduction of PowerShell Core.

It allows system administrators and power users to perform administrative tasks via a command line—an area where Windows previously lagged behind its Unix-like rivals with their proliferation of *sh shells.

Threat actors are equally fond of it because it allows them to “live off the land”, and for the options it provides to create fileless malware or to gain persistence on a compromised system.

Reduce abuse

The CIS discusses some security features available in PowerShell which can reduce abuse by threat actors.

Remote connections

Remote connections can be used for powerful remote management capabilities, so Windows Firewall rules on endpoints should be configured appropriately to control permitted connections. Access to endpoints with PowerShell remoting requires the requesting user account to have administrative privileges at the destination by default. The permission requirement and Windows Firewall rules are customizable for restricting connections to only trusted endpoints and networks to reduce lateral movement opportunities. Organizations can implement these rules to harden network security where feasible.

Multiple authentication methods in PowerShell permit use on non-Windows devices. PowerShell 7 permits remote connections over Secure Shell (SSH) in addition to supporting Windows Remote Management (WinRM) connections. This allows for public key authentication and makes remote management through PowerShell of machines more convenient and secure.

AMSI integration

The Antimalware Scan Interface (AMSI) feature, first available on Windows 10, is integrated into different Windows components. It supports scanning of in-memory and dynamic file contents using an anti-malware product registered with Windows and exposes an interface for applications to scan potentially malicious content. This feature requires AMSI-aware anti-malware products (such as Malwarebytes). Basically, AMSI works by analyzing scripts before the execution, so the anti-malware product can determine if the script is malicious or not.

Constrained Language Mode

Configuring AppLocker or Windows Defender Application Control (WDAC) to block actions on a Windows host will cause PowerShell to operate in Constrained Language Mode (CLM), restricting PowerShell operations unless allowed by administrator-defined policies.

PowerShell methods to detect abuse

Logging of PowerShell activities can record when cyber threats use PowerShell, and continuous monitoring of PowerShell logs can detect and alert on potential abuses. Deep Script Block Logging, Module Logging, and Over-the-Shoulder transcription are disabled by default. The authors recommend enabling the capabilities where feasible.

Before you start

If you plan on following the advice in the CIS, there are a few things you may want to consider first.

• Execution Policies do not restrict execution of all PowerShell content.
• AMSI bypasses are found and remediated in a constant whack-a-mole game, and most anti-malware products have different ways of accomplishing the same, or better, results. Therefor you will find that most AMSI-aware anti-malware products do not rely on AMSI alone.
• If you are a customer of a Managed Service Provider (MSP) you may need to contact them before taking any of the actions listed above, since doing so may hinder them in their remote management.
• Windows Remote Management/Remote Shell (WinRM/WinRS) connection limitations can become an obstacle in organizations with numerous administrators performing remote management, or that have multiple monitoring solutions connecting to the environment. By default, Microsoft Server limits the number of concurrent users connected to the WinRM/WinRS session to five and the number of shells per user to five. This can, and has often been modified by using an elevated command prompt.

Disabling PowerShell, if you do not need it, is a lot easier and safer than applying policies to make it safer to use. But looking at the options to make it more secure is certainly a good idea if you do need it.

Stay safe, everyone!