Do Not Remove or Disable PowerShell

Bottom Line Up Front (BLUF):

Whenever I hear about removing PowerShell from a Windows environment I think back to the classic animated film The Road to El Dorado when Miguel and the Chief discuss the impending Spanish invasion:

Miguel: Chief, you cannot fight them!
Chief: Then how can we stop them?
Miguel: We can't.

PowerShell is a powerful tool often used by hackers, but the truth is we can't remove it, and we shouldn't try to.

Background

PowerShell is a Microsoft task automation and configuration management solution comprised of a command-line shell, an object-oriented capable scripting language, and the Desired State Configuration (DSC) Framework. The command-line shell is unique as it returns .NET objects, enabling object-oriented programming through the scripting language. DSC is the configuration management solution enabling infrastructure management with configuration as code. With the release of PowerShell 7.2, the PowerShell DSC module is no longer included in the PowerShell package, and is now an independent module.

PowerShell comes in two types: Windows PowerShell and PowerShell. Windows PowerShell is based on the .NET Framework and only runs in Windows. Its latest version is 5.1 and Microsoft is no longer updating it with new features. PowerShell is built on .NET core, which allows it to run on Mac and Linux operating systems (OS). There are many differences between Windows PowerShell and PowerShell, including their cmdlets, modules, and executable names. Windows PowerShell is the version that ships by default in Windows products and henceforth "PowerShell" will refer to Windows PowerShell. PowerShell is most commonly invoked by a user through the powershell.exe executable; however, PowerShell is really a series of dynamic-link libraries (DLL) integral to the OS.

Risks

PowerShell is commonly used by hackers and cybercriminals. Since it is a legitimate program already present on a Windows system, no additional tooling is necessary to exploit PowerShell vulnerabilities. As an interpreted language, PowerShell functions as both a scripting and object-oriented programming language. PowerShell's control over filesystems and the Windows Registry, and its ability to send trusted commands through a network, makes it an extremely powerful tool and a prime target for threat actors.

Research from Splunk demonstrated that among adversaries that breached a system, hackers started the PowerShell command-line shell 28.63% of the time in 2020, 40.8% of the time in 2021, and 29.4% of the time in 2022 (Fetterman, 2022). The most common malicious actions involving PowerShell are communicating with C2 servers, extracting login credentials from servers, moving laterally within a network, executing fileless malware, and modifying or deleting files and registry keys (Reed, 2023).

While PowerShell is commonly invoked during an attack, it is rarely used during the exploitation phase. Lee Holmes, the former Lead Security Architect for Azure Management and one of the original developers on the PowerShell Team, noted that among observed attacks in 2017, the attack always began with an infected or malicious file and "it never started with PowerShell...the danger of of the PowerShell attack is never the PowerShell attack, it's just that people are using it for post-compromise activities. They've already got code execution on a system that can do anything that you can do in Windows" (Holmes, 2018, 7:00).

This is likely still the case, and Verizon's 2023 Data Breach Investigation Report did not include PowerShell as a top method of intrustion; rather, it highlighted malicious emails, infected Office documents, and Remote Desktop Protocol (Verizon, 2023, p. 24–29). Clearly, the presence of PowerShell presents risk to environments. However, the problem is not resolved by attempting to remove or disable PowerShell.

Remove or Disable?

While it is simple to remove the PowerShell executable, this does not actually remove PowerShell from the system. PowerShell can still be run through DLLs, and as an integral component to the OS, attempting to remove these DLLs can corrupt the OS.

Attempting to disable PowerShell is more so a cosmetic performance than an effective security policy. "Disabling PowerShell" only blocks the executable, it does not actually prevent a user from using PowerShell. In fact, "everything that has PowerShell support is hosting the PowerShell engine" (Holmes, 2018, 10:40). PowerShell scripts and commands can also be run "by loading the underlying System.Management.Automation namespace, exposed through the .NET Framework and Windows Common Language Interface" eliminating any need for the PowerShell executable (Stetty, 2021).

Neither does modifying the execution policy truly disable PowerShell: "Contrary to popular belief, the execution policy in PowerShell is not a security boundary. It's designed to prevent a user from unknowingly running a script. A determined user can easily bypass the execution policy in PowerShell" (Robbins, 2022).

Microsoft's official PowerShell Team recommends against disabling PowerShell, as they reference the ease of use of custom tooling to bypass restrictions, and the additional burden it places on administrators:

Client systems. After initial infection (by a macro-enabled document or user double-clicking a malicious executable), malware sometimes uses PowerShell as one component of its attack chain. Microsoft's recommendation is not to block PowerShell completely, as PowerShell is required for many operating system and system management tasks. Microsoft's recommendation is to limit PowerShell to authorized users and administrators to mitigate the use by commodity malware, as described by point #4 above ("Deploy Device Guard / Application Control Policies"). If Windows Defender Application Control is not an option, security products that block PowerShell from unknown parent processes (such as Word, Excel) are a reasonable middle ground.

