With the increasing prevalence of ransomware, ensuring the security of devices in your enterprise environment is paramount. Application control is a security approach designed to protect against malicious code execution, and is one of the central tenets of the Australian Cyber Security Centre (ACSC) Essential Eight Maturity Model. When implemented correctly, it ensures only approved applications can execute on your endpoints. One effective method for achieving this is by implementing AppLocker, a feature available in Windows operating systems that allows administrators to control which applications and files users can run. This blog post will guide you through the basics of AppLocker, its benefits, and how to implement it to harden your devices against unauthorized access and potential threats.
What is AppLocker?
AppLocker is a powerful tool included in Windows that helps administrators manage application execution policies. It allows you to specify which users or groups can run particular applications based on unique identities of files. These files include executable files, scripts, Windows Installer files, DLLs, and packaged app installers.
Benefits of Using AppLocker
- Enhanced Security: By restricting which applications can run on a device, AppLocker helps prevent the execution of unauthorized software, including malware and potentially unwanted applications (PUAs).
- Compliance: AppLocker can help organizations comply with regulatory requirements by ensuring that only approved applications are used within the network.
- Ease of Management: AppLocker policies can be configured via Group Policy and deployed using Intune, making it easy to manage application permissions at scale.
Designing AppLocker Policies
Step 1: Preparing Your Environment
Before implementing AppLocker, ensure your environment meets the following prerequisites:
- Deploy a test machine for the initial configuration and testing of AppLocker, with local admin rights to manage services and the Group Policy editor.
- Create the initial template and apply it locally on the test device to ensure you don’t lock yourself out. AppLocker is a powerful tool that can easily lock down a device beyond use.
- For on-premises environments without an MDM, AppLocker can be deployed via Group Policy.
- For MDM managed environments, such as Intune cloud-based or hybrid environments, AppLocker can be deployed through the Intune portal.
- You do not need the Enterprise SKU to run AppLocker. This requirement was removed as of September 2022, meaning it can be configured and deployed on the more common Windows Pro SKU as well.
Step 2: Application Identity Service
AppLocker is reliant on the Application Identity service to be running automatically on the system. This service is included in Windows by default but is usually disabled. While you can enable it manually for testing, you will need to automate this process using PowerShell or Group Policy for enterprise environments.
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/applocker/configure-the-application-identity-service
Step 2: Creating Default Rules
Create the initial policy on your test device by opening the Local Security Policy editor (secpol.msc) or the Group Policy Object editor.
Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Application Control Policies -> AppLocker
For each item in the AppLocker dropdown menu, right-click and select Create Default Rules. The default rules are necessary to ensure your operating system runs correctly, while locking down all non-essential applications. As you become more familiar with AppLocker you can edit the default rules as required.
Step 3: Creating Custom Rules
Use the Create a new rule option to allow or deny a particular application, path, or file hash. You have a high degree of granularity when defining custom rules, allowing to specify version numbers, executable names, or create rules applying to all apps signed by a particular Publisher.
- Executable applications can be defined by selecting a reference application on your system. You should try to reference applications by publisher where possible. File path is subject to change or mismanagement, and file hashes can change with app updates.
- Windows Installer refers to MSI installation. You are likely already restricting your users from installing MSI files without admin rights.
- Script controls should reference known known publishers and be used in conjunction with script signing in your environment.
- Packaged applications refer to Appx packages, such as Teams, OneNote, and Company Portal. These are often deployed with Windows or through the Microsoft Store. You can also select a reference Appx on your system when creating a new rule.
Step 4: Enable AppLocker
With your default and custom rules created, and the Application Identity service running, you are ready to enable AppLocker by right clicking on the AppLocker menu item in the GPO editor:
AppLocker --> Properties --> Enforcement --> Configured for all rules
All four rules (executable, windows installer, scripts, and packaged apps) should be enabled with the Configure checkbox ticked. This will activate AppLocker immediately once you accept the changes and close the dialog window!
Step 5: Common Pitfalls
- Default Rules Missing: One common mistake is attempting to create a single rule to block a particular application without using the default rules. This typically results in the user being unable to use any applications at all. Unfortunately, creating a simple rule to block a non-compliant app and calling it a day doesn’t work with AppLocker.
- User Installed Apps Blocked: The default rules do not cover user-installed applications, typically found in the AppData directory under the user profile, as opposed to system-wide applications stored in Program Files. While this is more secure, you will likely need to make some exceptions. You can whitelist all user directories using the example below (adjust as needed for your environment):
%OSDRIVE%\Users\*\AppData\*.exe
More info on file paths with AppLocker here. - Appx Packages Blocked: If you only enable one enforcement policy, such as executables, you may find that your Appx packages stop working. For example, Teams and Company Portal may be blocked, even though their install locations (C:\Program Files\WindowsApps) are whitelisted in the default rules, and you are not enforcing Appx restrictions. You’ll need to enable all enforcement policies together for the best results to ensure this doesn’t happen.
- Whitelist Organization Publishers: Don’t forget to whitelist your organization as a publisher for applications in AppLocker if they publish their own apps. You can use an existing installer as a reference and scope the custom role to apply to all apps by that publisher.
Deploying AppLocker Policies
AppLocker policies you create locally can be exported as an XML file and imported into Group Policy on Active Directory. They can also be imported into an Intune custom configuration profile and deployed to MDM devices, allowing for streamlined management of application execution policies.
Using AppLocker to create custom Intune policies for Windows
How AppLocker Prevents Ransomware
If you are testing with the default rules, you should find that all applications can run when installed to Program Files in the system scope, while portable apps, installers, and user-installed apps are blocked. By ensuring that only approved corporate apps can be run on the system, malicious apps are prevented from executing. For instance, random applications executed from the Downloads folder will fail. If your users don’t have local admin rights, they won’t be able to write or manage applications in Program Files. Instead, you can use Company Portal with Intune to deploy managed apps on their behalf. Thus, AppLocker is an efficient way to prevent applications from running if they install to the user profile rather than Program Files. This makes AppLocker effective in preventing ransomware execution, which can occur from inadvertent user interaction with a malicious installer or application.
Bonus: EPM and AppLocker
Microsoft Endpoint Privilege Management (EPM) works well with AppLocker, allowing standard users to elevate applications that would otherwise be blocked. If you have the resources for deploying EPM, it can simplify the management of approved applications by reducing the need for extensive whitelisting in the AppLocker configuration files.
Conclusion
AppLocker can be intimidating, especially if configured incorrectly. However, with careful testing and planning, you can avoid major troubleshooting headaches. Although AppLocker is an aging solution and Microsoft has stated it will no longer receive feature updates, it remains a useful tool for enterprise environments (and will continue to receive security updates). The spiritual successor, Windows Defender Application Control (WDAC), is worth exploring in a future blog post. Thanks for reading!
IdentityPoint 