11/18/2020 Jim Hill

How to Block the Use of PowerShell in Windows 10 by Implementing an Applocker Policy through Microsoft Endpoint Manager

In a Cloud Only Microsoft 365 Environment

Microsoft’s PowerShell is a powerful scripting application which is built natively into Windows 10 devices. While this application allows great power for administrators to configure and control their devices it also opens up huge opportunities for hackers to launch malware attacks including the recent spike of ransomware attacks in which the universal element in common was the use of PowerShell. This article describes how a Microsoft 365 Endpoint administrator can selective disable PowerShell either on a device by device basis or for a group of devices registered through the Microsoft 365 Azure Active Directory.  These instructions were created for Windows 10 devices registered through the BYOD registration method but should also work for the other enrollment methods albeit with slight differences.  These would also work within a hybrid environment with small adjustments. For the latter, just follow these instructions but when you roll out the configuration profile in Microsoft Endpoint Manager but make adjustments by following the config profile creation for Intune per this article: https://www.petervanderwoude.nl/post/managing-applocker-on-windows-10-via-oma-dm/ 

Note: I am thankful for the very helpful instructions provided by Peter van der Woude in the article referenced above. I also wish to thank Alex Fields from ITProMentor who sent me Peter’s article as well as for his very helpful articles on Microsoft 365. I highly recommend reading them at his site at:  https://www.itpromentor.com/

Summary of Steps to Disable PowerShell in a Microsoft 365 Cloud Only Environment through the Microsoft Endpoint Manager:

  1. Create New Security Group. In Endpoint Manager, create a security group which you will use to assign users and devices for which you want to disable PowerShell.  I recommend that you add just one test device to this new security group at first for testing purposes before you roll it out to your entire enterprise.  You could name your security group something like “Disable Powershell for Users and Devices.”
  2. Create XML Device Policy. Using a Windows 10 computer, use the Group Policy Editor to create a Applocker device policy which blocks the use of the EXE files associated with PowerShell.  Since most enterprise use the 64 bit variety of Windows 10 there are a total of four EXE files which need to be restricted:
    C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe
    C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
    C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell_ise.exe
    Important: You will need to edit the XML created in the Group Policy Manager and delete just the elements you need.
  3. Apply the Device Profile. Finally, roll out the device configuration profile in the Microsoft Endpoint Manager using the following OMI-URI:
    ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/9000/EXE/Policy  where the string value of “9000” is some value that you decide upon that makes sense to you. The other values must be entered exactly and this string is case sensitive.  I use policy strings with 9’s in them when they contain restrictions, use what makes sense to you.

Detailed Steps of how to Disable PowerShell in a Microsoft 365 Cloud Only Environment through the Microsoft Endpoint Manager:

Step 1 – Create new Security Group in Endpoint Manager

Build the Security Group you will use to restrict devices and users from using PowerShell.  If users never require the use of PowerShell, and they already have local administrative access, then why allow them to have access to this powerful program in the first place?  Open the Endpoint Manager  and browse to Groups from the home menu tree.  Create a new security group and name it with something that makes sense like “Disable PowerShell for Users and Devices.”  Add one test device to the new security group.  Later, when you want to quickly enforce the policy on this device, you will open that Windows 10 computer, select the Company Portal app (you do have this installed for every device per the BYOD device enrollment process, right?) and under the settings gear select “Sync.” This will sync the policies in the Endpoint Manager to the local Windows 10 device.

Step 2 – Create the Device Policy in the Group Policy Editor

Open the local group policy editor on a Windows 10 computer by typing “edit group policy” at the start menu.  When the policy editor opens browse to this tree. It is helpful to follow the more detailed instructions provided by Kenneth Van Surksun in this very helpful article.  Note that even though you will need to create the default policies in that tree you will later edit the XML file and remove everything that is not relevant to the new policy restricting the use of PowerShell.  Microsoft has also provided an excellent technical article detailing the Applocker CSP which provides the information necessary to specify the correct OMI-URI settings for the restriction of the EXE part of the tree.  Note: This is a fairly hard element to figure out without help from others. It took me a long while to determine the correct values so hopefully this article was of help to you!

group policy editor

Figure One: Tree Diagram from the Group Policy Editor

Figure One: Tree Diagram from the Group Policy Editor

Notice that I have already defined both the default policies as well as the restrictions for the EXE files associated with PowerShell.  You will need to include policy restrictions for these EXE files:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe

And, for 64-bit Machines:
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell_ise.exe

The following is one of these deny policies:

deny policy in group policy editor

Figure 2: Example Policy for Restriction of the PowerShell EXE

Figure 2: Example Policy for Restriction of the PowerShell EXE

Create each of the four policies, then right click on the AppLocker tree and select Export. This will export an XML file for the new policy.  Then, edit the XML file by removing everything except the single policy you have defined for the new restriction.  Your final XML file should look something like mine:

