Help Net Security’s week in review led with the incidents that already had Slack threads. Buried under that noise is DeepZero, an open-source engine that automates the search for exploitable Windows kernel drivers. That is the cybersecurity story your weekend actually needed, and it will not trend, because nobody had to send a customer notice about it.

Roundups train you to skim. You clock the loud patch, you clock the brand-name incident, you archive the tab. Sitting in the same digest is a public hunting pipeline that shortens the gap between a boring signed .sys file and a ring-0 gadget that turns off your threat-protection stack. The known-bad driver list was already a living document. Automation turns it into a feed.

The roundup buried the part that scales

BYOVD stopped being a conference demo years ago. Bring your own vulnerable driver: drop a legitimately signed kernel module, trip a bad IOCTL or a mapped physical-memory primitive, then silence callbacks before your EDR finishes its first look. Anti-cheat leftovers, RGB utilities, old backup filters, motherboard junk from 2017. Microsoft signed a lot of this stuff in a friendlier era, and Windows will still load it if you have not done the unglamorous work of telling it not to.

DeepZero’s contribution is pace. Hunting those primitives used to be a specialist’s week in IDA. An engine that automates the search means the next batch of loadable gadgets shows up as a queue, not a research paper. Red teams will use it. So will people you did not hire. You should assume both, today, not after the first internal writeup with “novel driver” in the title.

Catalogs like the public vulnerable-driver lists already proved the inventory is large. Automation changes the economics. You are no longer waiting for a named crew to weaponize one famous .sys. You are competing with anyone who can clone a repo and point it at the next forgotten signed binary from a hardware vendor’s support ZIP.

If your threat detection story is “we block known hashes from last quarter’s blocklist,” you are reading a changelog. The hunt has a search box now.

Cybersecurity still pretends the kernel is Microsoft’s job

Most defense in depth diagrams are honest until they hit ring 0. Edge firewall, identity, EDR, maybe a sprinkle of application allowlisting. Then a polite assumption that Windows will refuse the weird driver. Plenty of estates still permit administrators, helpdesk jump boxes, and “temporary” engineering laptops to load kernel code because a vendor installer demanded it in 2019 and nobody revoked the habit.

Your SOC already spends real hours on brute-force noise against VPN and RDP. That work is visible. Driver loads are quieter, and they pay better. One cooperative signed module beats a thousand password sprays if the goal is dumping LSASS or killing the sensors that would have noticed. Cyber security programs that score themselves on lockout policies and phishing click rates still leave the kernel path as an honor system.

HVCI and the Microsoft vulnerable driver blocklist exist. So does WDAC. A lot of you have the licensing and none of the enforcement, because a line-of-business printer stack or a laptop vendor’s “support assistant” falls over the first time you flip Memory Integrity. That outage gets a ticket. The open kernel load path does not.

Treat every third-party driver as code you chose to run with the keys to the machine. Signature plus “it came from the OEM portal” is origin, not a control. If a helpdesk tech can install a utility that talks to the kernel, your blast radius for a stolen admin token includes every EDR policy you paid for.

Do the boring driver work this week

You do not need DeepZero on a laptop to get value from the news. You need an inventory, a deny posture, and detections that fire on load, not on the ransomware note. Start with what is already on disk and what Windows will agree to run.

• Export loaded drivers from a representative slice of workstations, jump hosts, and servers. Diff that list against the Microsoft vulnerable driver blocklist and the public known-bad driver catalogs. Anything still loaded is an exception you are actively choosing.
• Turn on the built-in vulnerable driver blocklist and Memory Integrity / HVCI on the fleets that can survive it. Pilot the holdouts. Document the vendors that still require a kernel hole to print or tune a fan curve, then schedule their replacement instead of blessing the bypass forever.
• Put WDAC or an equivalent driver allowlist on privileged endpoints first: domain admins, security tooling, backup servers, VDI gold images. User-mode application control without kernel control is a very expensive screensaver.
• Alert on driver loads (Sysmon event 6, Windows code integrity events, your EDR’s equivalent) for publishers that are not in a short allowlist. A new .sys from an RGB vendor on a finance laptop is an incident, not a curiosity.
• Strip local admin where you still hand it out so “I needed a utility” cannot become “I loaded a kernel module.” Pair that with blocking test-signing and unofficial driver install paths on production images.

That is security hardening you can do without buying a new logo. Immediate: blocklist plus load telemetry on admin jump boxes today, because those boxes are where stolen credentials go to become domain-wide problems. Ongoing: treat driver inventory like certificate inventory. Review publishers quarterly. Kill exceptions that aged out of the project that created them. When a vendor ships a user-mode replacement, take the kernel component off the image the same week.

Keep the edge work. Just stop letting the firewall conversation soak up the week while ring 0 stays on default. Brute-force controls belong in the same program as kernel allowlisting; both are about shrinking what a stolen or bored admin session can touch.

If EDR dies, you are already in incident response

Kernel BYOVD playbooks are repetitive on purpose. Load driver, disable callbacks, freeze or unload the sensor, then dump credentials or drop a second payload while the SOC is staring at a host that went quiet. If your incident response runbook starts at “open the EDR console and isolate,” you have a gap the minute the console has nothing to say.

Build a kernel-aware path. Sudden sensor death, mass Process Notification dropout, or a host that still answers ping but stopped shipping telemetry is a suspected driver event until you prove otherwise. Pull the box off the network with a switch or hypervisor control you do not manage through the possibly dead agent. Collect loaded modules from a known-good channel: out-of-band management, a memory image, or a boot into a trusted environment. Hash every .sys. Check signatures, but also check whether that signed file is on your allowlist. A valid Authenticode chain on a 2016 process-killer utility is the finding.

Practice that isolation on a jump box this month. Tabletop the awkward part: the workstation team wants to reimage immediately, legal wants the disk, and the EDR vendor wants a support bundle from software that is no longer running. Decide now who owns the memory capture. Decide what “reimage” deletes that you needed for the postmortem.

The hunters just got a public engine. Your job is to make the next signed gadget fail on load, show up in a ticket, and meet an IR path that still works after the pretty dashboard goes dark.

Sources

• Week in review: Cisco patches exploited email gateway 0-day, Revolut breach