Windows bloquea controladores vulnerables desde hace años y casi nadie ha mirado qué hay dentro de esa lista. Nosotros la descargamos esta mañana y la contamos: 1.713 reglas de bloqueo, de las cuales 1.702 identifican el fichero por su hash.
Hace cuatro días escribimos aquí que memory integrity se activa sola en los equipos nuevos y en buena parte del parque. Esto es la continuación incómoda de aquel post. Activarla está bien —insistimos en que la actives—, pero conviene saber exactamente qué enciendes, porque lo que enciendes es, en su mayor parte, una lista de hashes.
Qué nos descargamos y qué contamos
Microsoft publica la lista de controladores vulnerables como una política de App Control descargable desde aka.ms/VulnerableDriverBlockList. Dentro del ZIP hay cuatro ficheros; el que importa es DriverPolicy_Enforced.xml, medio megabyte de XML. Lo bajamos el 6 de octubre de 2026 y contamos los elementos a mano. Estos son los números, y cualquiera puede repetirlos en cinco minutos:
- ·1.713 elementos
<Deny>en total. - ·1.702 de ellos llevan atributo
Hash: bloquean un binario concreto, byte a byte. - ·11 bloquean por nombre de fichero. Once. De mil setecientas trece.
- ·218 elementos
<Signer>: bloqueos por certificado, que es la parte que podría no caducar. Volveremos a ella, porque solo a veces no caduca.
La política se identifica a sí misma como Microsoft Windows Driver Policy, versión 10.0.29545.0. Si cuando leas esto el número ha cambiado, mejor: significa que se ha actualizado.
Si quieres repetir la cuenta en tu máquina, descomprime el ZIP y cuenta sobre el XML. Dos líneas de PowerShell:
$x = [xml](Get-Content .\DriverPolicy_Enforced.xml)
$d = $x.SiPolicy.FileRules.Deny
"Deny: {0} | por hash: {1} | por nombre: {2} | Signer: {3}" -f `
$d.Count, ($d | ? Hash).Count, ($d | ? FileName).Count, $x.SiPolicy.Signers.Signer.CountLo que Microsoft dice de su propia lista
La parte más honesta de este asunto no la decimos nosotros: la dice Microsoft, en la misma página desde la que te descargas el fichero. Están seguidas, en una nota al pie que casi nadie abre:
«The vulnerable driver blocklist isn't guaranteed to block every driver found to have vulnerabilities.»
La lista no garantiza bloquear todos los controladores en los que se encuentren vulnerabilidades.
«It's often necessary for us to hold back some blocks to avoid breaking existing functionality…»
A menudo tienen que retener bloqueos para no romper funcionalidad existente.
«The blocklist included in this article and in the associated downloadable files usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update.»
La lista que te descargas suele ser MÁS completa que la que llevas puesta en el sistema operativo.
La tercera es la que nos dejó callados un rato. Las 1.713 reglas que acabamos de contar no son las que tiene tu portátil. Las que tiene tu portátil suelen ser, por admisión del fabricante, un subconjunto. Sobre el ritmo, Microsoft es precisa y conviene citarla entera: «The blocklist is updated quarterly», y además «blocklist updates are delivered through the monthly Windows updates as part of the standard servicing process». O sea: revisión completa cada trimestre, goteo cada mes. La página que publica el fichero llevaba fecha de 1 de mayo de 2026 el día que escribimos esto.
479 muestras que cargan con memory integrity puesta
Existe un catálogo público y comunitario de controladores firmados de los que se puede abusar: LOLDrivers. No es un boletín de fabricante y conviene decirlo claro: lo mantiene la comunidad, cualquiera puede contribuir y sus campos son anotaciones, no certificaciones. Dicho eso, es la mejor foto pública que hay, y tiene un campo que lo cambia todo: LoadsDespiteHVCI —«carga a pesar de HVCI», es decir, a pesar de memory integrity—.
Nos bajamos el JSON el mismo día y lo contamos igual que el de Microsoft. 702 controladores catalogados, 2.407 muestras. El campo LoadsDespiteHVCI está relleno en 2.145 de ellas (262 están sin anotar y las hemos dejado fuera del denominador, que es lo honesto). De esas 2.145, 479 están marcadas como que cargan igual: un 22,3%. A nivel de entrada —no de muestra—, 230 de los 702 controladores del catálogo tienen al menos una muestra así: casi un tercio.
El contraste que importa: 45% contra 18%
El catálogo separa dos familias: controladores legítimos pero vulnerables (el driver de una utilidad de diagnóstico, de un antivirus viejo, de una herramienta de overclocking) y controladores maliciosos, escritos o manipulados a propósito para esto. Cuando separas la cuenta por familia, sale esto:
| Familia | Muestras anotadas | Cargan con HVCI | % |
|---|---|---|---|
| Legítimos pero vulnerables | 1.819 | 332 | 18,3% |
| Maliciosos (hechos para esto) | 326 | 147 | 45,1% |
| Total | 2.145 | 479 | 22,3% |
Casi una de cada dos muestras de controlador hechas a propósito para esto se salta memory integrity, contra menos de una de cada cinco de las que simplemente tenían una fallada. La diferencia admite dos lecturas y ninguna es tranquilizadora. La primera: quien escribe el driver sabe qué protección tienes puesta y optimiza contra ella. La segunda, más incómoda y probablemente más cierta: un controlador malicioso entra en este catálogo porque alguien lo vio funcionando en un incidente real; los que memory integrity paró no generan incidente, no se reportan y no se catalogan. Si es la segunda, el 45% no mide pericia del atacante: mide lo que llegó a vernos.
Sea cual sea la lectura, el número que te llevas es el mismo y es bueno: sobre las 2.145 muestras anotadas del catálogo, memory integrity frena 1.666. Un 77,7%. Eso es muchísimo para algo que viene de serie y no cuesta nada. Pero un 77,7% es un filtro, y un filtro no es un perímetro.
Por qué un hash envejece y un certificado no tanto
Un hash identifica ese fichero. Cambia un byte, recompila, vuelve a firmar con otro certificado comprado o robado, y tienes un binario que hace exactamente lo mismo y cuyo hash no está en ninguna lista del mundo. Por eso 1.702 reglas de hash envejecen desde el minuto uno: cubren el pasado con una precisión excelente y el futuro con ninguna.
Aquí es donde esperábamos encontrar el contrapeso, y lo encontramos a medias. Fuimos a los 218 bloqueos por firmante pensando que serían la parte sólida —quemar un certificado tumba todo lo firmado con él, pasado y futuro— y al contarlos salió otra cosa: solo 50 queman un publicador entero. Los otros 168 van atados a un FileAttrib con nombre de fichero y rango de versión, y de los 156 que declaran versión máxima, 79 están topados a una versión concreta (del estilo MaximumFileVersion="1.12.802.2023"). Traducido: subes el número de versión y la regla ya no te alcanza. El mecanismo que no caduca existe y está usado en 50 casos de 218.
Dos líneas de letra pequeña que cambian tu procedimiento
Si solo te llevas dos frases operativas de este post, que sean estas dos, ambas de la documentación oficial:
- 1Aplicar la política no expulsa de memoria lo que ya está cargado. Literal: «If any vulnerable drivers are already running that the policy would block, you must reboot your computer for those drivers to be blocked». Si el controlador ya está dentro, sigue dentro hasta que el equipo reinicie. Tu ventana de reinicio es parte de tu seguridad, te guste o no.
- 2La regla ASR de drivers vulnerables no hace lo que crees. Microsoft lo escribe así: «The ASR rule doesn't block a driver already existing on the system from loading». Impide que una aplicación escriba el driver en disco; no impide que cargue el que ya está. Y la frase sigue, porque Microsoft no deja el hueco abierto: «however enabling Microsoft vulnerable driver blocklist or applying this App Control policy prevents the existing driver from loading». Es decir, ese hueco lo tapa la lista, no el ASR. Son dos controles distintos y mucha gente cree que tiene los dos cuando solo ha activado uno.
Entonces, ¿qué sí?
Lo que una lista no puede hacer por definición es notar que un controlador firmado, legítimo y que carga perfectamente está haciendo algo que no toca a las tres de la mañana. Eso no se bloquea: se detecta, y alguien tiene que mirarlo. Es exactamente la diferencia entre una prevención y una detección y respuesta gestionada, y por qué llevamos tiempo diciendo que tener la herramienta no es tener el servicio.
Las cuatro cosas que pediríamos ver si esto sale en una revisión, por orden de dificultad:
- ✓Memory integrity activada y censada. No «activada en los nuevos»: censada equipo a equipo, con la lista de los que no la tienen y el motivo escrito al lado. Un porcentaje no es un inventario.
- ✓La lista descargable encima de la del sistema, en modo auditoría primero. Microsoft avisa de que bloquear drivers puede tumbar equipos; se prueba en un grupo y se leen los eventos de bloqueo en auditoría —el 3076 de
CodeIntegrity/Operational, que es el que te dice qué se habría bloqueado— antes de forzar nada. Ojo con la confusión habitual: el 3099 solo confirma que la política ha cargado, no qué habría roto. - ✓Una alerta por carga de controlador de kernel no habitual, no por nombre conocido. El nombre lo cambian; el hecho de que un servicio instale un driver a las 03:40 en un portátil de administración, no.
- ✓Alguien de guardia que reciba esa alerta. Una detección a las 03:40 que se lee a las 09:00 es un informe forense, no una respuesta. Esta es la parte que no se compra con una casilla.
Lo que NO estamos diciendo
No estamos diciendo que apagues memory integrity: justo lo contrario. Una protección que filtra cuatro de cada cinco muestras conocidas vale muchísimo y es gratis. Tampoco estamos diciendo que Microsoft lo haga mal; de hecho, lo que hace bien es escribir en su propia página lo que su lista no cubre, que es más de lo que hacen muchos. Y tampoco estamos diciendo que un programa de seguridad se resuelva comprando otra herramienta.
Lo que estamos diciendo es más pequeño y más incómodo: si tu respuesta a «¿y los drivers vulnerables?» es «tenemos memory integrity», acabas de responder con 1.702 hashes que envejecen y un subconjunto de ellos. Es una buena respuesta a medias. La otra mitad tiene nombre y apellidos y no es un producto: es alguien mirando lo que carga, y alguien despierto cuando salta.
Fuentes y método (todo reproducible): recuentos propios hechos el 6 de octubre de 2026. Las 1.713 reglas <Deny>, las 1.702 por hash, las 11 por nombre y los 218 <Signer> salen de contar los elementos de DriverPolicy_Enforced.xml (política Microsoft Windows Driver Policy 10.0.29545.0), descargado de aka.ms/VulnerableDriverBlockList. Las citas literales y la cadencia trimestral, de Microsoft recommended driver block rules (Microsoft Learn, fecha del artículo 1-may-2026). Los 702 controladores, 2.407 muestras y 479 marcadas LoadsDespiteHVCI salen del JSON público de LOLDrivers, catálogo COMUNITARIO (no de fabricante): sus campos son anotaciones de la comunidad y las 262 muestras sin anotar quedan fuera del denominador. Los porcentajes son nuestros, calculados sobre esas cifras.
¿Sabes qué carga en el kernel de tus equipos cuando no hay nadie mirando?
En everyWAN operamos EDR/MDR gestionado con guardia 24x7: la detección de madrugada se atiende de madrugada, no a la mañana siguiente. Y no te vendemos una herramienta más si ya tienes la que necesitas: no somos resellers de nadie.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN