
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.
Introduction
PowerShell version 2 is to this day still preinstalled on Windows 11 and all Windows Server versions with the exception of Windows Server 2022.
If PowerShell version 2 is installed, it’s possible to bypass the constrained language mode, which normally is being enforced by application control solutions like AppLocker and similar.
If you haven’t removed PowerShell version 2 already, you should consider looking into it today as an early Christmas present. 🙂
Ps. this solution is only targeting workstations. If you need to remove PowerShell version 2 from servers, you cannot leverage Microsoft Intune. You should instead look into Configuration Manager or similar.

Constrained Language Mode
The language mode of PowerShell can be queried using $ExecutionContext.SessionState.LanguageMode as shown below.

If PowerShell version 2 is installed, you can switch over to using this version, effectively bypassing Constrained Language Mode. See below:

Uninstall PowerShell version 2
In order to uninstall PowerShell version 2 using Microsoft Intune, I use 2 separate scripts. The scripts are located on my GitHub repository.
Detect-PoShv2.ps1: PowerShell/Detect-PoShv2.ps1 at master · imabdk/PowerShell (github.com)
- This script detects if PowerShell v2 is currently installed/enabled on the system
- If PoShv2 enabled, exit the script with error code 1
Disable-PoShv2.ps1: PowerShell/Disable-PoShV2.ps1 at master · imabdk/PowerShell (github.com)
- This script detects if PowerShell v2 is currently installed/enabled on the system
- If PoShv2 installed/enabled, PoShv2 is uninstalled/disabled.
Put the 2 scripts to use in Microsoft Intune with the Remediations options (formerly known as Proactive Remediations) as shown below:


Notice how your devices gradually reports back that PowerShell version 2 is no longer present on the systems.

We’ve all been there – you’re trying to uninstall a piece of software, but it just doesn’t seem to be as straightforward as you’d like. Perhaps the traditional uninstall process is proving to be a hassle, or maybe the software doesn’t seem to want to leave your system, no matter how hard you try.
That’s where PowerShell comes in.
In this article, we’ll show you three effective methods that leverage the power of PowerShell to manage and uninstall software packages with ease:
- WMI Method
- Package Provider
- Uninstallation String
Let’s get started!
Uninstalling Software with the WMI Method
One of its key components is the Win32_Product class that embodies products installed by Windows Installer.
Get-WmiObject -Class Win32_Product | Select-Object -Property Name
After a few seconds, the command will come up with a list of most applications installed on your PC.

2. From this list, identify the exact name of the application you wish to uninstall. It’s crucial to match the name exactly as it appears in the PowerShell output.
3. To locate your application, modify your command as shown below, replacing “PowerShell Test Application” with the name of your application:
Get-WmiObject -Class Win32_Product | Where-Object{$_.Name -eq "PowerShell Test Application"}
$MyApp = Get-WmiObject -Class Win32_Product | Where-Object{$_.Name -eq "PowerShell Test Application"}
$MyApp.Uninstall()While effective, the WMI Method has its limitations:
- It is resource consuming.
- There are cases where the WMI Repository is corrupted.
- Not all applications can be uninstalled by the WMI Method.
In case you’re unable to find your specific application using the WMI Method, the Get-Package cmdlet comes to the rescue, which leads us to the second method.
Uninstalling Software with the Uninstall String
The Uninstallation String method is ideal for custom packages. If a package appears in the Control Panel’s Add & Remove Programs, it creates an entry in the registry.
– For 64bit packages:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
– For 32bit packages:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
To uninstall a package using the Uninstallation String, locate the specific package entry and identify its uninstall string.
For example, if we look at the UXP WebView Support package, we can see that it has a custom uninstall string.

Conclusion
We’ve journeyed through the comprehensive landscape of uninstalling software packages using PowerShell, navigating through three dynamic methods – the WMI Method, Package Provider, and Uninstallation String. Each of these approaches is designed to give you control, flexibility, and precision when managing software on your system.
Whether you’re handling conventional applications or unique, custom packages, these PowerShell methods offer powerful solutions for your uninstallation needs. The key is understanding each method’s advantages and limitations, and strategically applying them based on your specific circumstances.
We hope this guide helps you harness the potential of PowerShell Package Management, enabling you to manage your software environment with confidence and efficiency. Continue exploring, and keep enhancing your software management skills. Remember, in the realm of PowerShell, you’re only limited by what you don’t know. Happy uninstalling!
Popular Articles
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.
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.
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 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).





