Vuit bytes i el driver segueix signat

La història s'explica així: algú va agafar un controlador signat, li va canviar vuit bytes, va repetir l'operació 2.500 vegades i es va passejar per davant de la llista de controladors bloquejats de Windows amb un fitxer diferent cada dia. La primera meitat és veritat i està documentada. La segona la desmenteix el mateix fitxer de la llista, que pesa mig mega i es baixa en trenta segons. Ho hem fet aquest matí i hem comptat què hi ha a dins.

Els vuit bytes existeixen i estan mesurats

La part documentada la va publicar Check Point Research el 24 de febrer del 2025 sota el títol «Silent Killers». El subjecte era truesight.sys en la versió 2.0.2, el controlador antirootkit d'Adlice, amb una fallada de terminació arbitrària de processos en les branques per sota de la 3.4.0: un driver legítim, signat pel seu fabricant, al qual se li pot demanar que mati processos. El mòdul que el feia servir apuntava a 192 processos, sobretot de programari de seguretat.

Check Point va trobar més de 2.500 variants diferents del mateix fitxer. La diferència entre una i l'altra eren vuit bytes: quatre al camp CheckSum de la capçalera PE i quatre al farciment de l'estructura WIN_CERTIFICATE. Zones que, diu la recerca, queden «excluded from the hash calculation during the signing process». Per això la signatura sobreviu intacta a les 2.500 còpies. L'objectiu el resumeix la mateixa publicació en quatre paraules: «hash-based detection alone proves ineffective».

L'exclusió que salva la signatura salva també el hash

L'especificació d'Authenticode exclou del càlcul del hash tres coses: el camp CheckSum de la capçalera opcional, l'entrada de la taula de certificats al directori de dades, i la mateixa taula de certificats. S'exclouen precisament perquè signar el fitxer les modifica, i si entressin al compte cap signatura no podria ser vàlida sobre el fitxer ja signat.

Aquests són exactament els dos llocs on s'escriuen els vuit bytes. De manera que el truc no només deixa la signatura vàlida: deixa també idèntic el hash Authenticode, que és el que fa servir Windows per decidir si un controlador carrega. El que sí que canvia amb els vuit bytes és el hash pla del fitxer sencer, el que calcula sha256sum, el que apareix a VirusTotal i el que porten les llistes comunitàries de controladors abusables. Per a aquelles fonts hi ha 2.500 fitxers. Per al nucli de Windows n'hi ha un.

Ho vam comptar al fitxer, i la regla que bloqueja no mira el hash

La llista oficial es descarrega de aka.ms/VulnerableDriverBlockList. La versió que vam baixar avui, 6 de novembre del 2026, s'identifica com a Microsoft Windows Driver Policy amb <VersionEx>10.0.29545.0</VersionEx>. A dins hi ha 1.713 regles <Deny>: 1.702 amb atribut Hash i 11 amb FileName. Els mateixos números que el recompte de la llista de controladors bloquejats que vam publicar el 6 d'octubre.

El que no havíem mirat llavors és de quin tipus són aquells 1.702 hashos. El nom descriptiu de cada regla ho diu. Comptats avui:

Hashos Authenticode i hashos de pàgina. Cap hash pla de fitxer. I el hash de pàgina no canvia l'argument: la pàgina zero, que és on viu el CheckSum, es calcula amb les mateixes exclusions. Així que encara que truesight estigués bloquejat per hash, els vuit bytes no l'haurien mogut. I resulta que ni tan sols està bloquejat per hash: cercant truesight a l'XML en surten catorze línies i cap no és una regla de hash. La que defineix el fitxer és aquesta:

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

Nom original del fitxer i rang de versions. Aquella definició la referencien quatre regles de signant —ID_SIGNER_TRUESIGHT_1 a _4—, repartides entre tres cadenes de certificació: una de Sectigo i dues de DigiCert, aquestes últimes a més amb CertPublisher="Adlice". Les quatre apareixen després com a <DeniedSigner>. Traduït: qualsevol binari que es digui Truesight, sigui anterior a la 3.3.0.0 i vingui signat per una d'aquelles cadenes, es denega. Els vuit bytes no canvien el nom, no canvien la versió i no canvien el signant.

Si vols refer el compte, són dues línies sobre l'XML que ja tens descarregat:

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

Llavors, per què carregava?

