Defender is a Suggestion

Windows Defender ships on every Windows 10 and 11 machine. It is the first thing operators worry about when they land on a box. It shouldn't be. Defender is excellent at catching people who download unmodified tools from GitHub and double-click them. Against anyone who spends thirty minutes on their payload, it folds.

This is not a Defender hate post. It does its job for what it is: a free, built-in antivirus. But operators treat it like a wall when it's a speed bump. Understanding why means understanding what it actually checks and where each layer breaks down.

The Detection Stack

Defender has five detection layers. Each one sounds scary on paper. In practice, they fall over in a predictable order.

Layer 1: Static Signatures

Defender scans files on disk and matches byte patterns against a signature database. If your binary contains a known-bad byte sequence, it gets flagged before it ever executes. This is the oldest detection method in antivirus and the easiest to defeat.

Change the bytes, change the verdict. Recompile from source. Encrypt your shellcode. XOR the strings. Strip debug symbols. Swap function names. The signature engine is doing exact pattern matching. If your binary doesn't contain the exact bytes it's looking for, it passes.

This is not sophisticated. String encryption and a recompile is all it takes. If you are getting caught at the static signature layer in 2026, the problem is laziness, not Defender.

Layer 2: AMSI

Already covered this one. AMSI runs in your process memory, you own that memory, and six bytes turn it off. If you are running native shellcode, AMSI never touches it. It only scans scripting engines: PowerShell, VBScript, JScript, .NET. If your stager is compiled C, AMSI is irrelevant. If it's PowerShell, patch it and move on.

Layer 3: Cloud Lookups

This is the layer that catches people off guard. Your binary passes static signatures locally, but Defender sends metadata (and sometimes the file itself) to Microsoft's cloud for deeper analysis. The cloud engine has better heuristics, sandbox detonation, and a broader signature set. On paper, this is Defender's strongest layer.

In practice, it's a network call. Network calls take time. If your binary executes before the cloud verdict comes back, the result defaults to clean. You are racing a REST API, and you get to pick when the race starts.

Several things work in your favour here. Environmental keying delays execution naturally. Sandbox checks add time before your real payload runs. A large binary takes longer to upload for cloud analysis. And if the target machine has limited or no internet connectivity, the cloud lookup never completes at all.

Layer 4: Behavioural Detection

This is the only layer worth respecting. Defender monitors runtime behaviour: API call sequences, process trees, memory allocation patterns, network connections. It builds a profile for each process and flags deviations.

But behavioural detection is still pattern matching. Defender looks for known-bad sequences, not arbitrary malicious intent. If your execution flow doesn't match a pattern in the ruleset, it passes. The patterns update, but they lag behind new techniques by weeks to months.

The trick is understanding what patterns exist in the ruleset and avoiding them. Use less common injection methods. Pick processes with broad behavioural baselines. Break up the classic allocate/write/execute chain with delays or alternative APIs. The behavioural engine is looking for sequences it recognises. Give it nothing familiar.

Layer 5: Tamper Protection

Tamper Protection prevents users and processes from disabling Defender through the registry, PowerShell, or Group Policy. It sounds like a serious obstacle. It is not. Tamper Protection stops you from turning Defender off. It does not stop you from evading it while it runs.

You do not need to disable Defender. You need to be invisible to it. Every technique in this post works with Defender fully enabled and Tamper Protection on. The goal was never to turn it off. The goal is to make it think nothing happened.

The Scoreboard

Here is what Defender catches and what it misses. Notice the pattern.

Every red row has one thing in common: zero effort. Every green row involved basic tradecraft that any operator should know. Defender catches the lazy. That is its job.

Why Defender Will Always Be Beatable

The same architectural constraints that make AMSI and user-mode hooks bypassable apply to Defender as a whole. It runs on the same machine as your code, in the same user space, with the same limitations.

The Real Fight Starts at EDR

Defender is the tutorial level. CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint (the enterprise product, not the free AV), Elastic Security. These run kernel drivers. They have dedicated threat research teams updating detection logic daily. They correlate events across your entire environment and flag anomalies that Defender would never see.

If you are spending weeks trying to bypass Defender, you are practising for the wrong exam. Get past it in an afternoon and spend your real effort on the EDR that's waiting behind it.

The Takeaway

Defender catches unmodified, publicly known tooling. That is all it needs to do for 99% of threats. But you are not 99% of threats. Basic tradecraft beats every layer: encrypt your payload, patch AMSI if needed, pick a good injection target, avoid known API chains. None of this is hard. None of this requires novel research.

The bar is on the floor. Step over it and focus on what matters.