- Hardening AppLocker - Thu, Jun 25 2020
- AppLocker Audit vs. Enforced mode - Tue, Jun 23 2020
- Creating AppLocker rules from the Windows event log - Wed, Jun 17 2020
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
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.
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.
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.
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:
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:
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:
- @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.