Perquè la regla existia i no cobria aquell cas. Segons Check Point, el TBS del certificat amb què estava signada la 2.0.2 era a la llista associat a un altre controlador, no a truesight, així que la combinació de nom i signant no tancava. Microsoft ho va corregir el 17 de desembre del 2024 després de l'avís dels investigadors, i la valoració de Check Point sobre la llista actualitzada és que «effectively prevents all variants of the legacy driver exploited in this campaign». Totes les variants, amb els seus vuit bytes i tot.

No va ser criptografia, va ser una regla incompleta. Aquella diferència importa a l'hora de decidir què compres i què escrius: contra un fitxer mutant aguanta la regla que descriu el fitxer per allò que no pot canviar sense deixar de ser ell.

La clau de registre del 2013 tampoc no és la resposta

L'altra reacció habitual a aquest tema és apuntar a CVE-2013-3900, la «WinVerifyTrust Signature Validation Vulnerability», que descriu exactament el forat conceptual: «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 va publicar la correcció el 10 de desembre del 2013 com a funció voluntària, i el 29 de juliol del 2014 va anunciar que no la imposaria per defecte. Dotze anys després encara és una clau que escrius tu, a les dues branques del registre, amb reinici:

; 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

Per directiva de grup és la plantilla MS Security Guide del Microsoft Security Compliance Toolkit, política Enable Certificate Padding. I per estalviar-te una discussió amb l'escàner de compliment: la revisió de l'avís del 23 de desembre del 2024 aclareix que «although Windows treats the EnableCertPaddingCheck value as a DWORD, its actual registry value type does not matter» mentre la dada ocupi d'1 a 4 bytes i algun no sigui zero, i afegeix que «compliance validation tools should not fail the EnableCertPaddingCheck inspection for its value type».

La nostra primera lectura va ser que activar aquella clau tancava la porta del controlador. És fals, i ho tanca el mateix apartat de preguntes freqüents de l'avís. La pregunta, literal: «Does the new verification behavior impact Windows Defender Application Control (WDAC)?». La resposta, també literal: «No. The new verification behavior does not impact WDAC.» La clau canvia WinVerifyTrust, que és verificació en mode usuari, i Microsoft sí que diu que afecta regles d'AppLocker i Software Restriction Policies que depenguin de l'editor. La càrrega de controladors al nucli va per integritat de codi, que és l'altra canonada.

Val la pena activar-la igual, pel que sí que cobreix, però amb la factura al davant: «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», sobretot els que es personalitzen en el moment de la descàrrega. I signar amb eines que no siguin les de Microsoft «runs the risk of signatures being recognized as non-compliant», cosa que apunta a programari propi i de proveïdor petit. Es prova abans. Al catàleg de vulnerabilitats explotades de CISA, per cert, aquest CVE va entrar el 10 de gener del 2022 i la seva data límit, el 10 de juliol d'aquell any, va vèncer fa 1.580 dies. L'acció obligatòria diu «apply updates per vendor instructions», i la instrucció del fabricant és que no hi ha actualització per aplicar.

Mentrestant, el catàleg de drivers manllevats creix

ESET va publicar el 9 d'abril del 2026 el seu recompte: gairebé 90 eines dedicades a matar, congelar o encegar programari de seguretat detectades en circulació, 54 d'elles amb la tècnica de carregar un controlador vulnerable però signat, abusant de 35 controladors diferents. El 18 de juny, Jakub Souček va publicar l'anàlisi de GentleKiller, el matador que el grup Gentlemen desenvolupa i ofereix als seus afiliats: almenys vuit variants del mateix bastiment, més de 400 processos mapejats a 48 productes de seguretat, i controladors manllevats que inclouen el d'una suite de prevenció de fuga de dades (stpm_*.sys, de Safetica) i el d'un antimalware domèstic (dmx.sys, de Zemana). Kaspersky ho va resumir al seu informe del 12 de maig: «tools commonly referred to as "EDR killers" have become a standard component of attack playbooks». I, a la mateixa pàgina, la recomanació que encaixa amb tot l'anterior: «for Windows environments, enabling Microsoft's Vulnerable Driver Blocklist is critical to thwarting BYOVD attacks».

La regla que va funcionar era una línia de text

