Eight bytes and the driver is still signed

The story goes like this: someone took a signed driver, changed eight bytes, repeated the operation 2,500 times and walked past Windows' blocked-driver list with a different file every day. The first half is true and documented. The second half is contradicted by the list file itself, which is half a megabyte and downloads in thirty seconds. We did that this morning and counted what is inside.

The eight bytes exist and are measured

The documented part was published by Check Point Research on 24 February 2025 under the title "Silent Killers". The subject was truesight.sys version 2.0.2, Adlice's anti-rootkit driver, with an arbitrary process termination flaw in branches below 3.4.0: a legitimate driver, signed by its vendor, that can be asked to kill processes. The module using it targeted 192 processes, mostly security software.

Check Point found over 2,500 distinct variants of the same file. The difference between one and the next was eight bytes: four in the CheckSum field of the PE header and four in the padding of the WIN_CERTIFICATE structure. Areas which, the research says, are "excluded from the hash calculation during the signing process". That is why the signature survives all 2,500 copies intact. The purpose is summed up by the publication itself in four words: "hash-based detection alone proves ineffective".

The exclusion that saves the signature also saves the hash

The Authenticode specification excludes three things from the hash calculation: the CheckSum field of the optional header, the certificate table entry in the data directory, and the certificate table itself. They are excluded precisely because signing the file modifies them, and if they counted no signature could ever be valid over the file it just signed.

Those are exactly the two places where the eight bytes are written. So the trick does not only leave the signature valid: it also leaves the Authenticode hash identical, and that is the one Windows uses to decide whether a driver loads. What the eight bytes do change is the flat hash of the whole file — the one sha256sum computes, the one that shows up on VirusTotal and the one community lists of abusable drivers carry. For those sources there are 2,500 files. For the Windows kernel there is one.

We counted it in the file, and the rule that blocks does not look at the hash

The official list downloads from aka.ms/VulnerableDriverBlockList. The version we pulled today, 6 November 2026, identifies itself as Microsoft Windows Driver Policy with <VersionEx>10.0.29545.0</VersionEx>. Inside there are 1,713 <Deny> rules: 1,702 with a Hash attribute and 11 with FileName. The same numbers as the count of the blocked-driver list we published on 6 October.

What we had not looked at back then is what kind those 1,702 hashes are. Each rule's friendly name says so. Counted today:

Authenticode hashes and page hashes. No flat file hashes at all. And page hashes do not change the argument: page zero, where the CheckSum lives, is computed with the same omissions. So even if truesight were blocked by hash, the eight bytes would not have shifted it. And as it turns out, it is not blocked by hash at all: searching for truesight in the XML returns fourteen lines and not one of them is a hash rule. The one that defines the file is this:

<FileAttrib ID="ID_FILEATTRIB_TRUESIGHT"
  FriendlyName="Adlice Truesight.sys\3807e9a1... FileAttribute"
  FileName="Truesight"
  MinimumFileVersion="0.0.0.0"
  MaximumFileVersion="3.3.0.0" />

Original file name and version range. That definition is referenced by four signer rules — ID_SIGNER_TRUESIGHT_1 through _4 — spread across three certification chains: one Sectigo and two DigiCert, the latter also carrying CertPublisher="Adlice". All four then appear as <DeniedSigner>. Translated: any binary named Truesight, older than 3.3.0.0 and signed by one of those chains, is denied. The eight bytes change neither the name, nor the version, nor the signer.

If you want to redo the count, it is two lines over the XML you already downloaded:

grep -o 'Hash \(Page \)\?Sha[0-9]*' DriverPolicy_Enforced.xml | sort | uniq -c
grep -i truesight DriverPolicy_Enforced.xml

So why did it load?

Because the rule existed and did not cover that case. According to Check Point, the TBS of the certificate the 2.0.2 build was signed with sat in the list associated with a different driver, not with truesight, so the name-plus-signer combination did not close. Microsoft fixed it on 17 December 2024 after the researchers reported it, and Check Point's assessment of the updated list is that it "effectively prevents all variants of the legacy driver exploited in this campaign". All variants, eight bytes and all.

It was not cryptography, it was an incomplete rule. That difference matters when deciding what to buy and what to write: against a mutating file the rule that holds is the one describing it by what it cannot change and still be itself.

The 2013 registry value is not the answer either

The other common reaction to this topic is to point at CVE-2013-3900, the "WinVerifyTrust Signature Validation Vulnerability", which describes exactly the conceptual hole: "modifying an existing signed executable file to leverage unverified portions of the file in such a way as to add malicious code to the file without invalidating the signature". Microsoft shipped the correction on 10 December 2013 as an opt-in feature, and on 29 July 2014 announced it would not enforce it by default. Twelve years on it is still a value you write yourself, in both registry branches, with a reboot:

; Windows de 64 bits (en 32 bits, solo la primera clave)
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config]
"EnableCertPaddingCheck"=dword:1

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config]
"EnableCertPaddingCheck"=dword:1

Through group policy it is the MS Security Guide template from the Microsoft Security Compliance Toolkit, policy Enable Certificate Padding. And to save you an argument with the compliance scanner: the 23 December 2024 revision of the advisory clarifies that "although Windows treats the EnableCertPaddingCheck value as a DWORD, its actual registry value type does not matter" as long as the data is 1 to 4 bytes with at least one non-zero, and adds that "compliance validation tools should not fail the EnableCertPaddingCheck inspection for its value type".

