If you’ve ever tried to run a script from Powershell you’ve probably seen this error message.


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.
Why Disable PowerShell?
Step 1: Find the PowerShell.exe file path
By default PowerShell.exe is located in this folder -> C:\Windows\System32\WindowsPowerShell\v1.0
To verify this on your computer, open PowerShell, then open task manager, go to the details tab, scroll down to powershell.exe, right click and select “open file location”.

Windows explorer will open to the folder location of powershell.exe. Make a note of this location as it will be needed in a later step.

Step 2: Create GPO to block PowerShell.exe
1. Open the Group Policy Management Console

Give the new GPO a name. I like to be descriptive with names so it’s easy to understand it.

You have now created a new GPO, the next step will be to edit the settings.
Now right-click “Software Restriction Policies” and select “New Software Restriction Policies”

Select “Additional Rules”, then right-click and select “New Path Rule”

Now click the browse button and select the powershell.exe file from the path in step 1. Most common path is -> C:\Windows\System32\WindowsPowerShell\v1.0.
Set the security level to “Disallowed” Click OK.


2. **Create a New Policy:**
Navigate to the “Policies” section and create a new policy or modify an existing one.
a. In the policy settings, navigate to the “Application Control” section.
b. Look for options related to executable control or application management.
4. **Apply the Policy:**
Once you’ve configured the policy to disable CMD and PowerShell, apply the policy to the relevant group of managed computers.
5. **Deploy the Policy:**
The policy changes will need to be deployed to the managed computers. Depending on your Kaspersky Security Center configuration, this might happen automatically or require manual synchronization.
Please note that the steps provided are based on general principles and may vary slightly based on the specific interface and options available in Kaspersky Security Center version 14. Always refer to the official documentation or consult with your IT team for accurate instructions tailored to your setup.
Remember that disabling CMD and PowerShell can impact the functionality of your systems and applications. It’s important to thoroughly test this policy in a controlled environment before applying it to production systems. Additionally, ensure you have a reliable backup and recovery plan in place in case any issues arise.
Firstly, let’s understand why you would want to disable PowerShell 2.0. This legacy version of PowerShell does not have many of the security features and improvements available in newer versions. It’s practically an open invitation to malicious actors to exploit your systems.
The Disable PowerShell 2.0 Script
Now that we’ve established the “why,” let’s talk about the “how.” The Disable PowerShell 2.0 script is your one-stop solution. Written in PowerShell 5.1, the script is designed to work on Windows 10, Windows Server 2016, and above.
Here’s what this script offers:
Elevated Privileges Check
OS and Version Check
Before it attempts to remove PowerShell 2.0, it checks your PowerShell version. You need to be running PowerShell 5.1 or later. It’s a good feature, ensuring you don’t mess up your existing setup.
The Removal
The script employs different commands (Disable-WindowsOptionalFeatureand Uninstall-WindowsFeature) based on your operating system to disable PowerShell 2.0. If PowerShell 2.0 is already disabled, it’ll let you know.
The Script
#Requires -Version 5.1
<#
.SYNOPSIS Disables PowerShell 2.0.
.DESCRIPTION Disables PowerShell 2.0 by removing the feature. This script does require that PowerShell 5.1 be installed before hand. See: https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/wmf/setup/install-configure
.EXAMPLE No parameters needed.
.OUTPUTS String[]
.NOTES Minimum OS Architecture Supported: Windows 10, Windows Server 2016 Release Notes: Initial Release (c) 2023 NinjaOne By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use. Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
#>
[CmdletBinding()]
param ()
begin { function Test-IsElevated { $id = [System.Security.Principal.WindowsIdentity]::GetCurrent() $p = New-Object System.Security.Principal.WindowsPrincipal($id) $p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator) }
}
process { if (-not (Test-IsElevated)) { Write-Error -Message "Access Denied. Please run with Administrator privileges." exit 1 } if ($PSVersionTable.PSVersion -ge [Version]::new(5, 1)) { if ($(Get-Command "Disable-WindowsOptionalFeature" -ErrorAction SilentlyContinue).Name -like "Disable-WindowsOptionalFeature") { if ($(Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2 -ErrorAction SilentlyContinue).State -like "Enabled") { # Remove PowerShell 2.0 on Windows 10,11 try { Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2 -ErrorAction Stop Write-Host "Disabled PowerShell 2.0" } catch { Write-Error $_ Write-Host "Unable to disable PowerShell 2.0" exit 1 } } if ($(Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root -ErrorAction SilentlyContinue).State -like "Enabled") { # Remove PowerShell 2.0 on Windows 10, 11, Server 2016 try { Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root -ErrorAction Stop Write-Host "Disabled PowerShell 2.0" } catch { Write-Error $_ Write-Host "Unable to disable PowerShell 2.0" exit 1 } } else { Write-Host "PowerShell is already disabled." } } if ($(Get-Command "Uninstall-WindowsFeature" -ErrorAction SilentlyContinue).Name -like "Uninstall-WindowsFeature") { if ($(Get-WindowsFeature -Name PowerShell-V2) -and $(Get-WindowsFeature -Name PowerShell-V2).InstallState -like "Installed") { # Remove PowerShell 2.0 on Windows Server try { Uninstall-WindowsFeature -Name PowerShell-V2 -ErrorAction Stop Write-Host "Disabled PowerShell 2.0" } catch { Write-Error $_ Write-Host "Unable to disable PowerShell 2.0" exit 1 } } else { Write-Host "PowerShell is already disabled." } } if ( $(Get-Command "Disable-WindowsOptionalFeature" -ErrorAction SilentlyContinue).Name -notlike "Disable-WindowsOptionalFeature" -and $(Get-Command "Uninstall-WindowsFeature" -ErrorAction SilentlyContinue).Name -notlike "Uninstall-WindowsFeature" ) { Write-Host "Running on an unsupported version of Windows." exit 1 } } else { Write-Host "Please upgrade to 5.1 before disabling PowerShell 2.0." exit 1 }
}
end {}Access over 300+ scripts in the NinjaOne Dojo
How to Use the Script
Benefits for IT Professionals and MSPs
For IT professionals and MSPs, the benefits are twofold:
- Enhanced Security: By disabling PowerShell 2.0, you’re closing a vulnerability point, thereby making your network more secure.
- Efficiency: Instead of manually navigating to each server and system to disable PowerShell 2.0, you can automate this task with this script.
Final Thoughts
Disabling PowerShell 2.0 is crucial for enhancing the security posture of your Windows environment. For IT pros and MSPs looking for an efficient way to do this, our Disable PowerShell 2.0 script is a godsend. It automates the task and comes equipped with checks to ensure you’re doing things right.
Bit Powershell on 64 bit machines
If you’re using a 64 bit machine you’ll notice that the execution policy that you set on the 64 bit Powershell doesn’t affect the 32 bit Powershell, and vice versa.
The system Powershells are:
| 64 bit | |
| 32 bit |
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.
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:
To truly remove or disable PowerShell requires extreme changes to the OS which are not recommended.
Disabling script execution
When prompted answer with:
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.
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.
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 resolved by attempting to remove or disable PowerShell.
Enabling script execution
When prompted answer with:
Allow PowerShell for Administrators
1. Create a new Active Directory Security group.

2. Modify GPO Delegation
Now go back to the GPO you created in step 1 and click on the delegation tab.

In the permissions section make sure the group is selected and it has only these permissions
- Read is set to “allow”
- Apply group policy is set to “Deny”

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 Contrained 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
Recommended Actions
- 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).
- 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.
- 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.
- 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).
- Use PowerShell Remoting to manage systems. When 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).
- 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).