La defensa que va funcionar en aquest cas va ser una línia de text que descrivia un controlador pel seu nom, la seva versió i qui l'havia signat. La va escriure Microsoft, i va tardar a escriure-la bé. Aquella és la forma de la protecció que serveix contra un fitxer que muta, i també és la forma de la protecció que cal mantenir: la llista oficial és el terra, no el sostre, i ESET recomana per damunt d'ella forçar la integritat de codi amb HVCI i una política pròpia de quins controladors poden carregar. Això és un document que algú escriu, prova i revisa. D'això va la nostra ciberseguretat.

I queda el buit que cap llista no cobreix, perquè una llista només coneix el que ja ha passat. Per al controlador que encara no hi és, el senyal que et queda és que un agent deixi de parlar. Ja ho vam escriure mirant què et queda quan quatre EDR no treuen ni una alerta: quan la detecció falla, l'únic que queda és telemetria desada fora de l'equip i algú que la consulti. Aquella segona part és la diferència entre tenir un EDR i tenir EDR/MDR gestionat: no l'agent, el torn. És el que fem a everyWAN, i és el que distingeix un equip que es va apagar d'un equip a qui li van apagar l'agent.

El que NO estem dient

No diem que el truc dels vuit bytes sigui inofensiu. Es menja la detecció per hash pla, i això és molta detecció: regles d'antivirus, llistes d'indicadors, consultes a VirusTotal, inventaris comunitaris de controladors abusables. El que no es menja és la decisió de si el controlador carrega al nucli.

Ens corregim a nosaltres mateixos, a més. Al post del 6 d'octubre vam titular una secció «per què un hash envelleix i un certificat no tant». Continua sent cert per la via que importa —un controlador nou, una versió nova, un signant nou—, però no per aquests vuit bytes, i en escriure-ho no vam distingir el hash Authenticode del hash pla. Aquí queda dit. I una acotació més: que els 1.702 hashos de la llista siguin Authenticode i de pàgina, i cap pla, és una lectura nostra a partir del nom descriptiu de cada regla; l'ordre per comprovar-ho és a dalt. Del truc en si no n'hem fet laboratori: aquella part ens la creiem de Check Point, que la va publicar amb mètode i data.

Fonts. Consultades el 6 de novembre del 2026. Les 2.500 variants, els vuit bytes repartits entre el camp CheckSum i el farciment de WIN_CERTIFICATE, els 192 processos, la versió 2.0.2 de truesight.sys, el motiu del TBS del certificat, la data del 17 de desembre del 2024 i les frases «hash-based detection alone proves ineffective» i «effectively prevents all variants…» són de «Silent Killers», de Check Point Research (24 de febrer del 2025). El que Authenticode exclou del càlcul del hash és a l'especificació del format PE de Microsoft i al document Windows Authenticode Portable Executable Signature Format. El recompte de la llista (versió 10.0.29545.0, 1.713 regles Deny, 1.702 per hash amb el seu desglossament per tipus, la línia de FileAttrib de truesight i les quatre regles de signant que la referencien) és nostre, sobre el fitxer DriverPolicy_Enforced.xml descarregat aquell dia d'aka.ms/VulnerableDriverBlockList; les ordres per refer-ho són a l'article. El títol del CVE, la descripció, les dates del 2013 i el 2014, el bloc de registre, la ruta de directiva de grup, l'aclariment sobre el tipus del valor de la revisió del 23 de desembre del 2024 i les respostes del FAQ sobre WDAC, AppLocker, Software Restriction Policies i instal·ladors surten de la fitxa oficial de CVE-2013-3900 del Microsoft Security Response Center, llegida per la seva API pública. Les dates del catàleg KEV són del JSON públic de CISA, versió 2026.11.04. Les gairebé 90 eines, les 54 amb BYOVD, els 35 controladors i la recomanació d'HVCI són de l'article «What are EDR killers?» d'ESET (9 d'abril del 2026). Les variants de GentleKiller, els processos, els productes i els controladors de Safetica i Zemana són de «Killing me gently», de Jakub Souček (ESET, 18 de juny del 2026). Les dues cites de Kaspersky són de l'informe de l'estat del ransomware publicat a Securelist el 12 de maig del 2026. Les cites es deixen en el seu anglès original perquè es puguin cercar textualment. La fotografia de la imatge social és «Computer Lab Baraboo», de JackFromWisconsin, CC0 via Wikimedia Commons, retallada per nosaltres.