Ghost in the Kernel: Hunting BYOVD After Microsoft’s 2026 Driver Trust Shift
BYOVD attacks have helped ransomware crews and advanced actors disable security tools, hide activity, and move from admin control towards the kernel. Microsoft’s 2026 Windows Driver Policy is a major hardening step, but it does not make kernel-driver risk disappear. This talk explains what the new policy blocks, what it only audits, and what defenders still need to hunt. Using cases including BlackByte, POORTRY/STONESTOP, and Lazarus/FudModule, we will build a practical approach to driver inventory, Code Integrity events, audit-mode visibility, and reducing kernel attack surface.
Kernel drivers remain a valuable target because they sit close to the operating system’s core. When abused, they can help attackers interfere with EDR, hide telemetry, tamper with protected processes, and weaken incident response visibility.
In 2026, Microsoft’s Windows Driver Policy changed the trust model for kernel drivers by reducing default trust in deprecated cross-signed drivers and moving towards a stricter WHCP/allowlisted legacy-driver model. That is a major defensive improvement, but it does not remove the defender’s job. Organisations still need to know which drivers are loading, which machines are only auditing, which machines are enforcing, and which legacy or signed drivers still represent risk.
This talk uses three real-world cases to show why this matters:
- BlackByte’s abuse of RTCore64.sys to weaken security tooling.
- POORTRY/STONESTOP, where signed-driver trust became part of the problem.
- Lazarus/FudModule, showing how advanced actors continue to pursue admin-to-kernel capability.
The main technical focus is the distinction between audit and enforcement. In Microsoft’s Code Integrity logs, Event ID 3076 means a driver would have been blocked but was allowed in audit mode. Event ID 3077 means the driver was actually blocked under enforcement. That difference is the “ghost” this talk hunts: the driver your policy can see, but has not yet stopped.
The talk will cover:
- Why BYOVD still matters after Microsoft’s 2026 driver trust shift.
- How the new driver trust model changes the defender’s assumptions.
- Why “signed” does not automatically mean safe.
- How to use Code Integrity Event IDs 3076 and 3077 as hunting signals.
- How to build a basic driver inventory and identify legacy exceptions.
- How to baseline noisy but legitimate 3076 events before hunting rare or suspicious ones.
- How to triage audited or blocked drivers into remove, update, allowlist, isolate, or monitor decisions.
Attendees will leave with a practical hunter’s toolkit: what logs to collect, what events to search for, what questions to ask about each driver, and how to turn audit-mode visibility into an actionable reduction of kernel attack surface.
This is a defensive, blue-team focused talk. It does not provide a BYOVD exploitation walkthrough. The emphasis is on visibility, detection, triage, and safe operationalisation.
Richard Dosumu is a cybersecurity practitioner, independent researcher, Product Lead and founder of OctaTech, a UK-based digital product company building accessible tools for cybersecurity development, learning, and productivity. He holds an MSc in Cyber Security and Human Factors from Bournemouth University and writes on cybersecurity, AI, digital resilience, and human-centred security. Through CyberYearn and OctaTech’s wider product work, Richard is focused on improving cybersecurity literacy by making security guidance clearer, more practical, and more accessible to learners, early-career professionals, and real-world teams.