Bypassing Modern Antivirus and EDR: A Primer
Ten years ago, evading Antivirus (AV) was relatively straightforward. Traditional AV relied heavily on static signatures—comparing the hash or the byte sequence of a file against a database of known malware. If you changed a few bytes of a malicious payload or packed it with a simple crypter, the signature changed, and the AV remained silent.
Today, the landscape is entirely different. Modern Endpoint Detection and Response (EDR) solutions (like CrowdStrike, SentinelOne, or Microsoft Defender for Endpoint) don't just look at files on a disk; they watch how programs behave in memory, monitor API calls in real-time, and analyze network telemetry.
For penetration testers and red teamers, executing code on a modern Windows endpoint is a high-stakes game of cat and mouse. In this primer, we will explore the core concepts used to bypass modern EDR solutions.
The Shift to In-Memory Execution
The first rule of modern malware execution is simple: Don't touch the disk.
If you drop a malicious .exe file onto a Windows desktop, the EDR will intercept the file write, scan it statically, and upload it to a cloud sandbox for dynamic analysis before it ever runs.
Instead, modern attacks rely on Reflective DLL Injection or shellcode injection. The attacker uses a benign, trusted process (like PowerShell, MSBuild, or a custom loader) to allocate a block of memory, copy the malicious payload directly into that memory space, and execute it as a thread. Because the payload only exists in volatile RAM and never touches the hard drive, static disk scanners are completely bypassed.
Blinding the EDR: API Unhooking
If the payload is running in memory, how does the EDR detect it? The answer is User-Mode API Hooking.
When a program needs to do something sensitive—like allocate memory for injection (VirtualAlloc), create a new process, or write to another process's memory—it must ask the Windows operating system to do it via an API call in ntdll.dll.
EDR solutions inject their own monitoring DLLs into almost every process on the system. They intercept (or "hook") these sensitive API calls. When your malware calls VirtualAlloc, the EDR intercepts the call, inspects the requested memory, realizes it contains malicious shellcode, and kills the process.
The Bypass: Direct System Calls (Syscalls)
To evade these hooks, attackers utilize Direct System Calls. Instead of asking ntdll.dll to allocate the memory (which the EDR is watching), the attacker's malware contains the raw assembly instructions required to talk directly to the Windows Kernel (Ring 0). By bypassing ntdll.dll entirely, the EDR's user-mode hooks are left blind, and the malicious action occurs undetected.
Evading Sandboxes: Environmental Keying
When EDRs encounter an unknown file or suspicious script, they often upload it to a cloud sandbox—an isolated virtual machine where the file is detonated and its behavior analyzed.
To prevent malware from revealing its true nature to the sandbox, attackers use Environmental Keying (or Guardrails). The payload encrypts itself and will only decrypt and execute if specific, hyper-local conditions are met.
For example, the malware might check:
- Does the Active Directory domain name match
TargetCorp.local? - Is the system's memory greater than 4GB (sandboxes often have limited resources)?
- Does a specific proprietary application exist in
C:\Program Files\?
If these conditions are not met, the payload assumes it is in a sandbox or a security researcher's lab and simply exits silently.
The Nuclear Option: BYOVD (Bring Your Own Vulnerable Driver)
If an EDR is particularly aggressive, sophisticated threat actors (like Ransomware syndicates and advanced APTs) use a technique called BYOVD.
In Windows, drivers run in kernel space (Ring 0), the most privileged area of the operating system. Security products also run in Ring 0 to protect themselves from being terminated by local administrators.
An attacker will drop a legitimate, cryptographically signed hardware driver (perhaps an old driver for a graphics card or a motherboard utility) onto the system. Because it is signed by a trusted vendor, Windows allows it to load. However, the attacker knows this specific driver contains a vulnerability (like an arbitrary memory read/write flaw).
The attacker then exploits the vulnerable driver from user-mode to execute code in the kernel, allowing them to forcefully terminate the EDR's core processes or blind its telemetry sensors completely.
Conclusion
Bypassing modern EDR is no longer about simple obfuscation; it requires a deep understanding of Windows internals, memory management, and kernel architecture. While EDRs provide incredible visibility and defense, they are not a silver bullet. A skilled adversary who understands how the security sensors work will always find a way to navigate the blind spots.