A thing I see a lot is that AppLocker is used to “protect” servers and prevent admins from doing certain things. In this post I want to go over what sort of security this gives so that everyone can see Pros and Cons. A thing to remember is that an administrator has all the rights on a system.

Since there are a billion ways of configuring AppLocker rules I will write about two different approaches, “Default rules for admins” and “Block wanted stuff”.

 

Default rules for admins

The first approach is to use just the default rules and remove the rules that allows the administrator to run everything from each section (DLL,EXE,MSI,SCRIPT).

The rules that is active now is everything that is placed under the “Windows folder” and “Program Files folder” are allowed to run on the server.

 

PROS

• If an administrator accidentally tried to execute a file (not in Program files or Windows) it will be blocked.
• If an administrator tried to run a script it must be placed under an approved path, making it harder to run. (unless he is advanced and uses a bypass) Hopefully that barrier will make the administrator think one more time before running the script.

 

CONS

• Administrators can place files under “Program Files” and “Windows” by default allowing them to run stuff just by moving files. Administrators have this permission.
• Administrators can run gpedit.msc on the local server and create their own rules that will merge with the centrally controlled AppLocker policy: https://twitter.com/Oddvarmoe/status/996147947975962624
• (Just to show an example) The administrator can change the service and disable the Application Identity service to stop AppLocker. (Start = 4)
  

 

Summary Default rules for admins

This type of setup only stops an administrator that accidentally tries to run things. It will not stop an admin that knows what he is doing. This kind of setup does not offer any great enchantments in security in my opinion other than stopping accidental clicking (and if that is your goal, great!).

 

 

Block wanted stuff rules

The second approach is something I have seen a couple of times. In this setup the default rules are often used and in addition a lot of things are blocked to prevent the admin from doing bad stuff. There are some advantages to this approach, but an administrator on a system is still an administrator. It is not that hard to bypass AppLocker as an administrator. If your goal is to totally lock down an administrator you have to create a long list of files to block in order to be successful. In my screenshots I will just show an example that prevents Internet Explorer and Edge from launching and that makes sense on a server. (No surfing Internet from servers!)

 

Blocking Internet Explorer

Blocking Edge

 

PROS (In addition to the ones under the Default rules for admins)

• Can block unwanted applications that you do not want your admins to accidentally launch.
• Can be very effective if you have a long list of all possible files that can bypass/disable AppLocker.
• Logs everything to the AppLocker log and you can identify who tries to do stuff on the servers.

 

 

CONS (In addition to the ones under the Default rules for admins)

• Turns an application whitelisting solution into an application blacklist solution
• Requires a lot of work to block everything. An administrator can in this example download a portable Chrome/Firefox or any other browser to perform web browsing.  How would they do that? Well, either copy the binary over RDP or use Powershell (invoke-webrequest http://site.com/browser.exe”). They can also go into the Microsoft Store and install a browser from there (unless you have blocked access).
    

 

 

Summary Block wanted stuff rules

AppLocker is not meant to protect admins from doing stuff, but it can be a great solution to “block” accidental execution of certain programs and obtain logging. The downside by adding a lot of things to block is that you suddenly have a lot things to maintain and a clever admin will almost always find another way to bypass things.

 

 

SUMMARY – AppLocker for Admins

In my opinion it has it’s use-cases (accidental clicking), but it should not be something that you consider as a security barrier for your admins. Instead I would focus on least privilege and try to limit the need to access the servers for admins (workflows, automation, Infrastructure-as-code++)
Also if you need to really lock down the servers for admins I would look into Windows Defender Application Control (Device Guard). Matt Graeber has a lot of great blogpost on WDAC/DG on his blog here that I recommend.

A ruleset I have not mentioned in this blogpost is that you can choose to only trust binaries/scripts from certain signers (Microsoft, Google, Adobe). I have tried to implement this, but the biggest problem with this:

• Microsoft has not signed all their Dll files (Causing unwanted situations sometimes) and then you need to add hash rules and path rules in addition to the signed rules. The ruleset will become very big very fast.
• Trusting everything signed from Microsoft is not a good idea since you can use their binaries to bypass AppLocker (Msbuild, installutil+++) and then you must also maintain a blacklist.
• Many “trusted” vendors has a lot unwanted utilities as part of their software packages that can be used to execute code.

My conclusion is that AppLocker is designed for end-users without admin rights and not administrators. Hopefully this blogpost gave you insights about how AppLocker works for administrators and the shortcomings.