At our last Windows Management User Group Netherlands meeting, we had the honor to have Sami Laiho, one of the world’s leading professionals in the Windows OS and Security flying over to the Netherlands and present for our user group. In his presentation titled: “Securing Windows in 2020 and forward”, Sami made us aware that by implementing some simple Applocker policies on our Modern Workplace and by making sure that the user working on the device has no admin rights, we can seriously improve our security. In his presentation Sami referred to a quote from Mikko Hyppönen (Chief Research Officer at F-Secure): “Make your security better than your neighbours”.
In this blogpost I will share my experience with implementing Applocker policy within my own tenant, and how I started to use these principles myself which eventually led by removing my account from the local administrator group.
Disclaimer: This blogpost provides a very simplistic way of enabling Applocker policies, in the real world there are some caveats which must be addressed when implementing Applocker. I will address those caveats later in this post as well.
Current state of local admin rights on Windows 10 devices
If you start Windows 10 business editions for the first time in the Out of the Box (OOB) experience, you can choose to join the device to Azure Active Directory. If you do this, by default the account performing the join will be added to the local administrator group. If you don’t want your users to become a local administrator on the device, you need to leverage Windows Autopilot where you can define this behavior (whether or not the user gets added to the local administrator group) in a deployment profile.
Due to this default setup provided by Microsoft it’s quite normal nowadays that there are some modern workplace implementation where the users are a local administrator on their device. In my opinion and based on my experience, this is a risk which must be mitigated. This mitigation can be done in several ways, where each solutions has it’s pro’s and con’s. For example you can decide to implement Microsoft Defender Advanced Threat Protection (MDATP) or a 3rd party solution providing services based on a “assume breach” approach on all your devices where the users are local admin, so that you have a way to detect and respond to a breach in a short period.
Another option is to revoke the administrator rights of your users, and implement some basic Applocker policies to prevent unwanted software from executing on your users devices.
First let’s see how we can setup Applocker
Setup and test your Applocker policies
The best way to setup your initial Applocker policies is by implementing the policies in a local group policy on a “standard” machine within your environment. With standard I mean a machine containing the default configuration when it comes to settings and applications installed.
You can open the Local Computer Policy by executing gpedit.msc and browse to Computer Configuration -> Windows Settings -> Security Settings -> Application Control Policies, where you will find the Applocker node.
Modifying the default rules
One of the recommendations mentioned by Sami, is to add a code signing policy rule to the default Executable rules. This will allow user to run signed applications (portable apps for instance) which they downloaded from the Internet for example.
Disabling the use of the built-in Paint 3D app
As an example we want to deny the start of the built-in Paint 3D application
Testing your defined ruleset
With the default rulesets implemented, and your customizations added you can verify it’s behavior
The first thing you need to do is configure enforcement behaviour for the Applocker policies, we will start with auditing the behaviour of the implemented rules.
Once the Enforcement settings are configured, we need to start the “Application Identity” service. This service is set to “Manual” by default. Make sure that it’s set to Automatic and started
See: Configure the Application Identity service for more information
Start your applications and verify the Auditing events in the Event Viewer
Enforcing your rules and verify the audit events in the Event Viewer
Now that we have a good feeling based on the Audit events, we can enforce the Applocker rules on our test system.
Exporting your Applocker policies
Once you have a good working Applocker configuration you can export that configuration into a .XML file which we need later on when creating our Configuration Profile in Intune.
You can export the configured Applocker policy by rightclicking on the Applocker node, and by choosing export. Provide a name and location for the XML file and click Save.
From that point forward you can open your XML file in your favorite XML editor
Distributing your Applocker policies using Configuration Profiles in Microsoft Intune
By using a Configuration Profile in Microsoft Intune we can deploy our exported Applocker policy to our Intune managed Modern workplaces.
We can do this by leveraging the Applocker Configuration Service Provider (CSP)
Create the Intune Configuration Profile
The first thing we need to do in order to use the CSP is to modify the XML and split it into several parts. I suggest doing it like this and to store these XMLs near your documentation for future reference.
Split the XML by copying the parts between <RuleCollection…> and </RuleCollection> for each section (AppX, Exe, MSI and Script). We will use the content of the XML files later when creating our Configuration profiles
We can create a Configuration Profile for Packaged Apps (AppX) by going to the Microsoft Endpoint Manager admin Center -> Devices -> Configuration Profiles. Click on “+ Create Profile” to create a new Configuration Profile
Provide the following details:
Name: Profile – W10 – Applocker – AppX (in my demo)
Description: Windows 10 – Applocker Policy – AppX
Platform: Windows 10 and later
Profile type: Custom
You can click on Add at the OMA-URI settings and provide the following details
Name: Applocker – AppX
Description: AppX configuration for Applocker
Data Type: String
Note: Notice the I2401 part in the OMA-URI, make this a unique string for your environment. You can choose this for yourself.
Copy the contents of your XML file and make sure it gets displayed without any error.
Now create other Configurationprofiles for Exe, MSI and Script – make sure that you use the OMA-URI strings which correspond to the rules you want to configure.
Once the Configuration profiles are created, assign them to either your users of machines
Making sure that the Application Identity services is started
Note: As mentioned in the comments, this is not necessary, the Application Identity Service will automatically start, see below for more information.
In order for the Applocker policies to work, we need to make sure that the Application Identity service is configured for automatic start and is running.
In order to accomplish this, we will create a simple PowerShell script which we will deploy to our clients. The script will set the Application Identity service startup type to automatic, and afterwards start the service.
set-service Appidsvc -Startuptype automatic
Once the configuration profiles and the PowerShell script are applied to your Modern workplace device you can see the following:
Some lessons learned
Lesson 1: Adding extra Applocker rules is easy
Let’s say that besides blocking the usage of Paint 3D as described above, you also want to disable the use of the built-in Mail app.
Just create a new XML with the configuration you want to apply, and make sure that you define a new unique OMA-URI string, in my case: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/I2402/StoreApps/Policy. If you don’t make the string unique you will have a policy conflict.
When you apply this policy, it will become active and also block the built-in Mail app from being executed.
Update August 2020: Based on a comment I received from Jon Abbott, we noticed a change in behaviour on how this scenario is processed. This has to do with the fact that Microsoft changed how Intune policies are processed, see the following article by Olivier Kieselbach for more context on that: Changed Intune Policy Processing Behavior on Windows 10
Due to this change in behaviour you now have to include the default rule set you created at all times, the concept of adding applications after that will still be valid though (as verified in my environment)
Lesson 2: Don’t expect too much from PowerShell and the Local Group Policy editor for troubleshooting purposes
If you want to verify whether the AppLocker settings are active on the system to which you deployed the Configuration Profile you will notice that the AppLocker node in the Local Group Policy Editor is empty. This is because the CSP is not configured as a local policy. It would be really nice to have a similar way (visual) to check for the CSP settings.
When using the Get-ApplockerPolicy commandlet you don’t get any information either. This is due to the fact this commandlet also relies on policies being set and doesn’t see the CSP configuration. Something MS must fix IMHO.
Software Restriction Policies, Applocker, Device Guard and Windows Defender Application Control
One of the disadvantages of the current internet is that “old” information doesn’t get removed. When I started reseaching for this article I became quite confused when reading about Software Restriction Policies (SRP), Applocker, Device Guard and Windows Defender Application Control (WDAC). Here is what I found out:
It all started with Software Restriction Policies which Microsoft introduced with Windows XP. SRP was hard to implement and therefore Microsoft released a version 2 of the Software Restriction Policies with Windows 7 and renamed the feature to AppLocker. Software Restriction Policies have similarities but also work slidably different. For a detailed comparison of Software Restriction Policies versus Applocker check out this article: “Determine your application control objectives“. It’s even possible to combine Software Restriction Policies with Applocker as detailed in this article: “Use Software Restriction Policies and AppLocker policies“
When Windows 10 was released Microsoft introduced Device Guard which could use Virtualization Based Security (VBS) allowing for better protection. Device Guard was later (when Windows 1903 was released) rebranded to Windows Defender Application Protection (WDAC). WDAC allows you to generate and configure policies using PowerShell and deploy them via Intune for example, but GPO’s is also supported. One of the neat additions for WDAC is that you can use reputation of the app as determined by Microsoft’s Intelligent Security Graph in order to allow or deny apps to run.
Also here you can decide to use AppLocker and WDAC in combination, see “Choose when to use WDAC or AppLocker” for more information. If you want more in detail information, I want to suggest that you read the following article: Application whitelisting: Software Restriction Policies vs. AppLocker vs. Windows Defender Application Control, by Wolfgang Sommergut on 4Sysops.
Device Guard (which is confusing since it should be called WDAC), is part of the MDM Security Baseline for May 2019 and provides the following configured options by default. So if you have the Security Baseline configured and deployed you are already using it.
Applocker known issues
There are many known ways to circumvent AppLocker policies, especially if you only use the default rules created using the wizard.
Aaron Margosis has written a solution based on PowerShell scripts which can further restrict the AppLocker policies, his solution called Aaronlocker is widely used IT departments configuring AppLocker in Enterprise environments.
From the documentation: AaronLocker is designed to make the creation and maintenance of robust, strict, AppLocker-based whitelisting rules as easy and practical as possible. The entire solution involves a small number of PowerShell scripts. You can easily customize rules for your specific requirements with simple text-file edits. AaronLocker includes scripts that document AppLocker policies and capture event data into Excel workbooks that facilitate analysis and policy maintenance
My advice would be that once you have a clear understanding of what Applocker can do in your environment you further restrict the Applocker policies, where both the Aaronlocker but also the Ultimate Applocker Bypass List can come in handy. Keep in mind though that you must also monitor for changes and implement those in your environment.
Implementing the described AppLocker policies in your environment can be a first step in order to make your security slightly better than you neighbor. It allows you to get to know AppLocker and provides some security improvements in your environment. Once you get a grip on these security measures you might want to consider to further implement other Applocker polices and configure WDAC.
We will have to do better though, if we want to further strengthen our security step by step..
Based on some feedback via comments I received some information which is valuable to this article as well.
Will this run on Window 10 Pro and will I be able to enforce my Applocker settings?
Anwer is yes, I’ve tested my Intune managed device on the Windows 10 Pro version and I have the ability to block applications
Oliver Kieselbach pointed me to the fact that configuring the Microsoft Identity Service for autostart is not really necessary since Windows will automatically start the service if needed. As you can see in the screenshot on a non-configured device the service is started and running.
Rudy Ooms made me aware that there is a more handy way to check whether the policies have been downloaded to the client
Stop malware with Software Restriction Policies alias SAFER, by Stefan Kanthak
Aaronlocker, by Aaron Margosis
Ultimate AppLocker ByPass List, by Oddvar Moe
Blocking apps with Intune and AppLocker CSP, by Matt Hinson