Server systems. Microsoft does not recommend blocking PowerShell on server systems. PowerShell is the most secure remote management technology, and disabling PowerShell exposes the server to significant risks of credential theft enabled by other remote management technologies (such as Remote Desktop). PowerShell is also the primary management technology for server systems, so blocking PowerShell completely causes an unacceptable administrative burden using tools with little to no security transparency. Additionally, malicious post-exploitation use of PowerShell on a server system is primarily associated with an active adversary, rather than the static approach used by commodity malware on client systems. Without Application Control (as described by point #4 above), active adversaries simply use other scripting languages or custom tooling. (PowerShell Team, 2020)

Cybersecurity authorities from the United States, United Kingdom, and New Zealand also "recommend proper configuration and monitoring of PowerShell, as opposed to removing or disabling PowerShell entirely" (CISA, 2022, p. 1). The joint report from the NSA, CISA, NZ NCSC, and NCSC-UK states:

PowerShell is essential to secure the Windows operating system, especially since newer versions have resolved previous limitations and concerns through updates and enhancements. Removing or improperly restricting PowerShell would prevent administrators and defenders from utilizing PowerShell to assist with system maintenance, forensics, automation, and security. PowerShell, along with its administrative abilities and security measures, should be managed properly and adopted. (CISA, 2022, p. 5)

To truly remove or disable PowerShell requires extreme changes to the OS which are not recommended.

Recommended Actions

1. Uninstall the Windows PowerShell 2.0 Engine. PowerShell 2.0 is deprecated and lacks security features present in PowerShell 5.X, such as enhanced transcription logging and Antimalware Scan Interface Protection (Aiello, 2017).
2. Use a GPO to enable Script Execution and select "Allow only signed scripts." This setting is recommended by the Center for Internet Security (CIS) and will override the execution policies set in PowerShell (CIS, n.d.). While threat actors can spoof signatures, the policy provides a thin layer of protection with minimal downside for administrators.
3. Use AppLocker to force PowerShell to use Constrained Language Mode. Constrained language mode "restrict[s] access to sensitive language elements that can be used to invoke arbitrary Windows APIs" (PowerShell Team, 2018). This policy must be tested before implementation to determine operational effects.
4. Create a Script Rules policy. AppLocker can also be used "to create an allow rule only for a specific folder," preventing arbitrary file execution outside the specified path (Gates, 2022).
5. Use PowerShell Remoting to manage systems. hen remote connections are needed, "PowerShell Remoting is the recommended way to manage Windows systems" (Wheeler et al, 2023). PowerShell Remoting uses Kerberos or NTLM authentication and "these authentication protocols do not send the actual credentials to remote hosts, avoiding direct exposure of credentials and risk of theft through revealed credentials" (CISA, 2022, p. 2). If implemented, the Windows Firewall rule should restrict connections to "trusted endpoints…to reduce lateral movement opportunities" (CISA, 2022, p. 3).
6. Log all PowerShell activities. As storage permits, all PowerShell activities should be recorded with an emphasis on Deep Script Block Logging and module logging, which record "even hidden malicious PowerShell activities and the commands that are executed, such as command invocations, and portions of scripts" (CISA, 2022, p. 4).

Summary

PowerShell is a core component to the Windows OS and there is no safe way to remove it. Disabling PowerShell through settings prevents the invocation of the executable, but does not prevent invocation from alternative entry points. Instead, PowerShell should be hardened and monitored.

References

Aiello, J. (2017, August 24). Windows PowerShell 2.0 deprecation. PowerShell Team. https://devblogs.microsoft.com/powershell/windows-powershell-2-0-deprecation/
CIS. (n.d.). Intel insights: How to secure PowerShell. Center for Internet Security. https://www.cisecurity.org/insights/white-papers/intel-insights-how-to-secure-powershell
CISA. (2022, June 22). Keeping PowerShell: Security measures to use and embrace. https://media.defense.gov/2022/Jun/22/2003021689/-1/-1/1/CSI_KEEPING_POWERSHELL_SECURITY_MEASURES_TO_USE_AND_EMBRACE_20220622.PDF
Fetterman, R. (2022, December 14). Zoom. Enhance!: Finding value in macro-level ATT&CK reporting. Splunk. https://www.splunk.com/en_us/blog/security/zoom-enhance-finding-value-in-macro-level-att-ck-reporting.html
Gates, J. (2022, June 22). Why to harden PowerShell and not remove it entirely. CalCom. https://www.calcomsoftware.com/mitigating-powershell-attacks/
Holmes, L. (2018, May 2). Defending against PowerShell attacks — In theory, and in practice by Lee Holmes. PowerShell.org in YouTube. https://www.youtube.com/watch?v=M5bkHUQy-JA
PowerShell Team. (2020, February 20). Defending against PowerShell attacks. Microsoft. https://devblogs.microsoft.com/powershell/defending-against-powershell-attacks/
PowerShell Team. (2018, May 17). PowerShell constrained langauge mode. Microsoft. https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/
Reed, J. (2023, June 26). All about PowerShell attacks: The no. 1 ATT&CK technique. SecurityIntelligence. https://securityintelligence.com/articles/all-about-powershell-attacks/
Robbins, M. (2022, November 17). Getting started with PowerShell. Microsoft Learn. https://learn.microsoft.com/en-us/powershell/scripting/learn/ps101/01-getting-started?view=powershell-7.4
Stetty, S., & Meyer, A. (2021, February 9). Stopping "PowerShell without PowerShell" attacks. Palo Alto Networks Blog. https://www.paloaltonetworks.com/blog/security-operations/stopping-powershell-without-powershell/
Verizon. (2023). 2023 Data breach investigation report (DBIR). Verizon Enterprise Solutions. https://www.verizon.com/business/resources/T348/reports/2023-data-breach-investigations-report-dbir.pdf
Wheeler, S., Wilson, C., & Schonning, N. (2023, October 23). Security considerations for PowerShell Remoting using WinRM. Microsoft Learn. https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/winrm-security?view=powershell-7.4