<RuleCollection Type=”Exe” EnforcementMode=”Enabled”>
<FilePathRule Id=”921cc481-6e17-4653-8f75-050b80acca20″ Name=”(Default Rule) All files located in the Program Files folder” Description=”Allows members of the Everyone group to run applications that are located in the Program Files folder.” UserOrGroupSid=”S-1-1-0″ Action=”Allow”>
<Conditions>
<FilePathCondition Path=”%PROGRAMFILES%\*” />
</Conditions>
</FilePathRule>
<FilePathRule Id=”a61c8b2c-a319-4cd0-9690-d2177cad7b51″ Name=”(Default Rule) All files located in the Windows folder” Description=”Allows members of the Everyone group to run applications that are located in the Windows folder.” UserOrGroupSid=”S-1-1-0″ Action=”Allow”>
<Conditions>
<FilePathCondition Path=”%WINDIR%\*” />
</Conditions>
</FilePathRule>
<FilePathRule Id=”fd686d83-a829-4351-8ff4-27c7de5755d2″ Name=”(Default Rule) All files” Description=”Allows members of the local Administrators group to run all applications.” UserOrGroupSid=”S-1-5-32-544″ Action=”Allow”>
<Conditions>
<FilePathCondition Path=”*” />
</Conditions>
</FilePathRule>
<FilePathRule Id=”c8036eb7-ddda-458a-bb95-8833e70b62aa” Name=”%SYSTEM32%\WindowsPowerShell\v1.0\powershell.exe” Description=”32 bit powershell” UserOrGroupSid=”S-1-1-0″ Action=”Deny”>
<Conditions>
<FilePathCondition Path=”%SYSTEM32%\WindowsPowerShell\v1.0\powershell.exe” />
</Conditions>
</FilePathRule>
<FilePathRule Id=”5dc163be-ff6b-4e78-96c2-1aba2c0212bb” Name=”%SYSTEM32%\WindowsPowerShell\v1.0\powershell_ise.exe” Description=”32 bit powershell ise” UserOrGroupSid=”S-1-1-0″ Action=”Deny”>
<Conditions>
<FilePathCondition Path=”%SYSTEM32%\WindowsPowerShell\v1.0\powershell_ise.exe” />
</Conditions>
</FilePathRule>
<FilePathRule Id=”1decfb8a-6a68-4643-8776-779f5228faa9″ Name=”%SYSTEM32%\WindowsPowerShell\v1.0\powershell.exe” Description=”64 bit powershell” UserOrGroupSid=”S-1-1-0″ Action=”Deny”>
<Conditions>
<FilePathCondition Path=”%SYSTEM32%\WindowsPowerShell\v1.0\powershell.exe” />
</Conditions>
</FilePathRule>
<FilePathRule Id=”f2f97a58-4ae2-4910-9993-b8817e4f3fb7″ Name=”%SYSTEM32%\WindowsPowerShell\v1.0\powershell_ise.exe” Description=”64 bit powershell ise” UserOrGroupSid=”S-1-1-0″ Action=”Deny”>
<Conditions>
<FilePathCondition Path=”%SYSTEM32%\WindowsPowerShell\v1.0\powershell_ise.exe” />
</Conditions>
</FilePathRule>
</RuleCollection>

Download my XML File

Step 3 – Apply the Device Profile in Microsoft Endpoint Manager

Create a new device configuration profile for Windows 10 devices and apply it only to the new security group you created above.  For the profile type select “Custom” and then use the OMA-URI value of:

./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/9000/EXE/Policy

where the string value of “9000” is some value that you decide upon that makes sense to you. The other values must be entered exactly and this string is case sensitive.  I use policy strings with 9’s in them when they contain restrictions, use what makes sense to you. Peter did a better job of describing the process in his excellent article.

You will then want to visit the test computer that you assigned to the security group and select “Synch” in the Company Portal App.  Test out the policy by typing “PowerShell” at the start menu. If all is working correctly you will see the following message:

screen shot of policy warning for powershell blocked

Figure Three:  Error Message for Blocked Application per the new Applocker Policy Restriction

Figure Three:  Error Message for Blocked Application per the new Applocker Policy Restriction

Conclusion:

You have now successfully configurated an Applocker restriction policy for Windows 10 devices  and applied it using the Microsoft Endpoint Manager. This will make things harder for hackers to mess with your Windows 10 devices.

, , , ,

Jim Hill

In my role at User Friendly Consulting I handle security operations, desktop and server administration, and digital marketing. We leverage the Microsoft 365 enterprise suite in order to provide maximum efficiency and security for our employees. My primary work is developing and implement digital marketing programs as well as control the IT infrastructure for the company.  I love the area of digital security and the adoption of secure practices, email delivery, and Office 365 security and configuration.  My background is mechanical engineering and information technology. I began my career as an engineer at Ford Motor Company in Dearborn and then transitioned into the IT field in 1998. My first work with computers was with finite element analysis on a Macintosh computer where I wrote a program to analyze stress on a flat plate for my senior design project. I began working at User Friendly Consulting in 1998 in various capacities but have landed in a role

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.