Ocho bytes y el driver sigue firmado

La historia se cuenta así: alguien cogió un controlador firmado, le cambió ocho bytes, repitió la operación 2.500 veces y se paseó por delante de la lista de controladores bloqueados de Windows con un fichero distinto cada día. La primera mitad es verdad y está documentada. La segunda la desmiente el propio fichero de la lista, que pesa medio mega y se baja en treinta segundos. Lo hemos hecho esta mañana y hemos contado lo que hay dentro.

Los ocho bytes existen y están medidos

La parte documentada la publicó Check Point Research el 24 de febrero de 2025 bajo el título «Silent Killers». El sujeto era truesight.sys en su versión 2.0.2, el controlador antirootkit de Adlice, con un fallo de terminación arbitraria de procesos en las ramas por debajo de la 3.4.0: un driver legítimo, firmado por su fabricante, al que se le puede pedir que mate procesos. El módulo que lo usaba apuntaba a 192 procesos, sobre todo de software de seguridad.

Check Point encontró más de 2.500 variantes distintas del mismo fichero. La diferencia entre una y otra eran ocho bytes: cuatro en el campo CheckSum de la cabecera PE y cuatro en el relleno de la estructura WIN_CERTIFICATE. Zonas que, dice la investigación, quedan «excluded from the hash calculation during the signing process». Por eso la firma sobrevive intacta a las 2.500 copias. El objetivo lo resume la propia publicación en cuatro palabras: «hash-based detection alone proves ineffective».

La exclusión que salva la firma salva también el hash

La especificación de Authenticode excluye del cálculo del hash tres cosas: el campo CheckSum de la cabecera opcional, la entrada de la tabla de certificados en el directorio de datos, y la propia tabla de certificados. Se excluyen precisamente porque firmar el fichero las modifica, y si entraran en la cuenta ninguna firma podría ser válida sobre el fichero ya firmado.

Esos son exactamente los dos sitios donde se escriben los ocho bytes. De modo que el truco no sólo deja la firma válida: deja también idéntico el hash Authenticode, que es el que usa Windows para decidir si un controlador carga. Lo que sí cambia con los ocho bytes es el hash plano del fichero entero, el que calcula sha256sum, el que aparece en VirusTotal y el que llevan las listas comunitarias de controladores abusables. Para esas fuentes hay 2.500 ficheros. Para el núcleo de Windows hay uno.

Lo contamos en el fichero, y la regla que bloquea no mira el hash

La lista oficial se descarga de aka.ms/VulnerableDriverBlockList. La versión que bajamos hoy, 6 de noviembre de 2026, se identifica como Microsoft Windows Driver Policy con <VersionEx>10.0.29545.0</VersionEx>. Dentro hay 1.713 reglas <Deny>: 1.702 con atributo Hash y 11 con FileName. Los mismos números que el recuento de la lista de controladores bloqueados que publicamos el 6 de octubre.

Lo que no habíamos mirado entonces es de qué tipo son esos 1.702 hashes. El nombre descriptivo de cada regla lo dice. Contados hoy:

Hashes Authenticode y hashes de página. Ningún hash plano de fichero. Y el hash de página no cambia el argumento: la página cero, que es donde vive el CheckSum, se calcula con las mismas exclusiones. Así que aunque truesight estuviera bloqueado por hash, los ocho bytes no lo habrían movido. Y resulta que ni siquiera está bloqueado por hash: buscando truesight en el XML salen catorce líneas y ninguna es una regla de hash. La que define el fichero es esta:

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

Nombre original del fichero y rango de versiones. A esa definición la referencian cuatro reglas de firmante —ID_SIGNER_TRUESIGHT_1 a _4—, repartidas entre tres cadenas de certificación: una de Sectigo y dos de DigiCert, estas últimas además con CertPublisher="Adlice". Las cuatro aparecen luego como <DeniedSigner>. Traducido: cualquier binario que se llame Truesight, sea anterior a la 3.3.0.0 y venga firmado por una de esas cadenas, se deniega. Los ocho bytes no cambian el nombre, no cambian la versión y no cambian el firmante.

Si quieres rehacer la cuenta, son dos líneas sobre el XML que ya tienes descargado:

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

Entonces, ¿por qué cargaba?