Our first reading was that enabling that value shut the driver door. It is false, and the advisory's own frequently-asked-questions section settles it. The question, verbatim: "Does the new verification behavior impact Windows Defender Application Control (WDAC)?". The answer, also verbatim: "No. The new verification behavior does not impact WDAC." The value changes WinVerifyTrust, which is user-mode verification, and Microsoft does say it affects AppLocker rules and Software Restriction Policies that depend on the publisher. Driver loading in the kernel goes through code integrity, which is the other pipe.

It is still worth enabling, for what it does cover, but with the bill in front of you: "after you opt in, PE files will be considered 'unsigned' if Windows identifies content in them that does not conform to the Authenticode specification. This may impact some installers", particularly those customised at download time. And signing with non-Microsoft tools "runs the risk of signatures being recognized as non-compliant", which points at in-house and small-vendor software. You test it first. In CISA's exploited vulnerabilities catalogue, incidentally, this CVE was added on 10 January 2022 and its deadline, 10 July that year, expired 1,580 days ago. The required action reads "apply updates per vendor instructions", and the vendor instruction is that there is no update to apply.

Meanwhile, the catalogue of borrowed drivers grows

ESET published its count on 9 April 2026: almost 90 tools built to kill, freeze or blind security software detected in the wild, 54 of them using the technique of loading a vulnerable but signed driver, abusing 35 different drivers. On 18 June, Jakub Souček published the analysis of GentleKiller, the killer the Gentlemen group develops and offers to its affiliates: at least eight variants of the same framework, over 400 processes mapped to 48 security products, and borrowed drivers including one from a data-loss-prevention suite (stpm_*.sys, from Safetica) and one from a consumer antimalware product (dmx.sys, from Zemana). Kaspersky summed it up in its 12 May report: "tools commonly referred to as 'EDR killers' have become a standard component of attack playbooks". And, on the same page, the recommendation that fits everything above: "for Windows environments, enabling Microsoft's Vulnerable Driver Blocklist is critical to thwarting BYOVD attacks".

The rule that worked was one line of text

The defence that worked in this case was a line of text describing a driver by its name, its version and who signed it. Microsoft wrote it, and it took a while to write it correctly. That is the shape of protection that works against a mutating file, and it is also the shape of protection that has to be maintained: the official list is the floor, not the ceiling, and ESET recommends going above it by enforcing code integrity with HVCI and your own policy on which drivers may load. That is a document somebody writes, tests and reviews. That is what our cybersecurity work is about.

And there remains the gap no list covers, because a list only knows what has already happened. For the driver that is not on it yet, the signal you are left with is an agent that stops talking. We wrote this already looking at what you are left with when four EDRs raise no alert: when detection fails, all that is left is telemetry stored off the machine and somebody who queries it. That second part is the difference between having an EDR and having managed EDR/MDR: not the agent, the shift. It is what we do at everyWAN, and it is what tells a machine that was switched off apart from a machine whose agent was switched off.

What we are NOT saying

We are not saying the eight-byte trick is harmless. It defeats flat-hash detection, and that is a lot of detection: antivirus rules, indicator lists, VirusTotal lookups, community inventories of abusable drivers. What it does not defeat is the decision about whether the driver loads in the kernel.

We are also correcting ourselves. In the 6 October post we titled a section "why a hash ages and a certificate not so much". It still holds by the route that matters — a new driver, a new version, a new signer — but not through these eight bytes, and when we wrote it we did not distinguish the Authenticode hash from the flat hash. Said here. One more caveat: that the list's 1,702 hashes are Authenticode and page hashes, with no flat ones, is our reading from each rule's friendly name; the command to check it is above. We have not reproduced the trick in a lab: that part we take from Check Point, who published it with method and date.

Sources. Consulted on 6 November 2026. The 2,500 variants, the eight bytes split between the CheckSum field and the WIN_CERTIFICATE padding, the 192 processes, version 2.0.2 of truesight.sys, the certificate TBS explanation, the 17 December 2024 date and the sentences "hash-based detection alone proves ineffective" and "effectively prevents all variants…" come from "Silent Killers", by Check Point Research (24 February 2025). What Authenticode excludes from the hash calculation is in Microsoft's PE format specification and in the document Windows Authenticode Portable Executable Signature Format. The count of the list (version 10.0.29545.0, 1,713 Deny rules, 1,702 by hash with the breakdown by type, truesight's FileAttrib line and the four signer rules referencing it) is ours, over theDriverPolicy_Enforced.xml file downloaded that day from aka.ms/VulnerableDriverBlockList; the commands to redo it are in the article. The CVE title, the description, the 2013 and 2014 dates, the registry block, the group policy path, the clarification on the value type from the 23 December 2024 revision and the FAQ answers on WDAC, AppLocker, Software Restriction Policies and installers come from the official CVE-2013-3900 record at the Microsoft Security Response Center, read through its public API. The KEV catalogue dates come from the public CISA JSON, version 2026.11.04. The almost 90 tools, the 54 using BYOVD, the 35 drivers and the HVCI recommendation come from "What are EDR killers?" by ESET (9 April 2026). The GentleKiller variants, the processes, the products and the Safetica and Zemana drivers come from "Killing me gently", by Jakub Souček (ESET, 18 June 2026). The two Kaspersky quotes come from the state-of-ransomware report published on Securelist on 12 May 2026. Quotes are left in their original English so they can be searched verbatim. The photograph in the social image is "Computer Lab Baraboo", by JackFromWisconsin, CC0 via Wikimedia Commons, cropped by us.