The origin of the term blacklist goes back at least to 1884 when it was used to refer to an employers’ list of workers considered troublesome, usually for union activity. The term whitelist was coined around the same time and refers to a list of people or organizations considered worthy of approval or acceptance, or a list of things deemed safe, acceptable, or desirable. So much for etymology (yawn), now let’s get back to IT. A whitelist is used in the IT industry in several capacities. You can have email whitelists for trusted senders that won’t get filtered out as spam. You can have LAN whitelists to control which systems are allowed on a network based on their MAC addresses. And you can have application whitelists, which are a security feature used to determine which programs are allowed to run on your system. Microsoft Windows has included built-in support for application whitelisting since Windows 7 using a feature called Windows AppLocker, and that’s what this present article is about. To learn more about AppLocker I’ve invited Oddvar Moe, an IT-Pro who has worked for more than 17 years in various IT capacities to explain how organizations can benefit from using it and how it can be configured. Oddvar is a Cloud and Datacenter Management MVP who works at Advania in Norway as a chief technical architect with focus on Windows security, both offensive and defensive. Oddvar is a Microsoft Certified Trainer and also a certified penetration tester (GIAC Penetration Tester). He has a passion for security and he loves to share his knowledge and does that either through his blog, writing articles, speaking at conferences, scripting, or on social media. For more information about him see his blog, his MVP profile, or his LinkedIn profile. You can also follow Oddvar on Twitter. Let’s now pay attention as Oddvar walks us through the basics of setting up application whitelisting on Windows computers.
Benefits of application whitelisting
I bet you all have heard the words a million times before, but what does it actually mean in terms of implementation and maintenance of application whitelisting? I will not lie to you, the truth is that application whitelisting can be hard to maintain over time and there are certainly obstacles on the way. But the benefits of having this implemented in a proper manner really makes it all worth it.
I don’t know how many customers I talked to that have removed the local administrator rights for their end users and they think that they now are finally safe for all the cruel attacks that are happening. Removing local administrator rights from your end users is something that can be really hard to achieve and you should give yourself a pat on the shoulder for doing it, but this is just the beginning of getting better security in place on your workstations.
Most common question
My most common question to my customers is: “Is it possible for non-admin end users to install software on their computers?” To my big surprise, people think that the end users are not able to do that. Did you know that most modern installers these days actually detect if the user is a local administrator or not and even asks if you want to install the software even if you are not a local administrator?
The best example is Google Chrome. If you start the installer with a user who is not a local admin, the UAC prompt will come and ask for credentials to escalate the privileges. If you click on cancel, the installer will actually ask if it should be installed even if you do not have local admin rights. This is illustrated in this screenshot:
Why am I telling you all of this you might ask? The reason is that if the end users can run and install software, then so can the attackers. Therefore we need application whitelisting to prevent this from happening. In this article, I will focus on AppLocker, but there are many other products out there that offer similar protections. Microsoft has, for instance, Windows Defender Application Control (Device Guard).
Configuring AppLocker
If you have an enterprise version of Windows in your organization, you already have a license for AppLocker and I would recommend that you at least configure it with basic settings. Just by implementing simple rules you can eliminate most of the automated ransomware attacks out there.
Let me get you started on a basic setup of AppLocker. First, you need to make sure your clients are running an enterprise version of Windows (Windows 7 or above). Next, you need to make sure they are a part of an Active Directory domain. You use Group Policy in Active Directory to configure AppLocker centrally. Okay, you got the prerequisites, now you need to create a Group Policy that is linked to the computers you want to apply AppLocker policies onto. This screenshot shows you how it looks like:
Inside this Group Policy, you need to configure how AppLocker should act. The settings for AppLocker are found under “Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Application Control Policies”.
There are five parts of AppLocker you can create rules for:
- EXE
- Script
- DLL
- MSI installers
- Packaged Apps
If you are missing DLL, you first need to right click on the AppLocker name and choose properties. From there go to Advanced tab and enable DLL rule collection. It has a warning stating that it will affect system performance. Based on my experience, this is not a problem. After you have enabled DLL rule collection it will be available together with the others.
Next, you need to right-click on the AppLocker name again and go to properties. From here you must choose how AppLocker should enforce the rules. You have the option to choose either Enforce rules or Audit only. When implementing AppLocker you often start by using Audit only to make sure you don’t break anything. After you have decided to go for either Enforce or Audit, you must configure the rules. This is done by right-clicking on the collection you want to create rules. I often start by using the Default rules. To do that just choose Create Default Rules and you get this:
That’s it, you have now created some AppLocker rules and there is just one more thing that needs to be configured in the Group Policy: the Application Identity service. This service must be running on the clients so that AppLocker will run. Within the same Group Policy, you can specify this by going to Computer Settings \ Policies \ Windows Settings \ Security Settings \ System Services \ Application Identity and setting it to Automatic.
There you have it! You now have a basic AppLocker setup going. If you choose to only go for audit, you can review the logs in the Windows event viewer under Applications and Services log \ Microsoft \ Windows \ AppLocker.
The default rules will make sure that only files placed within C:\program files, C:\program files (x86) and C:\Windows will run. Many malware types place binary files within the Appdata of the user. If the malware can place files there, AppLocker will prevent it from running. Assuming of course that you choose to enforce the rules.
Another approach instead of using folder locations is to use the digital signature as something you trust. This can, for instance, be that you trust every binary that is signed by Microsoft. Creating this rule can be done by creating a publisher rule when you define a new rule under one of the different sections.
Now it’s your turn
In my opinion, application whitelisting is a very important part of client security. We need to control the things that are allowed to run on the clients and prevent unwanted code to run. Implementing application whitelisting will not only increase your security, but it will also increase the stability on your clients since they are not able to add and run programs you do not allow. Hopefully, this will get you started with application whitelisting and give you a big weapon in your battle against cyberattacks. And don’t be afraid to reach out to me if you have any questions by posting a comment at the bottom of this article.
Photo credit: Pexels
Do you know a list of trusted publishers we could download tot fill the executables rules list ????
Well, there’s Microsoft for one I guess…
Where does Microsoft publishes the trusted DLL/EXE list?
AFAIK Microsoft doesn’t publish a list of trusted third-party EXE/DLLs, you need to create such a list yourself based on what trusted software you already have deployed or want to deploy in your environment.
Useless because it needs an Enterprise version of OS, which you can’t buy unless you’re a large organization. Typical Microsoft 🙁
Totally not true Dennis. Small businesses can purchase.
Uh-oh. Using the default rules is a very bad idea. Those include user-writable locations. That means, whatever the user places there (or a malware copies there) will be startable. NEVER use the default rules.
“While allowing an inexperienced administrator to safely interact with AppLocker, it does not
create a secure environment. The guidance provided in this document recommends that the
default rules not be used. By following the process in this document, an administrator can
safely create a highly tailored set of AppLocker policies without the need for the default
rules.
To reiterate, DO NOT ENABLE THE DEFAULT RULES”
Says who? Says Microsoft: https://www.scribd.com/document/173447840/AppLocker-Design-Guide
More specifically from https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-default-rules:
“You can use the default rules as a template when creating your own rules. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed to run.”