Porque la regla existía y no cubría ese caso. Según Check Point, el TBS del certificado con el que estaba firmada la 2.0.2 estaba en la lista asociado a otro controlador, no a truesight, así que la combinación de nombre y firmante no cerraba. Microsoft lo corrigió el 17 de diciembre de 2024 tras el aviso de los investigadores, y la valoración de Check Point sobre la lista actualizada es que «effectively prevents all variants of the legacy driver exploited in this campaign». Todas las variantes, con sus ocho bytes y todo.

No fue criptografía, fue una regla incompleta. Esa diferencia importa a la hora de decidir qué compras y qué escribes: contra un fichero mutante aguanta la regla que describe al fichero por lo que no puede cambiar sin dejar de ser él.

La clave de registro de 2013 tampoco es la respuesta

La otra reacción habitual a este tema es apuntar a CVE-2013-3900, la «WinVerifyTrust Signature Validation Vulnerability», que describe exactamente el agujero 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 publicó la corrección el 10 de diciembre de 2013 como función voluntaria, y el 29 de julio de 2014 anunció que no la impondría por defecto. Doce años después sigue siendo una clave que escribes tú, en las dos ramas del registro, con reinicio:

; 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

Por directiva de grupo es la plantilla MS Security Guide del Microsoft Security Compliance Toolkit, política Enable Certificate Padding. Y para ahorrarte una discusión con el escáner de cumplimiento: la revisión del aviso del 23 de diciembre de 2024 aclara que «although Windows treats the EnableCertPaddingCheck value as a DWORD, its actual registry value type does not matter» mientras el dato ocupe de 1 a 4 bytes y alguno no sea cero, y añade que «compliance validation tools should not fail the EnableCertPaddingCheck inspection for its value type».

Nuestra primera lectura fue que activar esa clave cerraba la puerta del controlador. Es falso, y lo zanja el propio apartado de preguntas frecuentes del aviso. La pregunta, literal: «Does the new verification behavior impact Windows Defender Application Control (WDAC)?». La respuesta, también literal: «No. The new verification behavior does not impact WDAC.» La clave cambia WinVerifyTrust, que es verificación en modo usuario, y Microsoft sí dice que afecta a reglas de AppLocker y a Software Restriction Policies que dependan del editor. La carga de controladores en el núcleo va por integridad de código, que es la otra tubería.

Vale la pena activarla igual, por lo que sí cubre, pero con la factura delante: «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», sobre todo los que se personalizan en el momento de la descarga. Y firmar con herramientas que no sean las de Microsoft «runs the risk of signatures being recognized as non-compliant», lo que apunta a software propio y de proveedor pequeño. Se prueba antes. En el catálogo de vulnerabilidades explotadas de CISA, por cierto, este CVE entró el 10 de enero de 2022 y su fecha límite, el 10 de julio de ese año, venció hace 1.580 días. La acción obligatoria dice «apply updates per vendor instructions», y la instrucción del fabricante es que no hay actualización que aplicar.

Mientras tanto, el catálogo de drivers prestados crece

ESET publicó el 9 de abril de 2026 su recuento: casi 90 herramientas dedicadas a matar, congelar o cegar software de seguridad detectadas en circulación, 54 de ellas con la técnica de cargar un controlador vulnerable pero firmado, abusando de 35 controladores distintos. El 18 de junio, Jakub Souček publicó el análisis de GentleKiller, el matador que el grupo Gentlemen desarrolla y ofrece a sus afiliados: al menos ocho variantes del mismo armazón, más de 400 procesos mapeados a 48 productos de seguridad, y controladores prestados que incluyen el de una suite de prevención de fuga de datos (stpm_*.sys, de Safetica) y el de un antimalware doméstico (dmx.sys, de Zemana). Kaspersky lo resumió en su informe del 12 de mayo: «tools commonly referred to as "EDR killers" have become a standard component of attack playbooks». Y, en la misma página, la recomendación que encaja con todo lo anterior: «for Windows environments, enabling Microsoft's Vulnerable Driver Blocklist is critical to thwarting BYOVD attacks».

La regla que funcionó era una línea de texto

