Windows Defender carries a kernel driver whose whole job is to clean up malware that survives a normal removal. It runs at the highest privilege level Windows offers, takes its orders from an encrypted file on disk, and deletes itself when the work is done. It has shipped on Windows machines for more than a decade, and according to Check Point Research nobody had ever published an analysis of how it actually works.
At Black Hat on August 5, Check Point researcher Jiri Vinopal presented that analysis, and the punchline is a key. Vinopal reverse engineered the driver from raw binary, with no documentation and no symbols to work from, across eighteen signed builds spanning Windows 7 to a fully updated Windows 11 25H2. Every single one of those builds carried the same hardcoded encryption key.
Why one key matters
The driver does not decide for itself what to delete. It reads an encrypted instruction file and carries out what it finds there. Because the key never changed, anyone who works it out can write instructions the driver will accept and execute as its own. Check Point describes what that unlocks as a full set of kernel-level file and registry operations, plus a boot phase window in which the filesystem is already live but Defender's own self-protection has not started yet.
Vinopal closed the talk with a live demonstration: the entire Defender stack deleted from a fully patched, fully protected machine, using Microsoft's own removal tool to do it. As Check Point put it, the defensive technology became the offensive capability.
There is no patch, and there will not be one
This is the uncomfortable part for defenders. The driver is doing exactly what Microsoft built it to do. There is no CVE attached and no fix on the way, because from the vendor's point of view nothing is broken. Check Point's write-up is a summary of a conference talk and does not spell out what level of access an attacker needs before they can plant an instruction file, so treat the technique as a post-compromise capability, a way to disable protection and persist rather than a way in.
That still matters, because turning Defender off is a standard step in real intrusions rather than a theoretical concern. IntelFusions reported in June on attackers who disabled Windows Defender and dumped credentials after breaking in through ColdFusion, and the same component drew attention in July when Microsoft patched a Defender zero-day granting full system control. Both of those had CVEs. This one does not.
What you should do
Since there is nothing to patch, detection is the answer. Vinopal released his tooling, BTR_CLI, as open source at the end of the session, along with detection guidance built on behavior rather than signatures. The behavior to hunt for is the driver being loaded and fed instructions outside a genuine Defender remediation, particularly early in boot, and unexplained removal of Defender components on an otherwise healthy endpoint. Anywhere a second layer of endpoint telemetry exists that does not depend on Defender itself, this is a good argument for keeping it.
Vinopal's session was one of three Check Point Research talks on the day, alongside work on AI agent frameworks by Shahar Tal and Yarden Porat and a deobfuscation pipeline for compiled V8 bytecode malware by Aleksandra Doniec, known as Hasherezade, who used it to recover browser and cryptocurrency theft, Telegram session collection and keylogging from twenty JSCeal payloads. Check Point's summary of all three is in its Black Hat day two recap.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.