A Rust workspace of proof-of-concept binaries documenting how BYOVD techniques abuse vulnerable kernel drivers to terminate AV/EDR processes, built for authorized research and defensive understanding.
| Tool | BlackSnufkin/BYOVD — a Rust Cargo workspace of PoCs demonstrating how vulnerable drivers are abused to disable AV/EDR agents |
| Category | Windows kernel driver security research (BYOVD PoC collection, Rust) |
| Primary Use | Studying BYOVD abuse patterns, driver reverse engineering, and validating blocklists like LOLDDrivers in lab environments |
| Safe Use | Educational and documentary analysis for authorized professionals: isolated lab VMs, red-team research under written authorization, and defensive teams validating driver block rules and EDR tamper detection |
| Telemetry Note | Every PoC manipulates the Service Control Manager — creating, starting, then deleting a driver service — which leaves distinct SCM event log artifacts, plus driver file load events observable via Sysmon (Event ID 6) and Microsoft Vulnerable Driver Blocklist telemetry |
BlackSnufkin/BYOVD is a 947-star Rust repository that collects proof-of-concept code demonstrating the bring-your-own-vulnerable-driver technique: loading a legitimately signed but flawed kernel driver and abusing its privileged IOCTL interface to terminate AV/EDR processes. The README is explicit that these PoCs exist for educational purposes, letting researchers understand how driver flaws translate into endpoint-agent takedown. It is a GPL-3.0 licensed Cargo workspace, and it targets a mix of drivers already catalogued in LOLDDrivers or Microsoft's recommended driver block rules alongside undocumented ones the author discovered independently.
The collection is notable for its breadth: over twenty *-Killer/ directories, each pairing a thin binary with the matching .sys file and a per-driver README containing driver hashes and usage notes. The targets span consumer antivirus (BdApiUtil64.sys from Baidu, ksapi64 from Kingsoft), OEM utilities (HNOs2Ec.sys from HONOR PCManager, HWAudioOs2Ec.sys from Huawei), forensic tooling (EnPortv from EnCase), gaming anti-cheat (xhunter1.sys from Wellbia, tied to CVE-2026-3609), and even reproduction of in-the-wild malware behavior such as the NSecKrnl ValleyRAT driver and the TfSysMon ThreatFire driver later abused by ransomware groups via the EDRKillShifter tool reported by Sophos and ESET.
Architecturally, the interesting part is byovd-lib, the shared library that does all the heavy lifting. It handles the Windows Service Control Manager lifecycle (install, start, stop-and-delete of the driver service), typed IOCTL dispatch, process enumeration by name, kill-on-sight monitoring with Ctrl+C handling, privilege adjustment, and RAII-based cleanup. Each killer binary is deliberately kept thin — roughly 50 to 100 lines — implementing only a DriverConfig trait that describes the driver name, file, device path, IOCTL code, and how a PID is serialized into the input buffer. Four exceptions (K7Terminator, Astra64-Killer, Ktapi-Killer, Xhunter1-Killer) are standalone workspaces with their own build trees because they diverge from the standard flow.
The library exposes two complementary APIs. The high-level path is the DriverConfig trait plus byovd_lib::run(), which orchestrates a preflight check, service installation with SERVICE_DEMAND_START, StartService, a kill-on-sight monitor loop, and cleanup on exit. The low-level imperative path lets researchers compose pieces directly: a ByovdDriver type for lifecycle control, a DeviceHandle with five typed IOCTL shapes (ioctl, ioctl_inout, ioctl_in, ioctl_in_unchecked, and a raw-pointer ioctl_raw escape hatch), and find_pid_by_name/find_all_pids_by_name for process targeting. This dual design means the framework covers both the standard pattern and oddballs — drivers already loaded on the system, structured input buffers, or multi-PID fan-out.
Several implementation details reveal real-world driver quirks the author had to accommodate. The skip_unload() override exists because some drivers BSOD on unload, so cleanup is skipped. ignore_ioctl_error() handles drivers like NSecKrnl that report an error status on successful operations — a classic source of false negatives when writing naive tooling. ensure_running_as_local_system() checks for the S-1-5-18 SID because some drivers reject requests from non-SYSTEM callers. These small accommodations are themselves instructive for anyone studying driver abuse engineering, and the UnknownKiller --attach mode shows the SCM-free pattern: open the device object directly and fire a single typed IOCTL.
Building is standard Cargo: cargo build --release at the workspace root, with -p selecting individual packages like cargo build -release -p BdApiUtil-Killer. Prerequisites are a Rust toolchain plus Visual Studio Build Tools with the Windows SDK, and binaries land in target/release/ next to their driver files. The README also documents a complete x64 driver reverse engineering process as a dedicated section, underscoring that the repository's value is as much the methodology — finding an undocumented driver, mapping its IOCTL surface, identifying a process-termination primitive — as the finished killers.
From a defensive perspective, this repository is essentially a validation corpus. Blue teams can use the documented driver list to audit whether Microsoft's Vulnerable Driver Blocklist and their application-control policies (WDAC) actually block these signatures, and to verify that EDR tamper protection survives kernel-mediated process termination attempts. The README's cross-references to LOLDDrivers entries and assigned CVEs (CVE-2024-51324 for Baidu, CVE-2025-61155 for GameDriverX64, CVE-2023-52271 for Topaz wsftprm, CVE-2025-70795 for Safetica, CVE-2026-8501 for PCTcore64) give defenders a direct path from PoC to patch and blocklist verification.
Detection angles fall out of the architecture naturally. The shared library's reliance on SCM operations — service creation, start, stop, delete — generates System event log entries that stand out for unsigned-or-unfamiliar driver names. Sysmon Event ID 6 captures driver loads regardless of how the service was installed. The kill-on-sight monitor pattern, which repeatedly enumerates processes by name and fires IOCTLs on match, is inherently noisy if an EDR agent respawns. The Astra64-Killer variant, described as a data-only Shadow SSDT hijack, represents the stealthier end of the spectrum, exactly the class of technique that kernel-level sensor integrity features are designed to catch.
The offensive context the README cites is worth understanding: commercial tools like SpyBoy's Terminator (sold for $3,000) and the open Blackout project popularized this technique, and ransomware operators have since operationalized it, as the Sophos and ESET reporting on EDRKillShifter and the TfSysMon driver demonstrates. That lineage is why BYOVD research matters defensively — each PoC in this repository corresponds to a driver that either already appeared in real intrusions or plausibly could, and the LOLDDrivers catalog entry for TfSysMon was added only after publication of research of exactly this kind.
For authorized professionals, the appropriate home for this code is an isolated lab: a disposable Windows VM with the target EDR installed under a test license, snapshots taken, and no production credentials. Red teams operating under a defined scope can use it to test whether their client's endpoint stack detects or survives driver-based tampering, while detection engineers can use it to generate the exact telemetry they need to build correlations. Everything here involves loading kernel drivers and killing protected processes — behavior that is trivially attributable and destructive outside a lab, so there is no legitimate use on systems you do not own or administer.
The repository sits at an interesting intersection of education and weaponization, and the author's framing leans documentary: the README documents the driver ecosystem, references public CVEs and vendor advisories, and disclaims misuse. The engineering quality of byovd-lib — RAII handles that are Send + Sync, typed IOCTL dispatch that eliminates byte-buffer boilerplate, back-compat aliases like FileHandle and get_pid_by_name — makes it a genuinely useful reference implementation for anyone writing Windows driver-interaction tooling in Rust, even for entirely benign purposes like hardware testing or driver fuzzing harnesses. That dual utility is precisely why it rewards careful study from both sides of the fence.
BlackSnufkin/BYOVD.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.