Bypassing AppLocker as an admin

I thought it would be useful to have a blog post about two different techniques you can use to bypass AppLocker if you are an admin on a host that has AppLocker enabled. The first technique that uses the GUI was briefly discussed in a tweet I posted a while back: https://twitter.com/Oddvarmoe/status/996147947975962624 

My goal with this post is to document that technique better, but also give you a new technique that has not been showed before, that you need to be aware of.

In these bypass technique examples the AppLocker Executable rules defined centrally are as follows (Default rules, without the admin rule):

The rest of the rules are defined with the default AppLocker rules (* under Windows and * under ProgramFiles).

 

Adding your own rules – the GUI way

If you are a local admin on a host there is nothing stopping you from adding your own rules. There are two ways of doing this. The GUI way of doing this is to start gpedit.msc on the host itself and adding them like showed in this GIF:

So, what you are basically doing here is to add AppLocker rules locally on that host. When AppLocker applies the rules it combines the rules defined in the Central Group Policy with the rules defined in the local policy on the host. Yeah, not ideal – I recommend considering adding this to remove any local rules added: https://oddvar.moe/2018/09/28/applocker-making-sure-that-local-rules-are-removed/.

 

Adding your own rules – with no GUI – (Stealthy as well)

Using a GUI is not always an option especially if you are working through a shell, so here I will go over a different method. When AppLocker (Application Identity Service) processes the Group Policies it places “AppLocker rule” files in c:\windows\system32\AppLocker. These files are used by AppLocker when you execute files to determine if the files should be blocked or not.

Another way of doing this is to manipulate the files that AppLocker places on disk under c:\windows\system32\applocker. To do that we first need to generate a wildcard rule that we will later plant on the machine we are attacking, Let me show you in this GIF.

So what I am basically doing here is to pre-create a rules file on  a stand-alone Windows 10 enterprise computer. If you do not want to generate the rule file yourself, it can be found here:

https://github.com/api0cradle/AppLocker-Stuff

 

Okay, so now we got the rule file, lets go ahead and plant it on a client that is protected (remember, you need to be an admin for this to work). For this to work you also need to reboot the client. I have not found a magic service to stop and start to get it to work without a boot. All you need to do is to copy the Exe.AppLocker file and replace the one in c:\windows\system32\applocker and then reboot.

Illustration:

The sweet thing (for an attacker) about doing it this way is that it does not show up in the GUI on the client, so you must manually inspect the files under c:\windows\system32\applocker to find this.

The files you plant are replaced as soon as you do a GPUpdate /Force or if someone changes the Central Group Policy (add/remove AppLocker rules).

After I was finished writing this blog post I also realized you can also just delete the rule file an achieve the same effect, but it might be harder to detect if you overwrite the rules file instead of removing it.

If you are battling with Group Policies re-applying with every Group Policy Refresh you can take a look at this blog post on how to stop that behavior:

https://www.trustedsec.com/2019/01/local-admin-access-and-group-policy-dont-mix/

 

Detection

This can be detected if you monitor changes to the files under c:\windows\system32\applocker. Updates to these files as far as I know is only updated if a group policy changes centrally or if you add your own local rules with gpedit. The timestamps on these files should also be the same. If there are variations it could indicate that someone placed a file there to bypass AppLocker. Another indication can be if one of these files are removed.

 

Conclusion

My conclusion has not changed since my last post about “AppLocker for Admins – Does it work?“. This post just illustrates another reason why AppLocker is not meant to protect admins.

Hope you enjoyed my post and feedback is always welcome.