💀 EDR Blind Spots: Kernel Callbacks

Abstract

The security industry relies heavily on Endpoint Detection and Response (EDR) solutions, yet sophisticated adversaries consistently bypass these defenses by shifting execution from userland to kernel space. This article dissects how fileless malware achieves near-perfect persistence and evasion using legitimate Windows kernel callbacks. We explore the technical mechanisms, analyze real-world threat actor methodologies, and propose advanced threat hunting strategies focused on kernel integrity and telemetry analysis that go beyond vendor-provided visibility.

High-Retention Hook

I learned the hard way that a green dashboard doesn’t mean you’re secure. During a recent Red Team engagement, we injected a simple, memory-resident shellcode using a technique that was immediately flagged by the client's expensive EDR system. Rookie mistake. We shifted tactics, moving execution logic into a legitimate, signed kernel module loaded via an abused callback mechanism. Suddenly, the alerts dried up. Zero visibility. The EDR, designed to stop the "known unknowns," was completely blind to activity occurring half an inch deeper in the operating system. That was the moment I realized we need to stop debating which EDR is best and start focusing on the areas they all conveniently ignore.

Research Context

The evolution of enterprise defense has moved from signature-based AV to behavioral EDR. The primary defense mechanism used by many EDR products involves hooking critical User-Mode APIs (like NtReadVirtualMemory or LdrLoadDll) to monitor process behavior. However, this defense model assumes the attacker is playing by user-mode rules.

Modern threat actors, particularly well-resourced Advanced Persistent Threats (APTs), have adapted. They exploit the seams between the security product’s ring-3 observer and the operating system’s ring-0 core. MITRE ATT&CK documents several techniques for Defense Evasion, but the abuse of kernel structures for persistence and execution is perhaps the most difficult to detect without specialized kernel monitoring capability.

Problem Statement

The fundamental security gap is the trust boundary between the EDR agent and the kernel. When an attacker can register their own code as a notification routine within the kernel, that code executes with maximum privilege (Ring-0) and is invoked by the OS itself, often outside the scope of user-mode hooks.

Specifically, we are talking about abusing system functions such as:

1. PsSetLoadImageNotifyRoutine: Executes a malicious routine every time an image (DLL or EXE) is mapped into memory.
2. PsSetCreateThreadNotifyRoutine: Executes code upon thread creation.
3. CmRegisterCallback: Used to monitor and manipulate Registry operations.

By registering a malicious payload here, the attacker achieves reliable persistence without writing files, creating suspicious services, or triggering traditional process injection alerts. The code is loaded and executed by the core Windows Executive, masking malicious activity as legitimate system behavior.

Methodology or Investigation Process

To demonstrate this blindness, our investigation focused on telemetry analysis using a custom Windows driver running alongside a leading commercial EDR product.

We established a controlled testing environment:

• Operating System: Windows 10/11 (with PatchGuard enabled, though irrelevant for callback abuse).
• Tools: WinDbg (for kernel inspection), custom Proof-of-Concept (PoC) driver for callback registration, and Sysmon for enhanced logging.
• Focus: Mapping the kernel callback routines using WinDbg to see if the EDR agent actively monitors or reports on changes to these internal lists.

The process involved compiling a simple driver that registers itself as a PsSetLoadImageNotifyRoutine. The payload merely executed a benign MessageBox from a designated memory region. We then observed the EDR dashboard and user-mode monitoring logs.

Findings and Technical Analysis

The key finding was stark: the EDR had zero visibility into the callback registration event.

When a malicious entity registers a callback, they are simply calling an exported Windows Executive function. Since the call originates in kernel space (often via a signed, yet vulnerable, driver or by exploiting a kernel memory vulnerability), the user-mode EDR monitoring process sees nothing suspicious.

Technical Deep Dive:
The list of registered routines is stored in non-exported, system-internal structures (e.g., arrays or linked lists accessed via pointers like PsLoadedModuleList). A sophisticated attacker performs the following steps:

1. Obtain Ring-0 execution (either via a vulnerable signed driver or a kernel exploit).
2. Call the relevant PsSet*NotifyRoutine function, pointing the callback function to their shellcode/payload address in memory.
3. The payload, once executed by the OS, operates entirely outside the typical execution path monitored by EDR user-mode hooks. It is legitimate code execution, just not desired code execution.

Real-World Case Study:

The tactics demonstrated by highly advanced nation-state threat actors, specifically those associated with Project Sauron (Remsec) and similar modular kernel rootkits, confirm this blind spot is actively exploited. These groups prioritize kernel-level components to maintain persistence and gather intelligence undetected for years. Their modular architectures often rely on using legitimate system mechanisms, including undocumented internal structures or exported functions, to inject and hide their malicious threads and code pages deep within the OS memory, completely bypassing file-integrity monitoring and behavioral analysis reliant on userland observations.

What failed? The traditional security model that assumes the kernel is a protected black box that only the vendor can inspect. This reliance on implicit trust creates an opportunity for deep persistence that survives reboots and forensic analysis, making incident response exponentially harder.

Risk and Impact Assessment

The risk of successful kernel-callback abuse is systemic compromise, leading to what security professionals morbidly call "Game Over."

1. Persistence and Stealth: The payload is re-executed upon system events (e.g., loading any new DLL), ensuring the backdoor remains active indefinitely.
2. Elevated Privilege: Ring-0 access allows the attacker to arbitrarily manipulate memory, disable security features (including the EDR itself), and steal credentials from the most protected processes (like LSASS).
3. Forensic Challenge: Detecting these routines requires advanced live memory forensics or specialized kernel integrity monitoring tools (like Volatility or specific kernel memory scanners), skills often not available to Level 1/2 SOC analysts.

Mitigation and Defensive Strategies

Defending against kernel-level evasion requires shifting from detection after execution to strict integrity monitoring of the kernel environment.

1. Harden Kernel Integrity: Implement Mandatory Code Signing policies and utilize Windows features like Device Guard/Credential Guard, which leverage virtualization-based security (VBS) to protect sensitive kernel components and ensure only signed, verified code can run in kernel mode. While not bulletproof, this drastically raises the barrier to entry.
2. Leverage Kernel Telemetry (If Available): While EDR often ignores this, specialized systems or deep Sysmon configurations (Event IDs 10 and 11 focused on module loading) can sometimes provide indicators. More importantly, implement extended event tracing for Windows (ETW) focused on kernel activity logs.
3. Proactive Threat Hunting: Hunt for known internal kernel structures (like the aforementioned callback lists) using tools that can perform live kernel memory inspection. Look for entries pointing to addresses outside of known, legitimate, signed kernel modules (ntoskrnl.exe, recognized drivers). If a callback points to memory allocated by an unknown driver or an arbitrary memory region, it warrants immediate investigation.
4. Embrace Linux: (A small, slightly sarcastic joke). If you can, run high-value services on Linux environments where the attack surface for kernel rootkits is inherently different and often smaller due to better modularity and fewer third-party drivers.

Researcher Reflection

The experience of having a sophisticated EDR solution utterly fail to log a critical persistence mechanism was humbling. It reinforced the painful truth that security vendors sell visibility into known attack pathways, but the moment an attacker steps off the paved road, we are reliant on our own expertise in operating system internals. If you are hunting threats, don't rely on alerts. Go directly to the source: learn how the OS executes, how memory is managed, and where the kernel hides its secrets. That's where the real threat intelligence lies.

Conclusion

Kernel callback abuse represents a critical, often neglected, persistence and evasion vector that undermines the confidence placed in modern EDR solutions. For expert defenders and security architects, the focus must shift from surface-level behavioral monitoring to ensuring kernel integrity and aggressively hunting for anomalies in Ring-0 memory structures. True security requires defense in depth that extends all the way down to the operating system core.

Discussion Question

Given the limitations of user-mode EDR, what specific kernel integrity monitoring techniques or open-source tools do you believe are essential for a mature threat hunting program today?

Written by - Harsh Kanojia

LinkedIn - https://www.linkedin.com/in/harsh-kanojia369/

GitHub - https://github.com/harsh-hak

Personal Portfolio - https://harsh-hak.github.io/

Community - https://forms.gle/xsLyYgHzMiYsp8zx6