Lista de bloqueo de controladores vulnerables: frenar BYOVD

Cargar un controlador de kernel requiere derechos de administrador y una firma válida. Los atacantes que ya tienen derechos de administrador quieren el kernel, porque desde ahí pueden matar los procesos del EDR, quitar la protección LSA a LSASS o desactivar la protección contra alteraciones. No pueden firmar un controlador malicioso, así que traen uno firmado legítimamente con una vulnerabilidad conocida, lo cargan y la explotan. Eso es bring your own vulnerable driver (BYOVD), y así funcionan la mayoría de las herramientas «EDR killer» que usan los afiliados de ransomware.

La lista de bloqueo de controladores vulnerables de Microsoft es una directiva de App Control que se niega a cargar controladores conocidos como vulnerables o maliciosos. Microsoft la mantiene junto con los fabricantes de hardware y la incluye en Windows. Esta guía profundiza más que la mención del pilar de App Control: cómo confirmar que está activa, cómo mantenerla al día y cómo tratar sus huecos.

Qué es la lista de bloqueo y qué no es

No es una lista de permitidos completa de controladores. Un controlador vulnerable que Microsoft aún no haya añadido se cargará. Por eso la lista de bloqueo es una base que hay que combinar con detección y, en los sistemas de alto valor, con una directiva completa de App Control.

Paso 1: comprobar el estado actual

En un equipo concreto, Seguridad de Windows la muestra en Device security > Core isolation details > Microsoft Vulnerable Driver Blocklist. Cuando están activados la integridad de memoria, Smart App Control o el modo S, el conmutador está activado y atenuado, porque esas funciones siempre aplican la lista de bloqueo.

La opción detrás del conmutador es un valor del Registro:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" -Name VulnerableDriverBlocklistEnable

1 significa activada. Comprueba también si la integridad de memoria se está ejecutando, ya que garantiza la aplicación:

(Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard).SecurityServicesRunning   # 2 = integridad de memoria (HVCI)

En toda la flota, recoge ambos valores con tu herramienta de administración, una extensión del inventario de hardware de Configuration Manager o un script de corrección de Intune en modo solo detección. Céntrate primero en Windows Server: los servidores actualizados en el sitio y las VM sin seguridad basada en virtualización son los huecos habituales.

Paso 2: activarla donde esté desactivada

La solución más sencilla es activar la integridad de memoria (HVCI), que trae consigo la lista de bloqueo y bloquea una clase más amplia de ataques al kernel. Donde HVCI todavía no sea posible (controladores incompatibles, hardware antiguo), establece la lista de bloqueo por sí sola:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" `
  -Name VulnerableDriverBlocklistEnable -Value 1 -Type DWord

Despliega ese valor con un elemento de Registro de las preferencias de directiva de grupo o con una corrección de Intune, y reinicia: la directiva de controladores se evalúa en el arranque. En las compilaciones donde el conmutador no existe, despliega en su lugar la lista de bloqueo como directiva de App Control (paso siguiente).

Paso 3: mantenerse al día entre versiones de Windows

La copia incluida en Windows va por detrás de la lista que publica Microsoft. Microsoft ofrece la lista de bloqueo más reciente como descarga (enlazada desde la página «Microsoft recommended driver block rules» de la documentación de App Control) en formato XML y binario, con variantes de auditoría y aplicada.

Dos formas de usarla:

1. Independiente: el método documentado por Microsoft consiste en renombrar el binario de auditoría o aplicado a SiPolicy.p7b, copiarlo en %windir%\System32\CodeIntegrity y ejecutar la herramienta de actualización de directivas de App Control (o reiniciar). Prueba primero la versión de auditoría en un anillo piloto. Ese nombre de archivo es la ranura de directiva única, así que sustituye cualquier directiva existente de formato único en el dispositivo. Donde el dispositivo admita varias directivas, Microsoft recomienda desplegar la lista de bloqueo junto a tus directivas existentes, por ejemplo convirtiendo el XML publicado (aquí DriverBlockRules.xml) a un .cip y aplicándolo con CiTool en Windows 11 22H2 y posteriores:

   PowerShell

   Copy-Item .\DriverBlockRules.xml .\DriverBlock.xml
   Set-CIPolicyIdInfo -FilePath .\DriverBlock.xml -ResetPolicyID   # formato de directivas múltiples, nuevo id.
   ConvertFrom-CIPolicy -XmlFilePath .\DriverBlock.xml -BinaryFilePath .\DriverBlock.cip
   CiTool.exe --update-policy .\DriverBlock.cip
   CiTool.exe --list-policies

   Los controladores que ya se están ejecutando solo se bloquean tras un reinicio.

2. Combinada en tu directiva base de App Control: si ya aplicas App Control, combina el XML publicado en tu base. El XML publicado contiene reglas de permitir todo para poder funcionar por sí solo; elimina esas reglas antes de combinarlo con una directiva de lista de permitidos, o abrirás tu lista por completo.

   PowerShell

   Merge-CIPolicy -PolicyPaths .\Base.xml, .\DriverBlockRules.xml -OutputFilePath .\Base-merged.xml

Elijas lo que elijas, añade una tarea periódica a tu calendario de cambios: revisa la versión publicada cada trimestre y tras cada divulgación importante de BYOVD.

Paso 4: añadir la regla ASR y la detección

La lista de bloqueo impide que un controlador se cargue. Dos capas más ayudan:

