AppLocker Bypass Checker

One of the Default Rules in AppLocker allows everyone to execute everything in the folder C:\Windows:


The reasoning behind this must have been that a non-admin Windows-user should not have write permissions anywhere in that folder. But as it turns out that is not the case.

I wrote a PowerShell script that tries to copy an executable to every folder in Windows and (if the copy succeeds) tries to execute it. At the end it will show what folders are at risk for AppLocker bypass and must be managed accordingly. Preferably by creating exceptions in the default Allow Rule or by adding a new Deny Rule that includes these folders. I would not recommend messing with the NTFS permissions on folders in C:\Windows (or where your %systemroot% is located).

I chose mstsc.exe as the executable (it’s short for Microsoft Terminal Services Client), since it is small, built-in and can run multiple instances. During the test you will see instances of this showing up:


Do not close them manually, as they are enumerated by the script at the end. They will be closed automatically by the script.

Remember to run the script as a user. Admins have another Default Rule that enables them to run anything anywhere. And if you wanted to bypass AppLocker as an admin (in case the default Admin Rule was removed) you could just stop the service “Application Identity” that AppLocker relies on to function properly.

You might have an Execution Policy that prevents you from running the script. In that case you have (at least) two simple options:

  1. Open the script in Windows PowerShell ISE (by right-clicking the script and choosing Edit), select the entire script with Crtl-A and then press F8 to run the selected code.
  2. Run Powershell with the option “-ExecutionPolicy Bypass”:

This is also a good reminder that Execution Policy is NOT a security feature. It is meant to prevent accidental execution of scripts. Here are 13 additional ways to bypass it:

I did notice that I got these warnings when bypassing Execution Policy (but not when changing the Execution Policy to RemoteSigned). Just ignore them as well:


You will see some errors when the script could copy a file, but not execute it:image
You can ignore these too.

At the end you should see something like this (in this case it was run on a Windows 10 build 10565):


Download the script here:

Don’t forget you might need to validate all the Program Files subfolders in a similar fashion if you keep that Default Rule.

Standard Disclaimer: I am NOT a coder. I am not responsible for what this script does. Do a code audit of the script if you run it in a sensitive environment.

Please leave any feedback you have as a comment to this post.

About Tom Aafloen

IT Security Advisor @ Onevinn
This entry was posted in AppLocker. Bookmark the permalink.

14 Responses to AppLocker Bypass Checker

  1. Pingback: Protecting Windows Networks – AppLocker | DFIR blog

  2. Pingback: Applocker:Windows网络保护之应用程序控制策略-IT大道

  3. Pingback: Applocker:Windows网络保护之应用程序控制策略 | 小橙子科技

  4. Pingback: Applocker:Windows网络保护之应用程序控制策略 | 邪恶十六进制

  5. Pingback: Applocker:Windows网络保护之应用程序控制策略 | 安全渗透军火库|SHENTOU.ORG

  6. john316 says:

    great stuff will try to use it tomorrow on a pritty hard(ened) win7 client. I also have restrictions on PS modules and scripts but well these can be C&P to console directly – not nice but working.

  7. Pingback: AppLocker Bypass Checker –

  8. J.L. says:

    You should have used notepad.exe in the example, it is on most every windows system.

    • Tom Aafloen says:

      Hi Joris!
      That was my obvious first choice, but notepad.exe unfortunately has dependencies to other files and will in fact not even execute when moved/copied to another location. Try it yourself by simply copying C:\Windows\notepad.exe to the Desktop and try to run it from there. Since I enumerate running instances of the used application at the end of the script I had to use a common program that can execute when moved and the choice fell on mstsc.exe. Other executables (without dependencies) should work equally well.

  9. chrom says:

    What about the fact that mstsc is a signed microsoft binary and the default rules let these run from anywhere?

    • Tom Aafloen says:

      Signed apps are more trusted by the OS in general, but if I recall correctly, there are no certificate based rules in the AppLocker default rules.

      • chrom says:

        you are right, the default executable rules don’t whitelist signed microsoft binaries.
        I got ahead of myself, they allow only installers by default.
        Really helpful and nice post!

        (you may delete my duplicate comment below, i pressed reply at the wrong place)

  10. yaks_77 says:

    excellent script, short and neat!
    I wonder if the list of paths resulted could be used as path exceptions not only for executables but also for DLL and scripts.
    at the moment I have a different list of them extracted from a nice document from the Australian government

  11. Daniel Schell says:

    You’ll probably find this free tool useful as well. It will enumerate deviceguard and applocker policy from any endpoint, highlight weak rules, and will run exe and dll execution tests on every folder on the system to determine gaps in policy.

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 )

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