VMDR en la Práctica: De la "Ceguera" en el Dashboard a la Remediación de Kernel con Qualys

Objetivo del Blue Team.

Como parte de mi formación en ciberseguridad defensiva, decidí auditar mi propia estación de trabajo como si fuera un activo crítico empresarial. Para ello, implementé el Qualys Cloud Agent, una de las herramientas líderes en la industria para la gestión de vulnerabilidades.

El objetivo era simple: obtener visibilidad total en tiempo real. Sin embargo lo que comenzó como una instalación rutinaria se convirtió en una lección práctica sobre por qué no podemos confiar ciegamente en las actualizaciones automáticas.

Fase 1: El Problema de la Visibilidad (Data vs Dashboard).

Tras instalar el agente y confirmar que el servicio corría correctamente, me dirigí al Dashboard de Qualys esperando ver un reporte de un estado. Me encontre con esto:

¿Mi equipo era perfecto y tenía cero vulnerabilidades? Claro que no. El problema no era la falta de datos, sino la visualización. Los widgets por defecto de Qualys (TruRisk) filtran vulnerabilidades extremas (Riesgo > 700) o muy antiguas (> 30 días).

Para ver la realidad operativa, tuve que crear mis propios indicadores (Widgets) utilizando queries personalizados. Al configurar un filtro para vulnerabilities.severity <= 3 y otro para vulnerabilities.severity: 4, la "ceguera" desapareció y el dashboard se iluminó.

Fase 2: Detección y Contradicción.

Entre los hallazgos, destacó una vulnerabilidad de severidad 4 (Alta): Microsoft Windows Security Update for December 2025 (Asociada a múltiples CVEs).

Aquí surgió una contradicción. Al revisar Windows Update en mi laptop, el sistema aseguraba estar actualizado. Incluso el historial de actualizaciones mostraba parches de seguridad iniciados en diciembre.

• Qualys: "Falta parche crítico".
• Windows: "Todo está al día".

Decidí entonces investigar, ir al "bajo nivel" para ver quién mentía.

Fase 3: Análisis Forense con PowerShell.

La vulnerabilidad indicaba que el archivo afectado era ntoskrnl.exe (el Kernel de Windows). Según la base de conocimientos de Qualys, para estar protegido necesitaba una versión especifíca del archivo.

Utilicé PowerShell para interrogar directamente el archivo en el disco, evitando la interfaz gráfica de windows Update:

(Get-Item "C:\Windows\System32\ntoskrnl.exe").VersionInfo.FileVersion

Me devolvió la siguiente versión: 10.0.22621.6166. La versión requerida es 10.0.22621.6345.

Evidentemente al revisar la existencia del KB con el comando en powershell:

Get-HotFix -Id KB5071417

Como resultado se obtenía un error dónde quedaba demostrado la ausencia de la actualización KB5071417.

El diagnóstico estaba claro: Aunque Windows intentó actualizarse en diciembre, el parche no se aplicó correctamente al núcleo del sistema, dejándolo vulnerable a más de 30 exploits distintos.

Fase 4: Remediación Manual e Integridad.

Dado que Windows Update no me ofrecía el parche nuevamente, tuve que realizar una intervención:

• Busqué el KB específico (KB5071417) en el Catálogo de Microsoft Update.
• Descargué el instalador independiente (.msu)

El Reto del Hashing.

Antes de ejecutar cualquier archivo descargado manualmente, es obligatorio verificar su integridad y autenticidad. Comparé el Hash SHA256 proporcionado por Microsoft con el de mi archivo descargado:

Get-FileHash .\windows11.0-kb5071417-x64.msu -Algorithm SHA256

Resultó que: Microsoft proporcionaba el Hash en formato Base64 y PowerShell en Hexadecimal. A simple vista eran diferentes, pero tras realizar la conversión, confirmé que eran matemáticamente idénticos. El archivo era seguro.

Fase 5: Verificación y Cierre.

Tras instalar el parche manualmente y realizar el reinicio obligatorio, volví a PowerShell. Esta vez, la versión del kernel coincidía con la requerida (.6345).

Así como el archivo KB también existía.

Conclusión.

Este ejercicio refuerza tres pilares fundamentales para cualquier profesional de seguridad:

1. Desconfianza Cero: Las herramientas automáticas (como Windows Update) pueden fallar silenciosamente.
2. Validación Técnica. Saber usar la línea de comandos (CLI) para "interrogar" al sistema operativo es más valioso que depender de interfaces gráficas.
3. Integridad. Verificar los hashes de los parches manuales no es opcional; Es la única garantía de que no estamos instalando software corrupto.

El ciclo VMDR no termina al instalar un parche, termina cuando verificamos técnicamente que la brecha se ha cerrado.