La defensa que funcionó en este caso fue una línea de texto que describía un controlador por su nombre, su versión y quién lo había firmado. La escribió Microsoft, y tardó en escribirla bien. Esa es la forma de la protección que sirve contra un fichero que muta, y también es la forma de la protección que hay que mantener: la lista oficial es el suelo, no el techo, y ESET recomienda por encima de ella forzar la integridad de código con HVCI y una política propia de qué controladores pueden cargar. Eso es un documento que alguien escribe, prueba y revisa. De eso va nuestra ciberseguridad.

Y queda el hueco que ninguna lista cubre, porque una lista sólo conoce lo que ya ha pasado. Para el controlador que todavía no está en ella, la señal que te queda es que un agente deje de hablar. Ya lo escribimos mirando qué te queda cuando cuatro EDR no sacan ni una alerta: cuando la detección falla, lo único que queda es telemetría guardada fuera del equipo y alguien que la consulte. Esa segunda parte es la diferencia entre tener un EDR y tener EDR/MDR gestionado: no el agente, el turno. Es lo que hacemos en everyWAN, y es lo que distingue un equipo que se apagó de un equipo al que le apagaron el agente.

Lo que NO estamos diciendo

No decimos que el truco de los ocho bytes sea inofensivo. Se come la detección por hash plano, y eso es mucha detección: reglas de antivirus, listas de indicadores, consultas en VirusTotal, inventarios comunitarios de controladores abusables. Lo que no se come es la decisión de si el controlador carga en el núcleo.

Nos corregimos a nosotros mismos, además. En el post del 6 de octubre titulamos una sección «por qué un hash envejece y un certificado no tanto». Sigue siendo cierto por la vía que importa —un controlador nuevo, una versión nueva, un firmante nuevo—, pero no por estos ocho bytes, y al escribirlo no distinguimos el hash Authenticode del hash plano. Aquí queda dicho. Y una acotación más: que los 1.702 hashes de la lista sean Authenticode y de página, y ninguno plano, es una lectura nuestra a partir del nombre descriptivo de cada regla; el comando para comprobarlo está arriba. Del truco en sí no hemos hecho laboratorio: esa parte nos la creemos de Check Point, que la publicó con método y fecha.

Fuentes. Consultadas el 6 de noviembre de 2026. Las 2.500 variantes, los ocho bytes repartidos entre el campo CheckSum y el relleno de WIN_CERTIFICATE, los 192 procesos, la versión 2.0.2 de truesight.sys, el motivo del TBS del certificado, la fecha del 17 de diciembre de 2024 y las frases «hash-based detection alone proves ineffective» y «effectively prevents all variants…» son de «Silent Killers», de Check Point Research (24 de febrero de 2025). Lo que Authenticode excluye del cálculo del hash está en la especificación del formato PE de Microsoft y en el documento Windows Authenticode Portable Executable Signature Format. El recuento de la lista (versión 10.0.29545.0, 1.713 reglas Deny, 1.702 por hash con su desglose por tipo, la línea de FileAttrib de truesight y las cuatro reglas de firmante que la referencian) es nuestro, sobre el fichero DriverPolicy_Enforced.xml descargado ese día de aka.ms/VulnerableDriverBlockList; los comandos para rehacerlo están en el artículo. El título del CVE, la descripción, las fechas de 2013 y 2014, el bloque de registro, la ruta de directiva de grupo, la aclaración sobre el tipo del valor de la revisión del 23 de diciembre de 2024 y las respuestas del FAQ sobre WDAC, AppLocker, Software Restriction Policies e instaladores salen de la ficha oficial de CVE-2013-3900 del Microsoft Security Response Center, leída por su API pública. Las fechas del catálogo KEV son del JSON público de CISA, versión 2026.11.04. Las casi 90 herramientas, las 54 con BYOVD, los 35 controladores y la recomendación de HVCI son del artículo «What are EDR killers?» de ESET (9 de abril de 2026). Las variantes de GentleKiller, los procesos, los productos y los controladores de Safetica y Zemana son de «Killing me gently», de Jakub Souček (ESET, 18 de junio de 2026). Las dos citas de Kaspersky son del informe del estado del ransomware publicado en Securelist el 12 de mayo de 2026. Las citas se dejan en su inglés original para que se puedan buscar textualmente. La fotografía de la imagen social es «Computer Lab Baraboo», de JackFromWisconsin, CC0 vía Wikimedia Commons, recortada por nosotros.