EDR/AV Evasion & Detection Bypass

Why EDR didn't stop me — and why it sometimes stops you. EDR solutions are powerful when they work properly. The problem is, attackers adapt. You buy a tool and think you're protected. We change one number in a command and the tool doesn't see us anymore. Understanding how detection works — and where it fails — is key to real security.

How EDR Actually Works

Endpoint Detection and Response (EDR) systems are complex solutions that combine multiple approaches for threat detection. Understanding their architecture is the first step toward understanding their limitations.

EDR System Components

  • Kernel-level driver — The EDR core operates at the kernel level, with visibility into all system activities. It registers callbacks for processes, threads, module loading, registry keys, and the file system.
  • User-mode agent — The user-space component collects telemetry, communicates with the cloud, and executes blocking decisions.
  • ETW (Event Tracing for Windows) — Windows provides a rich telemetry source through ETW providers. EDR solutions subscribe to .NET, PowerShell, Security, and other providers.
  • AMSI (Antimalware Scan Interface) — Microsoft's interface enables script scanning before execution — PowerShell, VBScript, JavaScript, and .NET assemblies.
  • User-mode hooks — Many EDRs hook ntdll.dll functions in user space to intercept system calls.

Detection Methods

  • Signatures — Static detection of known patterns in files and memory. Fast, but easily bypassed with modification.
  • Heuristics — Rules that identify suspicious behavior based on a combination of factors (e.g., Word spawns PowerShell that contacts the internet).
  • Behavioral analysis — Learning normal behavior and discovering anomalies. Effective for unknown threats, but prone to false positives.
  • Machine Learning models — AI/ML classifiers that evaluate files and behavior. Limited by training data and interpretability.
  • IOC checking — Comparison with known indicators of compromise (IP addresses, domains, hashes).

Why Detection Fails

No security solution is perfect. EDR systems have inherent limitations that attackers systematically exploit.

The Signature Problem

Signatures are the fastest detection method, but also the easiest to bypass. A small change in a binary — adding NOP instructions, changing constants, rearranging functions — produces a completely different hash. Polymorphic and metamorphic malware automate this.

Living off the Land (LOTL)

Why bring your own tools when the system already has them built in? The LOLBAS (Living Off the Land Binaries, Scripts and Libraries) technique uses legitimate system components for malicious purposes:

  • PowerShell — Powerful scripting language with access to the .NET framework. Enables download cradles, reflection, in-memory execution.
  • WMI (Windows Management Instrumentation) — System management that enables remote code execution, persistence, and lateral movement.
  • certutil.exe — Intended for certificate management, but can decode base64 and download files.
  • mshta.exe — Executes HTA (HTML Application) files that can contain VBScript or JavaScript.
  • rundll32.exe — Loads a DLL and executes a function. Frequently abused for execution.
  • regsvr32.exe — Registers COM objects, but can load scripts from a URL (Squiblydoo attack).
  • msbuild.exe — Compiles and executes C# code without creating executable files.

Command-line Obfuscation

Detection often relies on command-line matching. Windows cmd.exe and PowerShell are surprisingly tolerant of obfuscation:

  • String concatenation — "power" + "shell" instead of "powershell"
  • Environment variables — %COMSPEC% instead of cmd.exe
  • Caret escaping — p^o^w^e^r^s^h^e^l^l is a valid command
  • Unicode substitution — Visually similar characters from other character sets
  • Invoke-Expression aliases — IEX, &, . operator

AMSI Bypass

AMSI is a critical component for detecting script-based threats. Bypasses exploit:

  • Patching amsi.dll in memory — Overwriting the AmsiScanBuffer function to always return AMSI_RESULT_CLEAN.
  • Forcing error — Causing an error in AMSI initialization that disables scanning.
  • Context hijacking — Manipulating the amsiContext structure.
  • Reflection — Accessing internal .NET methods to disable AMSI.

ETW Blinding

If the EDR doesn't receive telemetry, it can't detect. ETW providers can be disabled:

  • Patching ntdll!EtwEventWrite — Overwriting the function to immediately return success without logging.
  • Provider unregistration — Removing consumers from the ETW session.
  • Trace manipulation — Modifying trace session parameters.

Unhooking

EDRs often hook ntdll.dll functions to intercept system calls. Attackers bypass this:

  • Fresh ntdll copy — Loading a clean copy of ntdll.dll from disk or the KnownDlls section.
  • Direct syscalls — Calling the syscall instruction directly, bypassing ntdll functions.
  • Manual unhooking — Overwriting hooked functions with original bytes.

Process Injection and Memory-only Execution

Files on disk are easy targets for scanning. In-memory attacks are harder to detect:

  • Process hollowing — Creating a process in suspended state, replacing the image, and resuming execution.
  • DLL injection — Injecting a DLL into a foreign process (CreateRemoteThread, QueueUserAPC, SetWindowsHookEx).
  • Reflective DLL loading — Loading a DLL into memory without registration in the PEB.
  • Process doppelgänging — Abusing NTFS transactions to load code without detection.
  • Module stomping — Overwriting a legitimate DLL in memory with malicious code.

Blind Spots

Every EDR has areas it doesn't fully cover:

  • Pre-boot — Activities before the agent loads.
  • Excluded paths — Folders excluded from scanning (often AV installation folders).
  • Trusted processes — Some processes are exempt from monitoring.
  • Timing attacks — Activities during reboot or during agent updates.
  • Volume gaps — High event volume can cause telemetry loss.

Red Team Approach to EDR Testing

Quality EDR testing doesn't mean just running Mimikatz and checking if it's blocked. A systematic approach includes:

Testing Phases

  1. Reconnaissance — Identifying the EDR solution (processes, drivers, registry keys). Each EDR has specific characteristics.
  2. Baseline testing — Testing with known tools to confirm detection is working.
  3. Signature bypass — Modifying tools to avoid static signatures.
  4. Behavioral testing — Testing specific TTPs and identifying which trigger detection.
  5. Advanced evasion — AMSI bypass, ETW manipulation, unhooking, custom loaders.
  6. Full kill chain — Executing the entire attack to validate detection in a realistic scenario.

Important Caveats

EDR evasion testing must be:

  • Performed only with explicit written permission from the client
  • Documented with every technique used
  • Aimed at improving detection, not just proving bypass
  • Including recommendations for improving EDR configuration

What This Means for You

EDR isn't a silver bullet. It's one layer in a defense-in-depth strategy. Effective protection includes:

  • Proper configuration — Out-of-the-box settings are often not optimal. Tune according to your environment.
  • Attack surface reduction — Disabling unnecessary LOLBAS tools, PowerShell Constrained Language Mode, AppLocker/WDAC.
  • Network segmentation — Even if an attacker bypasses EDR, segmentation limits lateral movement.
  • Logging beyond EDR — Centralized logging that doesn't depend only on EDR telemetry.
  • Regular testing — Periodic testing with realistic attack simulation.
  • Incident response readiness — A plan for when detection fails.

My tests don't end with "EDR bypassed" — they end with concrete recommendations on how to improve your detection capability.