Your EDR Did Not Stop Me: Why Endpoint Detection Fails Against AD Attacks

I have a conversation with nearly every client before an internal penetration test begins. They tell me about their EDR deployment, their SOC team, their SIEM with hundreds of detection rules. They are confident that even if I get initial access, their detection stack will catch me quickly. Then I compromise their entire domain using legitimate protocols and built-in Windows tools, and their EDR never fires a single high-severity alert.

This is not a failing of any specific EDR product. It is a fundamental gap between what EDR is designed to detect and how Active Directory attacks actually work. Understanding this gap is essential for building a defense strategy that actually stops real attacks.

What EDR Is Good At

EDR products are excellent at detecting malware execution, suspicious process behavior, known attack tool signatures, and anomalous endpoint activity. If I drop Mimikatz on disk, the EDR will catch it. If I run a PowerShell Empire payload, the EDR will probably flag it. If I attempt to inject shellcode into a running process, the behavioral detection will likely trigger.

Modern EDR has become genuinely effective against traditional endpoint attacks. The signature databases are comprehensive, the behavioral detection engines are sophisticated, and the machine learning models can identify novel threats. For protecting against ransomware, commodity malware, and scripted attacks, EDR is an essential investment.

Where EDR Falls Short

The problem is that most of my Active Directory attacks do not involve malware, suspicious processes, or anomalous endpoint behavior. I use legitimate Windows tools and protocols the way they were designed to be used. The EDR sees legitimate activity because it is legitimate activity -- it is just being performed by someone who should not be doing it.

When I perform Kerberoasting, I am requesting Kerberos service tickets using the standard Windows API. This is exactly what every application does when authenticating to a service. The EDR sees a normal Kerberos ticket request and does not alert because thousands of identical requests happen every hour in a normal environment.

When I perform NTLM relay, the authentication traffic uses standard NTLM protocols. The relay happens at the network level between machines. The endpoint's EDR does not see network-level man-in-the-middle attacks because they happen outside the endpoint's visibility.

When I use BloodHound's SharpHound collector, it makes standard LDAP queries to the domain controller. These are the same queries that management tools, helpdesk applications, and login scripts make constantly. The EDR cannot distinguish my reconnaissance from normal administrative activity based on the endpoint behavior alone.

When I perform a DCSync attack, I use the Microsoft Directory Replication Service protocol -- the exact same protocol that domain controllers use to replicate data between themselves. The EDR on the domain controller sees a standard replication request and has no basis to flag it as malicious.

The Detection Gap in Practice

Let me walk through a typical attack sequence and what the EDR sees at each step:

1. I run Responder: This runs on my own machine, not on any endpoint the EDR monitors. EDR visibility is zero.
2. I relay NTLM to LDAP: This is network traffic between machines. The endpoint EDR has no visibility into network-level relay attacks.
3. I modify AD objects via LDAP: The domain controller processes a standard LDAP modification request. No malware, no suspicious process.
4. I request Kerberos tickets for Kerberoasting: The workstation makes standard API calls. The EDR sees normal Kerberos activity.
5. I crack passwords offline: This happens on my own machine. No endpoint visibility.
6. I authenticate with compromised credentials: The target machine sees a legitimate logon with valid credentials. The EDR has no reason to alert.

At no point in this sequence does the EDR have a clear signal to generate an alert. I am not running malware, I am not injecting code, I am not exploiting software vulnerabilities. I am using Windows the way it was built to work.

What You Need Instead

Defending against AD attacks requires controls at layers the EDR cannot see. Here is what I recommend:

Domain controller monitoring: Your most critical detection capability is monitoring authentication events on your domain controllers. Event ID 4769 with RC4 encryption detects Kerberoasting. Event ID 4662 with replication GUIDs from non-DC sources detects DCSync. Event ID 4624 with mismatched workstation names and IPs detects relay attacks. These events exist in your Windows security logs today -- you just need to collect and alert on them.

Network detection: Deploy network detection tools that can identify NTLM relay traffic, ARP spoofing, LLMNR/NBT-NS poisoning, and suspicious Kerberos patterns. NDR solutions sit at the network level where EDR has no visibility and can catch attack techniques that are invisible at the endpoint.

Active Directory auditing: Enable and monitor Directory Service Changes auditing on your domain controllers. Watch for modifications to sensitive attributes like msDS-AllowedToActOnBehalfOfOtherIdentity, servicePrincipalName, and member attributes on privileged groups. Alert on any change to Tier 0 objects outside of approved change windows.

Identity threat detection: Consider deploying identity threat detection solutions specifically designed for AD attacks. These tools understand AD protocols at a deep level and can detect Kerberoasting, Golden Tickets, DCSync, and other AD-specific attacks that generic EDR misses. They fill the gap between endpoint detection and network detection with protocol-aware analysis.

Building a Layered Defense

EDR remains an important component of your security stack. It protects against malware, provides endpoint visibility, and enables incident response capabilities. But it cannot be your only detection layer. The attacks that compromise Active Directory environments operate at the protocol and directory service layer, outside EDR's design scope.

Build your detection strategy in layers: EDR for endpoint protection, NDR for network visibility, domain controller log monitoring for authentication attacks, and AD-specific threat detection for protocol-level abuse. When these layers work together, an attacker must evade all of them simultaneously -- which is dramatically harder than evading any single layer alone.

The next time a security vendor tells you their EDR will stop Active Directory attacks, ask them how it detects Kerberoasting, NTLM relay, and DCSync. If the answer involves signature matching or behavioral analysis at the endpoint level, you know there is a gap in your defense that needs to be filled with additional controls.