Protecting Windows Networks – AppLocker

Application Whitelisting is a powerful technology that could protect us from unknown malware, but it never really take off. One of the main reasons for that – it is hard to configure and maintain. Another – there are quite a few known bypass techniques, so it can’t stop determined attackers. Although, there are multiple commercial products for this, we’re going to look at built-in AppLocker technology that provide some basic features for free.


To get AppLocker running you need to enable a corresponding service.

To do this via GPO go to:

Computer Configuration →Policies → Windows Settings → System Services

And set service Application Identity to Auto:


Then go to Application Control Policies for configuration.

There are in fact two types of whitelisting applications available – old Software Restricted Policies and newer AppLocker. Read more about differences between the two here.

AppLocker allows you to setup the following rules:

  • Executables

  • MSI install files

  • Scripts

  • DLLs

Then you can either allow or deny something based on three conditions:

  • Path – is straightforward, allow or deny execution from folder.

  • File Hash – Allow or deny based on file hash. It’s not very useful, as it calculates hash from files themselves and you can’t simply say block this md5 hash without having file itself.

  • Publisher – the most flexible, allow or deny execution based on digital certificate publisher.

You could also add exceptions to the rules, this allows you to create rules like Allow everything in C:\Windows except cmd.exe.


Basically, there are two approaches to AppLocker – you either block everything and only allow certain stuff(whitelist) or you allow everything and block only certain stuff(blacklist).

Here is whitelist:


Here is blacklist:


The first useful thing you can use AppLocker for – as additional information source. Even if you don’t want to use AppLocker, you could configure and use it with Audit Only mode. This way, you will get information on every executable, dll and script executed on the system:


Hash is hidden in XML version of the log. Unfortunately, AppLocker use SHA256 Authenticode and not the file hash for EXE and DLL, so it’s not useful for us. You can’t look it up on Virustotal or anything.

Blocking stuff

There are couple of things to keep in mind when you want to block stuff:

  • You must be careful with rules like allow Publisher = Microsoft as this would allow tools like Sysinternals to run as well.

  • When using Path condition, you need to audit access rights to this folder. If anyone can write into your trusted folder, than AppLocker policy doesn’t make any sense and can be trivially bypassed.

  • You might be tempted to block execution from %TEMP% folders and it can work really well. However, it can also break a lot of stuff for your users, so test this thoroughly first. You also need to whitelist stuff like Dropbox and Chrome that run from AppData folder itself. Also, don’t forget to block C:\temp, C:\ProgramData, Recycle Bin and couple others writable folders. Personally, I still feel it is way too much work to figure out all the legitimate stuff that need to run from TEMP, but you could try.

  • Local admin and AppLocker do not mix. If your users have admin rights, they can add rules that will overwrite any AppLocker rules with their own, bypassing any restrictions you place.

AppLocker limitations

  • Anything run in memory can’t be controlled by AppLocker, obviously.

  • It can’t control Office macroses

  • It can’t control HTML Applications

  • Default rules is not as secure as you would think. You would think user can’t write into Windows folder and generally this is true, however there are a few folders that allow user write access, thus allowing easy bypass with default rules. Check your system with this script or use Sysinternals accesschk – accesschk.exe -d -w paranoid C:\Windows\*


  •  Scripts is not tightly controlled, if interpreter is allowed to run – you could simply copy and paste commands from text file and run your script this way. I also did a test on three different machines and on Windows 7 machines for some reason powershell scripts is not blocked with default settings, not quite sure why. However, on Windows 8.1 it works as intended.

Bypassing AppLocker

Unfortunately, there are quite a few of working bypasses for AppLocker, making it that less effective:

  • If you have local admin rights, you could add a local rule that allows execution of everything. This will overwrite any domain based policies.

  • You could simply abuse write privileges and move your executable into C:\Windows somewhere. This will bypass any restrictions with default rules.


  • You could use HTML applications. Here is example HTA that use powershell for reverse shell:


  • You could use rundll32 trick to execute various OS functions as described here. Even better, you could call javascript code via rundll32 and execute arbitrary code. This same trick was used by infamous Powerliks malware, but I actually saw it even earlier on engagement, where one well known APT group used the same thing in their own malware. Unfortunately it can’t be blocked.


  • You could use interpreters directly(same tactic for powershell and VBS):



  •  In-memory payload is not affected, so if nothing dropped on disk – it won’t be affected by AppLocker. Exploiting some trusted process or using various reflective injection techniques can be used for this.

  • DLL hijacking of trusted applications can be used unless you have strict DLL AppLocker rules.
  • There is also a few more, that require specifically crafted .NET application. Check out work by Casey Smith in Reference section for more information.

Mitigating bypasses

Some bypasses could be fixed with correct configuration:

  • Either revoke write access for users in Windows folders(could break some stuff, I didn’t test) or just add all user writable folders into exceptions. Same for Program Files.



  • Block mshta.exe. This will prevent execution of HTML Apps.


  • Block powershell.exe, cmd.exe, cscript.exe. This can work if you and your users don’t use any scripts that leverage those, otherwise it is not very realistic, because it will break whole bunch of stuff like logon scripts and any kind of rolled out automation. Be aware, that powershell could be called via any net application without powershell.exe, so either block powershell DLL(C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0\System.Management.Automation.dll) or block unknown executables and powershell.exe to block it effectively.

  • Although rundll32 can’t be blocked, if you have command line logging enabled – you could catch this pretty easily, just alert on rundll32.exe javascript. I’m not aware of any legitimate activity that would invoke javascript via rundll32.

  • As for bypasses described by Casey Smith, at first glance you could block all tools he abuses. But this potentially could break some .NET apps, I don’t really known if those tools are used in normal operation. This require additional testing. At the very least, monitor execution of those binaries.


Despite having limited functionally and known bypasses, I still think there is value in using AppLocker, especially on single purpose machines like ATMs, kiosks, POS terminals and various servers. It can be a challenge to maintain, especially on end user PCs, but even then you could use it in blacklist only mode or just audit and still get value.




  1. HI
    I have just started reading your blog after coming here via the Kerberos flaw post. Hmm. Hats of hombre and here’s my gun as well. I feel so disarmed reading your stuff.

    But I am after more as you can gather not to hack but to protect. I recently found out that however much I put in my GPOs to stop access to the c: drive you can simple bypass it by using \\localhost\c$ or some such thing. I know this works in one shape or the other because one of team members showed it to me.

    This must be of the least and of trivial concern to you given that you seem to be using techniques and methods way above this tom foolery. Is there a way to stop or get around the above flaw ?

    Can I leave the bar now ?

    Thanks and Regards


    1. Hi,

      Well, if your concern is network access – you could simply disable admin shares. It can broke some apps and services, so test it first.

      NET SHARE C$ /delete
      NET SHARE D$ /delete
      NET SHARE admin$ /delete

      But only admin users can access them anyway…

      In terms of local access, you can’t really restrict it for admin users as they can overwrite any ACLs you put in place, regular user accounts can’t do much by default if you don’t grant them excessive privileges yourself. So, not sure what the question is…


    2. Just… wow. Do you wear a trenchcoat with your fedora? I think reddit needs a hero like you.


  2. […] this tests all folders for executability, run as standard user Protecting Windows Networks – AppLocker | DFIR blog general advice Remove admin rights from everyone, and apply the exe restrictions to administrators […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: