Detecting EDR Silencing via Driver Unloading Techniques

In the modern enterprise, Endpoint Detection and Response (EDR) is the cornerstone of the security stack. These agents act as the "eyes" of the Security Operations Center (SOC), providing deep visibility into process execution, network connections, and file system modifications. However, the effectiveness of an EDR is entirely dependent on its ability to maintain visibility.

A sophisticated adversary's primary objective during the post-exploitation phase is often "silencing"-the intentional neutralization of security telemetry. One of the most potent methods for achieving this is through the unloading of the EDR's kernel-mode driver. When the driver is removed from the kernel's loaded module list or its callbacks are stripped, the EDR becomes a hollow shell: the user-mode service may still appear "Running" in Task Manager, but the kernel-level telemetry-the very data required to detect lateral movement and credential dumping-is gone.

This post explores the technical mechanics of driver unloading attacks and outlines rigorous detection strategies to identify these attempts before the "blind spot" can be exploited.

The Mechanics of Kernel Visibility

To understand how to detect an unload, we must first understand what the EDR is protecting. Most modern EDRs utilize kernel-mode drivers to register specific callbacks via the Windows Kernel API. These callbacks allow the driver to be notified of system events in real-time. Key mechanisms include:

• `PsSetCreateProcessNotifyRoutine`: Notifies the driver when a new process is created.
• `PsSetCreateThreadNotifyRoutine`: Notifies the driver of new thread execution.
• `ObRegisterCallbacks`: Allows the driver to intercept handle creation/duplication (crucial for preventing `lsass.exe` memory dumping).
• `CmRegisterCallbackEx`: Enables monitoring of Registry modifications.
• File System Minifilters: Intercepts I/O requests to monitor file creation, deletion, and modification.

An attacker does not necessarily need to "delete" the EDR driver from the disk. Instead, they aim to manipulate the kernel's operational state so that these callbacks are no longer executed, or the driver object itself is removed from the `PsLoadedModuleList`.

Attack Vectors: BYOVD and `NtUnloadDriver`

The most common way to achieve kernel-mode execution for the purpose of unloading a driver is the Bring Your Own Vulnerable Driver (BYOVD) technique. Since modern Windows versions require Driver Signature Enforcement (DSE), an attacker cannot simply load a malicious, unsigned driver. Instead, they leverage a legitimate, digitally signed, but vulnerable third-party driver (e.g., an old version of an anti-cheat driver or a hardware utility).

Once the vulnerable driver is loaded, the attacker exploits a primitive-such as an arbitrary kernel write-to manipulate kernel structures. The goal is often to call `NtUnloadDriver` or manually nullify the callback arrays.

The `NtUnloadDriver` function is a powerful system call. While intended for legitimate driver lifecycle management, if an attacker gains sufficient privileges (specifically `SeLoadDriverPrivilege` or through a kernel exploit), they can instruct the kernel to execute the `DriverUnload` routine of the EDR driver. Once the routine completes, the driver's code is removed from memory, and its hooks are effectively dissolved.

Detection Strategies

Detecting driver unloading requires a multi-layered approach, moving from high-level service monitoring to deep-kernel telemetry.

1. Monitoring Driver Lifecycle via ETW and Sysmon

The most immediate way to detect driver manipulation is to monitor the loading and unloading of drivers. Windows provides Event Tracing for Windows (ETW) and Sysmon (Event ID 6) to track driver loading.

While attackers may attempt to hide the unloading event, the loading of a suspicious, known-vulnerable driver (the BYOVD component) is often the "loudest" part of the attack.

Detection Logic:

• Monitor for the loading of drivers that are not part of the standard enterprise baseline.
• Cross-reference loaded drivers against databases of known vulnerable drivers (e.g., LOLDrivers).
• Alert on `Driver Load` events where the driver's metadata (publisher/version) is anomalous.

2. Detecting the Use of `NtUnloadDriver` via ETW-Ti

Microsoft introduced the ETW Threat Intelligence (ETW-Ti) provider, which is specifically designed to provide visibility into kernel-level operations that are often invisible to user-mode agents. ETW-Ti can provide telemetry on sensitive kernel operations, including certain types of memory manipulations and driver-related calls.

A robust detection strategy involves monitoring for calls to `NtUnloadDriver` or `ZwUnloadDriver` where the target is a known security product driver. This is a high-fidelity signal because, in a stable production environment, EDR drivers should almost never be unloaded without a documented system update or reboot.

3. Identifying "Callback Stripping"

Advanced attackers may not call an unload function but instead use a kernel write primitive to overwrite the pointers in the `PspCreateProcessNotifyRoutine` array. This effectively silences the EDR without removing the driver from the loaded module list.

Detecting this is significantly harder and requires Kernel Integrity Monitoring. This can be achieved through:

• Periodic Verification: Using a trusted, independent kernel agent to periodically traverse the callback arrays and verify that the registered routines point to the expected, authorized EDR driver memory space.
• Hypervisor-Based Inspection (VMI): In virtualized environments, a hypervisor can monitor the integrity of

Conclusion

As shown across "The Mechanics of Kernel Visibility", "Attack Vectors: BYOVD and `NtUnloadDriver`", "Detection Strategies", a secure implementation for detecting edr silencing via driver unloading techniques depends on execution discipline as much as design.

The practical hardening path is to enforce host hardening baselines with tamper-resistant telemetry, behavior-chain detection across process, memory, identity, and network telemetry, and continuous control validation against adversarial test cases. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track time from suspicious execution chain to host containment and reduction in reachable unsafe states under fuzzed malformed input, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.