In this guide, I’ll show you how to disable PowerShell with group policy. In addition, I’ll show you how to enable it for specific users such as administrations while leaving it disabled for all other users.
Why Disable PowerShell?
PowerShell is often used by malicious actors to spread malware throughout the network. PowerShell is enabled by default on Windows 10 for all users, attackers can utilize this tool to run malicious commands, access the file system, registry, and more. Ransomware is often distributed throughout the network via PowerShell. To learn more I recommend reading this white paper -> Security Primer – Ryuk
Steps to Disable PowerShell with Group Policy
Important:
This example blocks the original 32bit version of PowerShell. Your computers may have a different version or multiple versions installed (Core and 5.1). To Block all PowerShell versions you will need to create multiple path rules.
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
Now, create and link a new GPO to the organizational unit that has the user accounts you want to block access for. I have all of my users in an organizational unit called “ADPRO Users” so I will link it there.
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.
2. Edit the GPO and navigate to -> User Configuration -> Policies -> Windows Settings -> Security Settings -> Software Restriction Policies
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.
Tip: Another option is to use a hash rule. The benefit of a hash rule is it will block the file no matter its location. For example, if PowerShell tried to run from c:\it\ it would be blocked due to the hash rule, not the file path. The only drawback to this is you would need a hash rule for every version of PowerShell.
Next, reboot your computer for the policy to take effect. Now when you try to run PowerShell you should receive the following message.
You can repeat these steps for PowerShell ISE or any other application you want to block.
This blocks it for any user in the OU you applied the GPO to. To enable it for specific users follow the steps below.
Step 2: Allow PowerShell for Administrators
In this section, I’ll show you how to block PowerShell for users but keep it enabled for administrators.
1. Create a new Active Directory Security group.
Name it whatever you want, I like to be descriptive with objects so other administrators can quickly understand what it is used for. I named my group “GPO – Enable PowerShell”
Now add any user as a member to this group that you want to have the rights to run PowerShell.
2. Modify GPO Delegation
Now go back to the GPO you created in step 1 and click on the delegation tab.
Click “Advanced”
Click “Add” then select the security group you created that has users you want to enable PowerShell for. Click OK.
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”
Click OK.
Now any user you add to the security group will get denied this policy and enable them to run PowerShell.
Conclusion
PowerShell is a great tool for administrators but it is being abused more and more by malicious actors to spread ransomware throughout the network. I recommend adhering to the principle of least privilege and ensuring users have the minimal level of access needed to perform their work duties. Most users don’t need PowerShell so it is recommended to disable it for those users. Ensure you test these types of changes before rolling it out company wide and get approval with documentation to cover yourself. Change management is great for these types of system wide changes.
Thanks a lot, it worked.
Hi, will this block PowerShell altogether ? I’m asking if this can break applications? For examle Defender for Endpoint is using PowerShell to download signatures ….
It is a user GPO policy so it would only block it for the users the GPO applies to. Defender may be using the system or a service account so it can easily be excluded.
You can use powershell to get the hash for each ‘powershell.exe’ on the system with this command:
get-childitem -Path c: -Filter powershell.exe -Recurse -ErrorAction SilentlyContinue -Force | Get-FileHash
If you run that on multiple machines, you can get a good selection of the hashes to block.
This is great, I had to change the path to c:\ for it to work.
Hi robert
Better, change the path to $env:SystemDrive. By this you’ll be sure that you’ve selected the system drive.
Remember : Avoid using hard coded car in a script 🙂
regards
It’s even better if an organization is able to disable PowerShell remoting! We were able to do this, thankfully.
PowerShell remoting is disabled by default on client computers but is enabled by default on servers.
Hi Robert
Disabled Powershell remoting is not a good idea on client because this impact Admin Accounts. Enabled Powershell remoting is better, with restrictive VLANs (i.e. admin VLAN)
– No impact for regular users
– Admin Accounts can use it
Set powershell remoting is setting WinRm. You could set winRM using GPO
regards
Hi,
I recommend disabling PowerShell for regular users and then you can specify which Admins or users to enabled it for (See step 2). You should of course test this to make sure it won’t break anything.
Thanks a lot, it worked.
Hi, it wont work like in step2, due its a computer policy (not user policy).
So afaik it will ignore this
You need to block PowerShell 32bit and 64bit and powershell_ise 32bit and 64bit and PowerShell Core all versions and PowerShell Windows Universal App from Microsoft all versions.
Great point. Thanks, Karol.
Karol: could you provide links to any reputable articles on this?
you could just rename the file and still run, better off creating applocker rule rather than software restriction policy.
Yes but applocker requires Windows enterprise version.
I applied this but I am still able to open the PowerShell. Also, when running gpupdate no result appeared for software restriction
can you please help me finding the problem?
Which PowerShell version? PowerShell core has a different path than the original version.
I am using Defender AntiVirus and from the audit I see malicious scripts trying to run from C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
As of today your solution is v.helpful. However, if the malicious scripts copies the file and rename the .exe to execute, it can bypass this GPO.
Good reference article to stop applications. Thanks
Yea it is not 100% full proof, using the hash method would be more effective.
Any program or script that uses PowerShell would make a call to PowerShell.exe. You could try Microsoft Sysmon, it will add a log entry when anything runs powershell.exe with lots of details.
I mean when I check the gpresult for the logged in user, it shows policy applied , but it shows first this one:
Software Restriction Policies/Security Levels
Policy Setting
Default Security Level Unrestricted
Though down it shows the powershell block , i have applied, i think the above one is taking precedence.
I applied this, but still i am able to open powershell . I have checked the path and its the same some being used.
It is taking the default – Unrestricted as selected.
Confirm the path to the powershell.exe with this command
(Get-Command powershell.exe).Definition
Typically this is the path but I would first confirm that.
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Thanks, path was correct, but when I enabled the Restriction rule, couple of default rules were there, which had the option Unrestricted, I removed them and after sometime, checked, its working fine.
Thanks , appreciate your help.
Hello,
I use a deploy software that I can deploy various powershell scripts but now need to allow users to run powershell.
How do I go about removing this policy from each user? I tried just disabling the gpo but that doesn’t work.
Thanks,
Tony
Hi what is to stop malicious software copying Powershell.exe which is blocked to some other name and execute that thus bypassing the GPO.
Good question. Absolutely nothing. This method only blocks the path so powershell could be run from another location. There is no 100% full proof method but this would stop a lot of common attacks that use PowerShell.
I would highly recommend using the Hash rule method which blocks it regardless of location. Unfortunately you do have to take the time to setup the rules for each and every version of Windows (including versions of Win10 like 1809/1903/etc.) as they have different hash values.
Kenny, I agree I’ve just not had much luck with the Hash rule working for blocking PowerShell.
I had tested the steps below it is working fine to disable all users but for the secuiry group that enable users does not work , i had followed the steps as mentioned on this page correctly
Run a gpresult /r to check if the GPO is still being applied or not to the allowed group. If everything is correct you should not see the GPO applied to your allowed list.
I had followed the same step but the policy is not working , when i apply the policy and reboot the client machine the PowerShell still running
Verify you are logging into the computer with a domain account. If you are logged in with a local account PowerShell will still run. You could apply this to the entire computer but you then lose the ability to give rights to specific users like admins. If that is not a concern then you could use a computer policy instead of a user policy.