• La regla ASR «Block abuse of exploited vulnerable signed drivers» (GUID 56a863a9-875e-4185-98a7-b882c64b5ce5) impide que las aplicaciones escriban en disco controladores vulnerables conocidos. Ponla en bloqueo; forma parte del conjunto de protección estándar descrito en la guía de reglas ASR.
• Detección de cargas de controladores. El evento 6 de Sysmon (controlador cargado) registra el hash y la firma de cada controlador. Compara los hashes nuevos con tu inventario de controladores conocidos y con listas de la comunidad como LOLDrivers. El evento 7045 del registro System (se instaló un servicio) detecta la creación del servicio que suele preceder a la carga de un controlador.

Los controladores usados en ataques BYOVD reales suelen ser utilidades antiguas firmadas legítimamente: herramientas de overclocking, actualizadores de firmware de fabricantes y componentes antitrampas. El mismo archivo firmado puede ser inofensivo en un PC de juegos y una señal de alarma en un servidor de archivos.

Una forma rápida de revisar las cargas de controladores en un equipo con Sysmon instalado:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=6} -MaxEvents 500 |
  ForEach-Object { $x = [xml]$_.ToXml(); [pscustomobject]@{
    Time      = $_.TimeCreated
    Driver    = ($x.Event.EventData.Data | Where-Object Name -eq 'ImageLoaded').'#text'
    Signature = ($x.Event.EventData.Data | Where-Object Name -eq 'Signature').'#text'
    Hashes    = ($x.Event.EventData.Data | Where-Object Name -eq 'Hashes').'#text' } } |
  Sort-Object Driver -Unique

Todo lo que se cargue desde un perfil de usuario, C:\ProgramData, C:\Windows\Temp u otra ubicación con permisos de escritura es sospechoso, tenga la firma que tenga.

Paso 5: ir más allá en los servidores

La lista de bloqueo responde a «¿se sabe que este controlador es malo?». En los servidores puedes plantear la pregunta más exigente «¿se espera este controlador aquí?». El hardware de los servidores cambia poco, así que el conjunto de controladores es pequeño y estable, lo que hace realista una lista de permitidos de controladores:

1. Construye una directiva de App Control a partir de un servidor de referencia de cada modelo de hardware, con los controladores de kernel en el nivel de editor (New-CIPolicy -Level Publisher -Fallback Hash -ScanPath C:\Windows\System32\drivers).
2. Combina en ella las reglas de bloqueo de controladores recomendadas, sin sus reglas de permitir todo.
3. Ejecútala en modo auditoría durante un ciclo de parches completo, incluidas las actualizaciones de firmware y de controladores de almacenamiento, y después aplícala.

Si ahora mismo es demasiado, mantén al menos un inventario de controladores por modelo de servidor y genera alertas ante cualquier controlador cuyo hash no se haya visto nunca en tu parque. La guía del instalador administrado explica cómo mantener esa directiva cuando crece más allá de los controladores.

Qué se rompe

Muy poco, por eso este control debería ser universal. Los casos raros:

• Utilidades de hardware antiguas: herramientas de fabricantes que incluyen una versión vulnerable de un controlador (control de ventiladores, iluminación RGB, herramientas de actualización de BIOS). La solución es la versión actualizada del fabricante, que normalmente no está en la lista.
• Antitrampas o DRM heredados en dispositivos personales.
• Controladores industriales o de laboratorio especializados que nunca se actualizaron.

Cuando se bloquea un controlador, el dispositivo sigue arrancando, pero el componente no se inicia. Compruébalo antes de aplicar en servidores con hardware poco habitual, y resiste la tentación de desactivar la lista de bloqueo por una herramienta; sustituye o aísla la herramienta.

Verificarlo

1. Directiva activa: CiTool.exe --list-policies enumera las directivas activas, incluida la de bloqueo de controladores, con su versión; compara la versión con la que pretendías desplegar.
2. Activación en el arranque: en Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational, el evento 3099 registra cada directiva activada en el arranque, con su nombre y versión.
3. Bloqueos: los eventos 3077 (aplicado) y 3076 (auditoría) del mismo registro muestran un controlador que se bloqueó o se habría bloqueado. A continuación, el evento 3089 aporta los detalles de la firma.
4. Prueba con seguridad: no descargues controladores vulnerables en sistemas de producción para probar. Usa una VM de laboratorio aislada o limítate a las comprobaciones de directivas y eventos anteriores.

Reenvía los eventos de CodeIntegrity a tu SIEM. Un controlador bloqueado en un servidor casi nunca es un accidente; trata el evento 3077 de un controlador BYOVD conocido como una señal de intrusión activa e inicia la respuesta a incidentes.

Lista de comprobación

• VulnerableDriverBlocklistEnable = 1, o integridad de memoria en ejecución, en todos los clientes y servidores
• Servidores y VM sin seguridad basada en virtualización comprobados explícitamente
• Última lista de bloqueo publicada desplegada, probada antes en auditoría en un anillo piloto
• Reglas de permitir todo eliminadas antes de combinar la lista de bloqueo con una lista de permitidos de App Control
• Regla ASR de controladores firmados vulnerables en modo bloqueo
• Evento 6 de Sysmon y evento 7045 de System recopilados y revisados
• CodeIntegrity 3077 sobre controladores con alerta de gravedad alta
• Tarea trimestral para comprobar si hay una versión más reciente de la lista de bloqueo

La lista de bloqueo es un cambio pequeño con un efecto desproporcionado sobre la forma en que los atacantes desactivan tus defensas. Funciona mejor junto a la integridad de memoria y una directiva completa del área de control de aplicaciones, con el instalador administrado para mantener esa directiva.