PowerShell is an incredibly effective tool that allows IT administrators to automate repetitive tasks and is particularly useful in helping to protect and manage the cybersecurity of Windows operating systems.
However, those same capabilities are just as useful for hackers after gaining initial access to a network, with PowerShell scripts being used to weaken intrusion prevention systems, move laterally and maintain persistence. According to cybersecurity researchers, the tool has been used in several notable incidents, including the Kaseya VSA compromise that led to a mass deployment of the REvil ransomware last year.
Several other threat actors have leveraged PowerShell to infect Word and Excel files with malware and spread fileless malware, according to new information provided by the U.S. Cybersecurity and Infrastructure Security Agency and a host of other nations’ cybersecurity agencies.
The new document released gives IT and cybersecurity professionals recommendations on how to secure PowerShell and prevent it from being used against the organization in the event of a cyberattack, rather than simply disabling PowerShell.
Make sure PowerShell is up to date
PowerShell 7.2 is the latest version of the scripting tool, and an earlier version, 5.1, is included with Windows 10+. However, version 7.2 can fully integrate with and access all components created for version 5.1. Agencies recommend disabling and uninstalling the “deprecated second version on Windows 10+,” as newer versions of PowerShell provide enhanced security measures.
PowerShell Remoting security
PowerShell includes built-in security features that enable administrators, analysts and users to remotely execute commands on Windows hosts. The underlying protocol used is Windows Remote Management (WinRM), and Kerberos or New Technology Lan Manager (NTLM) are the default authentication protocols. Those protocols do not send the actual credentials to remote hosts, thus avoiding direct exposure of credentials.
Agencies also advise organizations to configure Windows Firewall rules on endpoints to control permitted connections. The client and server editions of Windows include PowerShell remoting capabilities, but access to endpoints with PowerShell remoting requires the requesting user to have admin privileges at the destination by default. Enabling PowerShell remoting on private networks will introduce a Windows Firewall rule to accept all connections. Those rules can be customized to restrict connections to only trusted endpoints and networks to reduce lateral movement and harden networks.
According to the cybersecurity agencies, PowerShell 7 permits remote connections over Secure Shell in addition to WinRM connections, allowing for public key authentication and convenient and secure remote management. New capabilities can establish remote connections without requiring the use of HTTPS with SSL/TLS certificates. PowerShell over SSH does not require Trusted Hosts as when remoting over WinRM outside of a domain, allowing for secure remote management over SSH without a password for all commands and connections. This also allows for PowerShell remoting between Windows and Linux hosts.
Antimalware Scan Interface (AMSI) integration
The agencies also say the Antimalware Scan Interface feature, integrated into different Windows components, can scan for in-memory and dynamic file contents for malicious content using an anti-virus product registered with Windows. Built-in scripting languages, including PowerShell, use AMSI so that scripts are scanned by registered and supported anti-virus software.
Limiting PowerShell’s capabilities
Using AppLocker or Windows Defender Application Control, admins can block certain actions on a Windows host and cause PowerShell to operate in Constrained Language Mode, restricting PowerShell operations unless allowed by administrator defined policies, according to the agencies. This corrects an AppLocker script enforcement flaw that blocks PowerShell commands in a script but allows them interactively entered into the PowerShell command console. A proper configuration can prevent a malicious actor from gaining full control over a PowerShell session.
Detecting abuse
Organizations should maintain logs and monitor PowerShell activities to detect when malicious actors are leveraging the tool. However, deep script block logging, module logging and over-the-shoulder transcription are all disabled by default. The agencies recommend enabling those capabilities where feasible.
Deep script block logging records each PowerShell command in the Windows Event Log, while module logging captures the pipeline execution details of PowerShell. Meanwhile, over-the-shoulder transcription records every PowerShell input and output, whether functional or not, to help defenders decipher intended actions.
Don’t block PowerShell
Some organizations have taken to blocking PowerShell altogether to prevent malicious actors from utilizing the tool, but the agencies warn against that tactic, as it can hinder defensive capabilities that current versions of PowerShell provide.
Leave a Reply