Hardening AppLocker

In this last part of my AppLocker series, I explain how you can harden AppLocker. Although AppLocker can dramatically reduce the amount of work required to secure your network, it doesn't mean that AppLocker doesn't need maintenance. Your job is not just adding rules but also keeping AppLocker safe against found weaknesses; that is, you have to harden AppLocker.
Latest posts by Sami Laiho (see all)

First, we'll need to make sure that your path rules don't leak. What I mean by this is that correctly developed software doesn't add write permissions to the Program Files or Windows folders, but very often software is not developed properly. This includes Microsoft as well—when it comes to the Windows folder, for example.

When you allow Program Files and your end users don't have admin rights, your AppLocker is super easy to manage. But your job for every folder you allow is to make sure that the users really can't write. And if they do, you have to add those folders as exceptions to your rules.

The easiest way to do this is to use AccessChk.exe from Sysinternals. You can use it as in the picture by adding parameters as follows:

  • exe -s -w Users "C:\Program Files\"

Where the parameters are as follows:

  • S = Recursive
  • W = Write permission
  • Users = To group to check for having permissions
  • "C:\Program Files\" = The folder to check
AccessChk can find out whether limited users have write permissions to an object in a container

AccessChk can find out whether limited users have write permissions to an object in a container

In this example, we see that users can write to the AppExample1 folder. So we need to add this as an exception. Remember that an exception is not equal to Deny. It just means that a rule will not apply to it. It could still be allowed by another rule.

You should always check whether this really is a problem. If you see the permissions for AppExample1, you see that Everyone has write permissions, which means it's really a problem.

In this example, the developer has given the app excessive permissions

In this example, the developer has given the app excessive permissions

On the other hand, TeamViewer has fixed this by adding an explicit Deny for executing anything so it's not a problem if you check out the permissions.

Some developers have fixed the leakage by adding explicit Deny ACLs

Some developers have fixed the leakage by adding explicit Deny ACLs

There is also a known issue where someone can abuse the fact that a folder in NTFS is just a file with the attribute D. Every file has an alternate data stream (ADS) that can be used to hide data or binary. This allows an attacker to run binary from a folder's ADS.

To block this, whenever you add a folder exception, such as C:\Windows\Temp\*, you also need to block the ADS using the format C:\Windows\Temp:*. Making sure your containers don't leak is a check you need to do for every folder rule you add, not just the default rules. This will also be different for every environment, so I can't do this for you.

Exceptions on an AppLocker rule mean that rule does not apply to them

Exceptions on an AppLocker rule mean that rule does not apply to them

One of the best experts in AppLocker is a Norwegian guy called Oddvar Moe. Oddvar has an updating batch file for checking for leakage. You can find it on GitHub:

Oddvar Moe's AccessChk.bat can be downloaded from GitHub

Oddvar Moe's AccessChk.bat can be downloaded from GitHub

Another job for you is to follow my basic rule in security: If you can't block, contain. So some files we need to allow as Windows won't work without them, such as RunDLL32.exe. The problem is that this is known as a LOLBin—Living Off the Land Binary. LOLBins are trusted binaries that can be used to run any external code. Some of them can be blocked, as you can see in this Microsoft guide. However, some we need to allow.

Those that can't be blocked we need to contain, so that they can't talk to the network to get a payload or commands from the attacker. This needs some help from your firewall. Here I have an example of my firewall rules:

AppLocker can help contain dangerous binaries that can't be blocked

AppLocker can help contain dangerous binaries that can't be blocked

You should block at least:

  • Rundll32 & regsvr32 (32 and 64bit)

You might also consider:

  • PowerShell (this is diamond for your security)
  • Scripting host (since most companies block PowerShell from limited users, the bad guys are moving back to VBScript, etc.)

If you only have one subnet, you can block just INTERNET, as I've done. But if you have more subnets, you need to block outbound connections by default and only allow correct destinations.

The last thing you need is to be active on Twitter and follow the people who will tell you when problems arise. Here is my list of tweeps to follow:

  • @Oddvarmoe
  • @subTee
  • @mattifestation
  • @enigma0x3
  • @aionescu
  • @tifkin_
  • @bohops
  • @PhilipTsukerman
  • @samilaiho 😉

Here are a few links for you to look at:

I love AppLocker and whitelisting in general, and I hope this series is useful for your AppLocker implementation.

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads by becoming a member!

2+
avatar
Share
0 Comments

Leave a reply

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

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account