Listen to this Post
Introduction:
Endpoint Detection and Response (EDR) solutions rely heavily on kernel-level callbacks to monitor process creation, thread execution, image loading, and file system operations. By abusing a legitimate, signed but vulnerable driver, an attacker can effectively deregister or block these callbacks, rendering the EDR sensor blind to system activity while maintaining system stability and avoiding bugchecks.
Learning Objectives:
- Understand how EDR solutions collect telemetry through Windows Kernel Callbacks.
- Learn the methodology of using a trusted, signed driver to unhook or disable EDR notifications.
- Identify detection strategies and mitigation techniques against Bring Your Own Vulnerable Driver (BYOVD) attacks.
You Should Know:
1. Understanding Kernel Callbacks and EDR Telemetry
EDR sensors operate by registering callback routines with the operating system. For example, `PsSetCreateProcessNotifyRoutineEx` allows a driver to be notified every time a process starts. To blind an EDR, an attacker aims to remove these registered callbacks from the kernel’s internal structures. The technique often involves locating the `CallbackListHead` in the kernel and unlinking the EDR’s entry.
To verify registered callbacks, security researchers use tools like WinDbg or DriverView. However, from a defensive perspective, monitoring for attempts to modify these structures is critical.
Windows Command (Admin):
To list loaded drivers and filter for security products (often named with vendor prefixes like sysmon, cb, or edr), you can use:
driverquery /v | findstr /i "symantec crowdstrike sentinel carbon black"
- The Bring Your Own Vulnerable Driver (BYOVD) Attack Chain
The core concept behind the post is the BYOVD technique. The attacker supplies a legitimate driver that is digitally signed by Microsoft (WHQL) but contains a known vulnerability, such as arbitrary read/write primitives. The sequence involves:
1. Deploy the Driver: Place the vulnerable `.sys` file on disk.
2. Load the Driver: Use the Windows Service Control Manager (sc.exe) or a custom loader to start the driver.
3. Communicate with the Driver: Send IOCTL (Input/Output Control) codes to the driver to execute kernel-mode read/write operations.
4. Patch the EDR: Locate the EDR’s callback structures in memory and overwrite them or disable them.
Step‑by‑step guide:
- Identify a target driver: This requires reconnaissance to find a signed driver with known vulnerabilities (e.g., `gdrv.sys` from Gigabyte, or `aswArPot.sys` from Avast).
- Load the driver:
sc.exe create DrvLoader binPath= C:\path\to\vuln_driver.sys type= kernel start= demand sc.exe start DrvLoader
- Exploit the vulnerability: Using a user-mode client, send the appropriate IOCTL to the driver to perform kernel read/writes. This often involves crafting a buffer that points to the memory address of the EDR’s `PSCREATEPROCESSNOTIFYROUTINE` and overwriting it with zeros or a pointer to a benign routine.
- Verify blind spot: Attempt to execute a new process (e.g.,
calc.exe) and check if the EDR console registers the event. If successful, the EDR is blind to new telemetry.
3. Linux Perspective: LKM Rootkits vs. EDR
While the original post focuses on Windows, the principle of blinding security tools applies to Linux as well. Endpoint detection on Linux often relies on eBPF (Extended Berkeley Packet Filter) programs or kernel modules that hook syscalls. Attackers can load a malicious Linux Kernel Module (LKM) to hook syscalls before the security agent does, or unload the eBPF programs.
Linux Commands to inspect loaded security modules:
List loaded kernel modules lsmod | grep -E "falcon|cylance|sentinel" Inspect eBPF programs attached to kprobes bpftool prog list bpftool net show
Mitigation: Enforcing a strict kernel module signing policy (CONFIG_MODULE_SIG_FORCE) and using Lockdown LSM can prevent unauthorized modules from loading.
4. Course Content: The “Toolkit” Approach
The post mentions, “Such tool should be absolutely present in your engagement’s toolkit. Support for that is added to the content’s course with couple of drivers backups.”
This implies that modern red teaming courses are shifting from script-kiddie tools to custom exploit development targeting the security stack itself. The “drivers backups” likely refer to a collection of known vulnerable signed drivers (like the popular `Capcom.sys` or RTCore64.sys) stored locally to bypass network detection during an engagement.
Defensive Implementation:
To prevent this, organizations should implement Driver Blocklist Policies via Microsoft Defender for Endpoint or Windows Defender Application Control (WDAC). WDAC can be configured to allow only specific approved drivers to load, effectively blocking BYOVD attacks regardless of the signature.
5. Hardening Against BYOVD
Defenders are not helpless against this technique. The following steps should be implemented to mitigate the risk of EDR blinding:
- Enable HVCI (Hypervisor-Protected Code Integrity): Also known as Memory Integrity, this leverages virtualization-based security to protect kernel mode processes. It prevents the loading of vulnerable drivers and stops unauthorized code injection into the kernel.
- Monitor for Driver Load Events: Event ID 7045 (Service Installation) and Event ID 6 (Driver Loaded) in the System log, while often noisy, should be correlated with file hashes of known vulnerable drivers.
- Implement LSA Protection: While not directly preventing driver loading, it adds another layer of complexity for credential dumping once the EDR is down.
PowerShell Query for Suspicious Driver Loads:
Get-WinEvent -FilterHashtable @{LogName='System'; ID=6} | Where-Object { $_.Message -match "gdrv.sys|RTCore64.sys|capcom.sys" }
6. API Security Implications
Although the post focuses on endpoint telemetry, the concept applies to API security. Modern EDRs often integrate with cloud workloads. If an attacker blinds the EDR on a Kubernetes node or a virtual machine, they effectively bypass runtime security for containerized APIs. Red team toolkits now often include agents that kill or block Falco agents (a popular runtime security tool) via kernel module unloading.
What Undercode Say:
- Offensive Utility: Abusing legitimate drivers is currently the most reliable method to bypass modern EDRs without triggering “tamper protection” alerts, as the driver is signed and trusted by the OS.
- Defensive Blind Spot: Relying solely on signature-based detection for drivers is insufficient; organizations must enforce application control and driver blocklists proactively.
- The Arms Race: As EDRs move to kernel-level protections and PPL (Protected Process Light) models, attackers will continue to exploit the inherent trust the OS places in WHQL-signed binaries, pushing the need for stricter driver certification policies from Microsoft.
Analysis:
The technique described highlights a critical flaw in the assumption that “signed” equals “safe.” The post underscores a shift in red team methodology where the security product itself becomes the primary target. By neutralizing telemetry, the attacker gains an immense advantage: they can execute post-exploitation activities (lateral movement, data exfiltration) without generating alerts. For defenders, this means that prevention must occur at the hardware and policy level (VBS, WDAC) rather than relying solely on the EDR’s ability to detect malicious behavior after the fact. The inclusion of “drivers backups” in training courses indicates a professionalization of this attack vector, moving it from niche exploit development to standard operational tradecraft.
Prediction:
As BYOVD becomes standard in red team toolkits, we will see a surge in Microsoft’s enforcement of driver signing requirements, potentially moving to a model where only drivers submitted to the Azure Attestation service for “health” attestation are allowed to load. Concurrently, EDR vendors will shift more detection logic to the hypervisor level (VBS enclaves) to create a separation between the security agent and the kernel being attacked, ensuring that even if the kernel is compromised, the telemetry collection remains isolated and tamper-proof.
▶️ Related Video (90% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Saad Ahla – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
