Endpoint Protection Platforms (EPP) and Endpoint Detection and Response (EDR) tools represent the last and often the most important layer of defense in a modern security stack. They sit directly on the machines that matter like developer laptops, domain controllers, CI/CD servers, POS systems. And yet, despite years of engineering investment, they carry systematic blind spots that sophisticated attackers reliably exploit.
The problem is structural, the operating system itself does not expose a complete view of its own behavior and endpoint agents must work within the permissions and interfaces that the OS provides. Understanding where visibility breaks down directly shapes how defenders architect detections, how red teams build payloads and how security engineers prioritize compensating controls. This article walks through the major categories of visibility failure, the underlying technical reasons each exists and what a mature detection engineering program does to reduce though never eliminate those gaps.
EPP Architecture Fundamentals
Before discussing what endpoint agents cannot see, it helps to understand what they can and how they acquire that visibility. Modern EPP and EDR agents collect telemetry from multiple OS instrumentation points simultaneously.
Instrumentation Points on Windows
On Windows, the primary telemetry surfaces available to a user-mode or kernel-mode endpoint agent include:
- Event Tracing for Windows (ETW): A high-performance, kernel-level tracing mechanism. Providers like Microsoft-Windows-Kernel-Process, Microsoft-Windows-Threat-Intelligence (ETWTI) and Microsoft-Windows-DNS-Client surface rich behavioral signals.
- Windows Filtering Platform (WFP): A network callout framework that lets kernel drivers inspect, modify or block network traffic at multiple IP-stack layers.
- Kernel Callbacks: Registration via APIs like PsSetCreateProcessNotifyRoutineEx, PsSetCreateThreadNotifyRoutine, CmRegisterCallback and ObRegisterCallbacks gives agents synchronous notification of key OS events.
- Minifilter Drivers: Filesystem filter drivers that intercept I/O operations through the Filter Manager (FltRegisterFilter). Used for real-time file scanning and blocking.
- Antimalware Scan Interface (AMSI): A COM-based interface that allows script hosts like PowerShell, VBScript, JScript and Office macros to pass content to registered antimalware engines before execution.
The Visibility Stack by OS Layer
Not all OS layers are equally observable. The following diagram maps coverage from user space down to hardware, with the darker layers representing areas of higher attacker advantage:
Fileless and Memory-Only Attacks
The term “fileless” is somewhat misleading that all code must eventually reside in memory and most fileless attacks involve at least a small on-disk artifact like a phishing document, a malicious LNK or a registry key. What the term actually describes is code execution that never writes a standalone PE binary to disk in a form that traditional file-scanning AV can inspect. Fileless techniques exploit the gap between what a minifilter driver can see files on disk and what actually executes at runtime (memory-resident shellcode, reflectively loaded DLLs, .NET assemblies loaded via reflection).
- Process Hollowing: Process hollowing unmaps a legitimate process image from memory and replaces it with malicious code, while preserving the visible process name and parent. From the perspective of process listing tools and many EDR process-creation callbacks, only the creation of a legitimate host process like svchost is observed.
- Reflective DLL Injection: Reflective DLL Injection loads a DLL directly from memory without using `LoadLibrary`. Since the DLL is never written to disk or added to the PEB module list, it can evade file-based scanners and many traditional detection methods. Introduced by Stephen Fewer in 2008, the technique remains effective because kernel callbacks monitor `LoadLibrary` but not custom PE loaders that manually map the DLL into memory.
- AMSI Bypass: Antimalware Scan Interface (AMSI) lets script hosts like PowerShell, VBScript and JScript send code to security tools such as Microsoft Defender Antivirus before execution. Since AMSI runs entirely in user mode within the host process, code already executing there can patch its functions to always return a clean result, effectively disabling scanning. For this reason, AMSI bypass is commonly used as an early step in modern PowerShell-based attack chains.
Kernel-Level and Rootkit Threats
The single greatest architectural advantage an EDR agent can have is a kernel driver. Running at Ring 0, a kernel driver can register synchronous callbacks, intercept syscalls and observe memory operations that are completely opaque to user-mode agents. However, attackers have increasingly moved into the kernel as well via legitimate driver abuse, driver signing loopholes and firmware-level persistence.
BYOVD (Bring Your Own Vulnerable Driver)
The BYOVD technique loads a legitimately signed but vulnerable kernel driver, then exploits a known vulnerability in that driver to achieve kernel-mode code execution. Because the driver is signed by a legitimate CA, Secure Boot and driver signing enforcement do not block it. Once in the kernel, the attacker can disable EDR kernel callbacks, unhook minifilter drivers and tamper with EPROCESS structures to hide processes.
Notable real-world BYOVD drivers include dbutil (Dell), mhyprot2 (MiHoYo) and gdrv (GIGABYTE). Microsoft maintains a blocklist via HVCI/WDAC but coverage is never complete, and new vulnerable drivers surface regularly.
DKOM (Direct Kernel Object Manipulation)
DKOM manipulates kernel data structures directly, without going through any monitored API. The classic example is unlinking an EPROCESS structure from the PsActiveProcessLinks doubly-linked list making the process invisible to NtQuerySystemInformation-based process enumeration the foundation of every task manager and process tree in a standard EDR console.
Hypervisor-Level Rootkits
A hypervisor rootkit installs below the operating system, leveraging Intel VT-x or AMD-V to place the original OS inside a virtual machine it fully controls. From that position, the rootkit has complete read/write access to the guest OS’s physical memory with zero guest-observable footprint. This class of attack sometimes called a “blue pill” or “virtual machine based rootkit” is beyond the detection capability of any software agent running inside the guest OS including kernel-mode EDR drivers.
LOLBAS and Living-off-the-Land Techniques
Living-off-the-Land Binary and Script (LOLBAS) techniques abuse legitimate OS binaries, scripts, and libraries to accomplish attacker objectives. Because these binaries are signed by Microsoft, have legitimate use cases, and are whitelisted in most environments, they present a fundamental signal-to-noise problem for behavioral detections.
The core visibility problem with LOLBAS is that a detection based purely on process name is trivially bypassed, while a detection based on behavioral context such as parent process, command-line arguments, network connections and child processes generates enormous false positive rates in most enterprise environments. Tuning these detections requires extensive baselining of normal usage patterns per environment work that is ongoing and never complete.
Encrypted Traffic Blind Spots
Modern network communication is overwhelmingly TLS-encrypted. This is a security improvement overall but it creates a structural visibility gap for network-based detection components bundled in endpoint products. Without TLS inspection, an EDR’s network telemetry sees destination IP, port, bytes transferred and timing but not the payload content.
DNS-over-HTTPS C2
Traditional DNS C2 is highly visible as DNS queries appear in plaintext, are easy to log and can be blocked by DNS sinkholes or RPZ policies. DNS-over-HTTPS (DoH) tunnels these queries inside standard HTTPS traffic to resolvers like 1.1.1.1 or 8.8.8.8. From a network perspective, the endpoint is simply making HTTPS requests to a well-known, trusted CDN IP address. The content including the C2 domain being resolved is encrypted.
HTTPS C2 Blending
Frameworks like Cobalt Strike, Brute Ratel and Havoc are designed to make their C2 traffic indistinguishable from legitimate HTTPS browsing. Malleable C2 profiles allow the operator to mimic specific legitimate services Amazon S3, Microsoft Graph API, Google Analytics including response codes, headers and timing patterns. An endpoint agent inspecting only connection metadata like IP, port or TLS SNI has no way to distinguish this traffic from legitimate use of those same services.
Supply Chain Visibility Gaps
The SolarWinds, Kaseya, and 3CX incidents demonstrated a class of attack that endpoint protection fundamentally struggles with as the implant is delivered as a signed, legitimate update to trusted software that already has elevated privileges and is explicitly excluded from EDR inspection by policy.
Trusted Updater Abuse
Software update mechanisms typically run as SYSTEM, are code-signed and are excluded from behavioral monitoring to avoid false positives and performance overhead. When an attacker compromises the build pipeline or update infrastructure of a software vendor, the resulting malicious update is indistinguishable from a legitimate one at the endpoint. The process is signed, the binary passes hash verification and the EDR’s exclusion list welcomes it.
Compiler-Level Implants
Ken Thompson’s 1984 “Reflections on Trusting Trust” described the theoretical attack where a malicious compiler that inserts backdoors into compiled code while also subverting its own source. This remains non-theoretical. The XcodeGhost incident (2015) demonstrated it at scale, with a trojanized version of Apple’s Xcode compiler inserting malicious code into hundreds of iOS applications. No endpoint agent on the developer’s machine or the end user’s device could detect the implant through behavioral analysis because the malicious code was architecturally identical to legitimate app behavior.
Telemetry Gaps and Data Volume Challenges
Even where instrumentation points theoretically provide complete visibility, practical limitations in telemetry collection, buffering and transmission create windows of blindness.
- ETW Tampering: ETW providers can be disabled by a sufficiently privileged process. An attacker with kernel privileges can call NtTraceControl to disable specific ETW providers, or simply patch the EtwpEventCallback function pointer in the kernel to suppress specific event types. This silences the telemetry stream that many EDR products depend on for process injection, memory allocation and network event visibility.
- Event Buffer Overflows: ETW buffers are finite. Under high-load conditions like intensive build processes, large file operations, high-frequency network activity, the ETW buffer can fill faster than it is consumed causing event loss. The kernel drops events silently; neither the consuming EDR agent nor the SIEM will see a gap marker. An attacker who can generate sustained high-volume legitimate activity or exploit a noisy co-resident process can use this to mask malicious actions in the noise.
- Direct Syscall Invocation: Many EDR products instrument user-mode API calls by installing inline hooks (trampolines) in ntdll within each monitored process. These hooks redirect calls to EDR inspection code before forwarding to the real syscall. An attacker can bypass this entirely by resolving syscall numbers directly and invoking them via syscall/sysenter instructions without ever passing through the hooked ntdll stubs. Tools like Syswhispers, Hells Gate and Tartarus Gate automate this approach.
Closing the Gaps: A Defense-in-Depth Approach
No single control eliminates the visibility limitations described above. A mature endpoint security posture layers complementary mechanisms so that each addresses the blind spots of the others.
Hypervisor-Protected Code Integrity (HVCI) and Credential Guard
HVCI uses the Windows hypervisor to enforce that only properly signed code runs in kernel mode, even if an attacker achieves kernel-level code execution. This directly blocks the BYOVD attack class and significantly raises the cost of DKOM. It must be enabled at image deployment time and requires compatible hardware.
Kernel ETW Threat Intelligence (ETWTI)
Microsoft-Windows-Threat-Intelligence is a kernel-mode ETW provider surfacing events for remote process memory allocation, thread injection and APC queue manipulation. Unlike user-mode hooks, ETWTI events are generated in the kernel and cannot be silenced by a user-mode ETW patch. They can still be suppressed by a kernel-mode attacker, but that requires a significantly higher bar.
Memory Scanning and VAD Interrogation
Periodic or trigger-based scanning of process memory for anomalous virtual address descriptors (VAD entries) specifically for executable memory regions not backed by a mapped file, or where the mapped file path does not match the module in the PEB loader list catches several injection variants that behavioral hooks miss. This is computationally expensive and typically runs on high-value process targets only.
Network Telemetry Enrichment
Where TLS inspection is architecturally infeasible, JA3/JA3S fingerprinting, JARM active fingerprinting, certificate transparency logs and beacon interval analysis provide statistical signals about encrypted C2 traffic without decrypting it. These signals are probabilistic, not deterministic, but they meaningfully improve coverage when correlated with endpoint process telemetry.
Cross-View Detection
Cross-view detection compares the system state as reported through standard APIs against independent views obtained through alternate mechanisms. For example, comparing the process list from NtQuerySystemInformation against a list derived by walking the kernel’s scheduler dispatch queue directly reveals DKOM-hidden processes. This technique is used by hypervisor-based security products with privileged access to guest memory.
Supply Chain Security Controls
Software Bill of Materials (SBOM) generation, build system isolation, artifact signing with hardware-backed keys and reproducible builds reduce supply chain risk. Behavioral baselining of trusted updater processes alerting on any network connection or child process spawned by an update agent that deviates from established baseline catches post-compromise abuse of trusted update paths.
Conclusion
Endpoint protection platforms are extraordinarily capable tools that stop the overwhelming majority of commodity threats. But they operate within the constraints of the operating system they instrument and those constraints are not going away. File-scanning cannot see memory-only code. User-mode hooks cannot survive direct syscall invocation. Kernel callbacks cannot monitor a hypervisor sitting beneath them. AMSI cannot scan content that patches it away first.
The defenders who understand these limitations are the ones who build detections that compensate for them like layering ETWTI over user-mode hooks enriching network telemetry with behavioral baselines and using memory forensics to catch what process monitoring misses. The defenders who assume their EDR is a complete solution are the ones who find out the hard way that it is not.
Visibility is never binary. It is a continuously contested space between the instrumentation available to defenders and the evasion techniques available to attackers. Staying ahead means treating endpoint telemetry not as a solved problem but as an ongoing engineering discipline.
