De la alerta del antivirus al registro de riesgos: cómo se gestiona un driver vulnerable sin parar un equipo crítico
En ciberseguridad circula una regla que suena razonable:
«Si el antivirus detecta algo, elimínalo.»
En entornos industriales, de fabricación o de diagnosis, esa regla puede salir muy cara. Eliminar de forma automática un componente marcado como vulnerable es, en muchos casos, la forma más rápida de dejar inoperativo un equipo del que depende la actividad diaria.
Hace unos meses nos encontramos con un caso de este tipo durante una revisión rutinaria de seguridad sobre un equipo portátil de diagnosis utilizado en un entorno industrial. Pequeño y cotidiano, pero buen ejemplo de por qué conviene parar a analizar antes de actuar.
La alerta
Durante una comprobación habitual, la plataforma de protección clasificó un controlador del sistema dentro de una familia de detección de tipo «driver vulnerable».
Para muchos administradores el siguiente paso sería evidente: eliminar el archivo o ponerlo en cuarentena. Pero antes de tocar nada hay que responder a una pregunta:
¿Qué es realmente este controlador y qué pasa si desaparece?
Primer paso: ¿es malware?
Lo primero fue comprobar la firma digital del archivo. El controlador estaba correctamente firmado y la firma era válida, lo que descartaba una manipulación evidente.
Conviene insistir en algo que se confunde a menudo: una firma válida no convierte a un controlador en seguro. Un software perfectamente legítimo y firmado puede contener vulnerabilidades conocidas. Firma válida y «sin riesgo» no son lo mismo.
Segundo paso: ¿de dónde salió?
A través del almacén de controladores de Windows (Driver Store) confirmamos que el archivo procedía de un paquete INF oficial instalado en el sistema, firmado a través del programa de compatibilidad de hardware de Windows, y no de una copia manual ni de un programa desconocido.
Es decir: no era un archivo sospechoso colado en el equipo, sino un componente base del propio fabricante del dispositivo, instalado por canales oficiales.
Tercer paso: ¿se está usando?
El controlador estaba registrado como un servicio de tipo Kernel Driver. Aquí conviene desmontar un razonamiento tentador: que el driver tenga un inicio «bajo demanda» y no permanezca cargado de continuo no reduce el riesgo. En un ataque del tipo que veremos a continuación, es el propio atacante quien carga el archivo para explotarlo; cómo esté configurado su arranque le da igual.
Lo relevante era otra cosa: este controlador forma parte del software de bajo nivel que el equipo necesita para interactuar con el hardware. Eliminarlo sin entender su función podía provocar el fallo de funcionalidades esenciales o incluso impedir que el software de diagnosis arrancara.
Entonces, ¿por qué lo marca el antivirus? El problema BYOVD
Aquí aparece el concepto clave del caso: BYOVD (Bring Your Own Vulnerable Driver).
En los últimos años, numerosos grupos de ransomware y herramientas de post-explotación han adoptado una técnica concreta: en lugar de introducir un driver malicioso (que sería bloqueado), traen consigo un driver legítimo, firmado y vulnerable, lo cargan en el sistema y abusan de su fallo para obtener privilegios de kernel y desactivar las soluciones de seguridad.
Por eso muchos fabricantes de antivirus marcan este tipo de controladores aunque sean oficiales y estén correctamente firmados. Y por eso existen proyectos públicos —como LOLDrivers— que catalogan estos drivers conocidos para que defensores y atacantes… los conozcan exactamente igual.
La conclusión es importante y es justo la que se suele malinterpretar:
La detección no significa que el equipo esté comprometido. Significa que existe un componente que un atacante podría aprovechar si antes lograra ejecutar código en el sistema.
Es una diferencia fundamental entre «estás infectado» y «tienes una pieza que conviene vigilar».
El control que todo el mundo espera… y por qué aquí es un arma de doble filo
Llegados a este punto, un lector técnico pensará en la respuesta de manual: la Microsoft Vulnerable Driver Blocklist, que junto con la Integridad de Memoria (HVCI) bloquea por defecto la carga de drivers vulnerables conocidos. Es, hoy, el mecanismo estándar contra BYOVD.
El problema es que ese control, aplicado aquí, dejaría el equipo inoperativo: bloquearía precisamente el controlador que el dispositivo de diagnosis necesita para funcionar. Este es el verdadero dilema del caso, y es el que mejor resume la tensión de la ciberseguridad industrial: existe un control técnico capaz de cerrar el riesgo, pero su aplicación choca de frente con la disponibilidad del equipo.
Cuando la mitigación «correcta» rompe el negocio, la respuesta no es ni aplicarla a ciegas ni ignorar el riesgo. Es gestionarlo.
La decisión: no eliminar, gestionar
Tras el análisis, eliminar el controlador suponía un riesgo operativo mayor que mantenerlo. La decisión adoptada fue distinta y se apoyó en medidas compensatorias:
- Confirmar el origen legítimo del controlador y que pertenece al software base del equipo.
- Verificar que el sistema estaba actualizado (BIOS y controladores oficiales en versiones vigentes).
- Comprobar si existía una versión más reciente del paquete que sustituyera al controlador. Al tratarse de un equipo en configuración específica del fabricante, no hay descarga pública estándar: la actualización depende del propio proveedor.
- Restringir el uso del equipo exclusivamente a tareas técnicas de diagnosis, evitando navegación general y correo, que son las vías habituales por las que un atacante consigue esa primera ejecución de código que el BYOVD necesita.
- Revisar y limitar el acceso del equipo a los recursos internos de la red.
- Vigilar la carga del controlador (mediante registro de eventos de carga de drivers / EDR), de modo que cualquier intento de uso fuera de su función normal genere una alerta.
El driver, por sí solo, no compromete el equipo. Lo que estas medidas reducen es la probabilidad del paso previo —que un atacante llegue a ejecutar código— y la capacidad de detectar el abuso si se produjera.
Cuando el fabricante no responde
Trasladamos la situación al proveedor del equipo para confirmar si existía alguna actualización o recomendación oficial. A día de hoy, esa consulta sigue abierta: a pesar de varias reclamaciones por distintos canales, aún no hemos recibido respuesta.
Y esto, lejos de ser un punto débil, ilustra por qué un proceso de gestión de riesgos importa. La protección del equipo no puede quedar en suspenso a la espera de que un tercero conteste. El riesgo está identificado, las medidas compensatorias están aplicadas y el activo permanece operativo y bajo control mientras se insiste por los canales del proveedor. La gestión no se paraliza; se documenta y se sostiene en el tiempo.
Del incidente al SGSI
Aquí es donde muchas organizaciones dan el trabajo por terminado. Nosotros entendemos que es donde empieza.
Detectar una vulnerabilidad no es solo resolver una incidencia técnica: es evaluar el riesgo que representa para la organización y dejar constancia de la decisión. Por eso el caso pasó al proceso de gestión de riesgos del Sistema de Gestión de Seguridad de la Información (SGSI), alineado con la gestión de vulnerabilidades técnicas que contempla la norma ISO/IEC 27001 (control A.8.8). Allí se documentó:
- el activo afectado y su propietario;
- la vulnerabilidad identificada y su naturaleza (driver vulnerable / BYOVD);
- el impacto potencial y las condiciones necesarias para que se materialice;
- las medidas compensatorias aplicadas;
- las consultas realizadas al proveedor y su estado;
- y la decisión de tratamiento adoptada: aceptación del riesgo con controles compensatorios, con un propietario asignado y una fecha de revisión, no un cierre definitivo.
Así, el análisis deja de depender del conocimiento del técnico que intervino y pasa a formar parte del conocimiento documentado de la organización, revisable y trazable.
Reaccionar no es gestionar
Una alerta de seguridad no siempre implica una infección ni una actuación inmediata sobre el archivo detectado. Una respuesta impulsiva podría haber dejado inoperativo un equipo imprescindible para la actividad diaria.
La diferencia entre reaccionar y gestionar está en dedicar tiempo a entender qué se ha detectado, qué función cumple, qué pasaría al eliminarlo y qué medidas compensatorias caben cuando no existe una alternativa técnica viable, o cuando la alternativa «de manual» rompería el propio sistema que pretende proteger.
En Kaizen Development Solutions entendemos la seguridad como un proceso continuo de análisis, gestión del riesgo y mejora constante. Porque, muchas veces, la mejor decisión no es la más rápida, sino la que mejor equilibra protección, disponibilidad y las necesidades reales de la organización.
Si en tu organización conviven equipos críticos con alertas que no admiten una respuesta de manual, estaremos encantados de ayudarte a gestionarlas sin frenar la operativa.
