How to Bypass Windows AppLocker

hack windows app lock

Hello, today we will talk about Applocker bypass techniques in a Windows environment. What is Applocker, how does it protect systems, and more importantly, how to bypass this security feature. So many issues to tackle in this article!

What is Applocker?

Applocker is a software whitelisting tool introduced by Microsoft starting from Windows Vista/Seven/2008 in order to restrict standard users to only execute specific applications on the system. e.g.: “Alice can run explorer.exe, Bob, however, cannot!”


If you are conducting penetration tests, you will likely find Applocker on very sensitive machines: industrial computers, ATM, business workstations, etc.

How does it work?

To activate Applocker on your testing machine, start the Application Identity service (Administrative Tool -> Services), then open the Group Policy Editor (gpedit.msc on a local machine or gpmc.msc on a domain controller). Browse to “Application Control Policies” in “Security Settings”:




Click on “Configure Rule Enforcement” to choose which kind of filtering to perform. As you can see, Applocker covers five types of applications:

• These are regular .exe and .com applications (cmd.exe, ipconfig.exe, etc.)
• Windows Installer files (.msi, .msp, .mst), typically used to install a new software on the machine.
• Script files with the following extensions .ps1, .vbs, .vba, .cmd and .js.
• Packaged Apps installed through the Microsoft Store
• DLL files (.dll and .ocx in the advanced tab).

In this tutorial, we will solely talk about the most commonly deployed restrictions in real world environments that is rules on executables, installers and scripts.

For each of the five categories mentioned above, we can define rules governing their usage based three criteria:

• Execution path: e.g. default Applocker rules allow any executable and script present in “C:\Windows” and “C:\Program Files”. It must do so – at least for some programs – otherwise the system will have trouble booting.
•  

 

• Publisher information: some executables (Windows binaries for instance) are signed using the vendor’s public key. Applocker can rely on this information to deny/allow executables to run. This feature is rarely used.
• File hash: Applocker stores MD5 hashes of allowed (or forbidden) files. Every time a program runs, Applocker checks its MD5 and decides accordingly. These rules can consume a good deal of memory, so they are mostly used to forbid some “dangerous” executables.

This might seem like a lot of knobs to tweak. It is. Configuring Applocker is not for the faint of heart. To make this tutorial most interesting, we will start with a basic configuration and harden it as we improve our hacking skills. Let’s get started!

Naive Setup

Say an admin sets up the default Applocker rules only: no standard user is allowed to run files (executable, installer or script) outside of the classic “C:\Windows” and “C:\Program files” folders. How to run say a meterpreter.exe on the machine with a standard account i.e. no admin privileges on the box?


One way to go is to search for default allowed folders with write access. The idea is to copy the executable into an allowed folder, then launch it from there. Straight forward. Doing it manually can take a bit of time, so how about an automated PowerShell script?
The execution path restriction also applies to scripts in this case, so we need to be crafty about this. First, we load the script’s content using the Get-Content command, convert it to a string then forward it to the Invoke-Expression command which executes it, no questions asked!





On a default Windows installation, “C:\Windows\Tasks” and “C:\Windows\tracing” usually pop up as being writable by everyone! Copying our executable (mimikatz.exe, meterpreter.exe, etc.) there for instance bypasses default Applocker lockdown:





One might argue, quite correctly, that .exe files are over-rated and that we can perform all attacks with native Windows’ most powerful tool PowerShell. That’s very true and by using Invoke-Expression we bypass any execution path restriction. Yet, there are some cases when we need to run a simple exe file because it is that simple: a recompiled malware, custom tool, etc.


If we can’t find a writable directory allowed in Applocker, we need to resort to other means to run executables. One such method is to load the .exe file in memory, then launch it by jumping to its entry point. No execution path, no Applocker rule triggered!


We first store the executable, mimikatz.exe in this case, in a PowerShell variable:

PS > $ByteArray = [System.IO.File]::ReadAllBytes("C:\users\richard\desktop\mimikatz.exe");

Then use the Invoke-ReflectivePEInjection function from the PowerSploit framework to load it in memory and jump to its entry point.

PS > Invoke-expression(Get-Content .\Invoke-ReflectivePEInjection.ps1 |out-string) 

 PS > Invoke-ReflectivePEInjection -PEBytes $ByteArray

We can thus effectively bypass any Applocker rule based on Execution paths.

Tightening the grip

 

Our savvy admin knows its configuration has a few holes. He tightens the grip a bit further by restricting access to basic Microsoft tools like cmd.exe and PowerShell.exe.





We cannot use custom scripts (.cmd, .js or .vbs scripts) to execute code because they are only allowed to run from restricted folders (previous rules). But, remember the main issue with blacklists: we always miss something!
In this case for instance, the admin denied classic Windows 64-bit tools but totally forgot about 32-bit files in the “C:\Windows\SysWOW64\” folder. To execute PowerShell for instance, we simply run it from that folder.





Once we have access to a PowerShell prompt we can load executables and scripts in memory and execute them as we saw earlier.

Moreover, performing a search for powershell.exe across the system usually yields other versions of this file may have a different hash from the one banned by Applocker:


Say the admin tracks and blacklists every instance of powershell.exe, powershell_ise.exe, cmd.exe… are we done? Not quite. There are other means to execute code on Windows. Remote Procedure Calls for instance provide alternative ways to interacting with the system without using classic command line tools. The utility “C:\Windows\System32\wbem\wmic.exe” can be used to perform such actions.


Sure we cannot spawn a PowerShell prompt through WMIC, but it still offers an environment to get interesting information about the system in order to perform a privilege escalation:

Locked down

Our admin grew tired of legit Microsoft tools used in such an evil way so he blocked all the previously mentioned binaries (and some more) to completely lock down the system. No more cmd.exe, powershell.exe, wmic.exe, etc. That seems like a bit of a pickle, but let’s go back to the basics for a second. AppLocker recognizes powershell.exe based on the hash of the file. Which means if we grab a copy of powershell.exe with a different hash, we win! We cannot take an executable (extension .exe) because these files are only allowed to be launched from legitimate windows folders. Never mind, we have other PE type files we can use: DLL files! We can find for instance a DLL implementation of PowerShell at the following URL.


We download it to a random folder, then launch it using the C:\windows\system32\rundll32.exe utility. To execute a DLL, we give it the name of the DLL and its entry point function, in this case the main function: rundll32.exe PowerShdll.dll,main





Perfect! We can now run any executable/script we want.

Conclusion

 

Obviously, the conclusion is to apply protection on DLL files as well as executables. That’s entirely true, however, it requires a lot more work to identify all legitimate DLLs used by business applications on the machine. Not to mention the notable decrease in performance caused by such a systematic check each time any program loads a DLL! We can find ways to thwart DLL whitelisting using the same spirit as the tricks outlined in the above chapters, but that will be the subject of a future article. Until then, hack safely!