Guilgo Blog

Cuando Wazuh detecta vulnerabilidades en tus equipos Windows y WSUS tiene cientos de actualizaciones pendientes, la pregunta clave es: ¿qué parcho primero? Este post conecta el flujo Wazuh → WSUS para priorizar y desplegar parches críticos de forma controlada.

A raíz de Monitorización de Active Directory y Office365 con Wazuh y WSUS: cómo reparar la base de datos SUSDB, aquí va el siguiente paso: qué aprobar cuando Wazuh dispara alertas de CVEs.

Contexto: más CVEs, más necesidad de priorizar

Cada vez salen más vulnerabilidades al día —ya sea por investigadores, bug bounty o herramientas asistidas por IA— y WSUS acumula decenas de actualizaciones sin aprobar. Aprobar todo a la vez es arriesgado; dejar todo para “el ciclo mensual” tampoco sirve cuando hay un CVE crítico con explotación activa (como en Wazuh 4.9.1 y Mirai).

La idea: usar Wazuh para ver qué sistemas están afectados y WSUS para desplegar solo lo necesario, en el orden correcto.

Cómo Wazuh detecta vulnerabilidades

El módulo Vulnerability Detector de Wazuh escanea el inventario de software instalado y lo cruza con bases de datos de CVEs (NVD, OVAL, etc.). En equipos Windows, el agente envía información de paquetes instalados (incluidas actualizaciones de Windows) y el manager genera alertas cuando hay un CVE conocido para esa versión.

En el dashboard de Wazuh puedes ver:

• Qué hosts tienen vulnerabilidades
• Severidad (Crítico, Alto, Medio, Bajo)
• CVE ID y descripción
• Nombre del paquete/componente afectado

Si aún no tienes el Vulnerability Detector activo, en ossec.conf del manager:

<vulnerability-detector>
  <enabled>yes</enabled>
  <provider name="msu">
    <enabled>yes</enabled>
  </provider>
</vulnerability-detector>

Luego: wazuh-control restart

Limitaciones y falsos positivos: qué no valida el Vulnerability Detector

El Vulnerability Detector trabaja por inventario: cruza software instalado con bases de CVEs. No valida si el componente es realmente explotable en tu configuración (si el servicio está activo, si la función afectada está en uso, etc.). Eso puede generar alertas que no justifican parchear de urgencia:

• Supersedence: Una actualización puede estar reemplazada por otra más reciente. WSUS suele marcar “superseded”; aprobar la revisión antigua no soluciona el CVE si ya existe un KB más nuevo que la reemplaza. Revisa en WSUS que el KB que apruebas no esté superseded.
• Paquetes no realmente activos: El inventario dice “instalado”, pero el rol o la feature puede estar deshabilitada. Un CVE en un componente que no ejecutas sigue apareciendo; prioriza los que afectan a servicios que sí están en uso.
• Features deshabilitadas: Igual que arriba: si el CVE afecta a una función que no tienes habilitada, el riesgo real es menor. No dejes de parchear, pero no trates todo como crítico solo por el CVSS.

Wazuh usa feeds NVD/MSU en modo offline (sincroniza copias locales). Actualiza esos feeds con regularidad para que los CVEs recién publicados entren en el Vulnerability Detector; si no, las alertas llegarán con retraso.

Evitar parchear innecesariamente reduce reinicios, pruebas y riesgo operativo. Revisar supersedence y contexto del componente antes de aprobar en piloto ahorra trabajo y evita aprobar el parche equivocado.

Criterios de priorización

Regla práctica: servidores expuestos (Internet, DMZ) y DCs primero; equipos de usuario internos después.

Priorizar por exposición real, no solo por CVSS. Un CVE con CVSS 7 en un controlador de dominio o en un servidor expuesto a Internet suele ser más urgente que un CVSS 9 en una workstation interna que no ofrece servicios. La severidad del CVE importa, pero el contexto del activo (qué hace, quién puede alcanzarlo) debe subir o bajar la prioridad. En la práctica: misma severidad → primero los que están expuestos o son críticos para el dominio (DCs, servidores de identidad, perimetrales).

Flujo práctico: de Wazuh a WSUS

Paso 1 — Identificar el CVE y el KB de Microsoft

Cuando Wazuh alerta de un CVE en Windows, necesitas el Knowledge Base (KB) de Microsoft. Busca en:

• Microsoft Security Response Center
• NVD → en la ficha del CVE suele aparecer el enlace a la advisory de Microsoft

Ejemplo: CVE-2025-XXXX → KB5041234.

Paso 2 — Buscar la actualización en WSUS

En el servidor WSUS, con PowerShell:

# Conectar al servidor WSUS
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | Out-Null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("localhost", $false, 8530)

# Buscar por ID del Knowledge Base
$kbId = "5041234"
$updates = $wsus.GetUpdates() | Where-Object { $_.Title -match "KB$kbId" }

$updates | Select-Object Title, UpdateClassificationTitle, CreationDate, IsApproved | Format-Table -AutoSize

Paso 3 — Crear grupos de aprobación (piloto vs producción)

Antes de aprobar masivamente, crea un grupo piloto con pocos equipos:

# Crear grupo Piloto-Patches si no existe
$computerGroups = $wsus.GetComputerTargetGroups()
$pilotoGroup = $computerGroups | Where-Object { $_.Name -eq "Piloto-Patches" }
if (-not $pilotoGroup) {
    $pilotoGroup = $computerGroups.Add("Piloto-Patches")
}

Asigna 2–3 equipos de prueba a ese grupo desde la consola de WSUS (o por GPO).

Paso 4 — Aprobar solo para el grupo piloto primero

# Obtener la actualización por KB
$update = $wsus.GetUpdates() | Where-Object { $_.Title -match "KB5041234" } | Select-Object -First 1

if ($update) {
    # Aprobar para instalación en Piloto-Patches
    $update.Approve("Install", $pilotoGroup)
    Write-Host "Actualización aprobada para grupo Piloto-Patches"
} else {
    Write-Host "No se encontró la actualización. Verifica que WSUS haya sincronizado con Microsoft."
}

Paso 5 — Esperar y validar

• Revisa en Wazuh que los equipos del grupo piloto dejen de aparecer como vulnerables tras el parche.
• Comprueba el Event Viewer (Windows Update) en uno de los pilotos.
• Si todo va bien, aprueba para All Computers o para el grupo de producción.

# Una vez validado en piloto, aprobar para todos
$allComputers = $computerGroups | Where-Object { $_.Name -eq "All Computers" }
$update.Approve("Install", $allComputers)

Script resumido para aprobar por KB

Guarda algo así como Approve-WsusUpdateByKB.ps1:

param(
    [Parameter(Mandatory=$true)]
    [string]$KBId,
    [string]$TargetGroup = "Piloto-Patches",
    [switch]$WhatIf
)

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | Out-Null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("localhost", $false, 8530)

$update = $wsus.GetUpdates() | Where-Object { $_.Title -match "KB$KBId" } | Select-Object -First 1
$group = $wsus.GetComputerTargetGroups() | Where-Object { $_.Name -eq $TargetGroup }

if ($update -and $group) {
    if ($WhatIf) {
        Write-Host "[WhatIf] Se aprobaría KB$KBId para $TargetGroup (no se realizó ningún cambio)"
    } else {
        $update.Approve("Install", $group)
        Write-Host "KB$KBId aprobado para $TargetGroup"
    }
} else {
    Write-Host "Error: update o grupo no encontrado"
}

Uso:

.\Approve-WsusUpdateByKB.ps1 -KBId "5041234" -TargetGroup "Piloto-Patches"
# Dry-run (no aprueba, solo muestra qué haría):
.\Approve-WsusUpdateByKB.ps1 -KBId "5041234" -TargetGroup "Piloto-Patches" -WhatIf

Rollback y despliegue controlado

WSUS puede romper cosas (incompatibilidades, reinicios inesperados, drivers). Un despliegue controlado implica tener estrategia de rollback y límites claros:

• Aprobación para desinstalar (Uninstall): Si un parche causa problemas en piloto, en WSUS puedes aprobar la actualización como Uninstall para el grupo afectado. Importante: Uninstall solo aplica si el parche ya está instalado en los equipos; si aún no se ha desplegado, basta con Decline (rechazar) la actualización para ese grupo y no se instalará. Tener claro cuándo usar Uninstall vs Decline evita quedarte atrapado con un parche malo en producción.
• Deadline sin auto-reboot agresivo: Al aprobar, puedes fijar un deadline (fecha/hora límite de instalación). Si evitas deadlines demasiado cortos, reduces reinicios en horario laboral. Combínalo con ventanas de mantenimiento en GPO para que el reinicio ocurra cuando toque.
• Anillos de despliegue: Ya usas piloto → producción. En entornos grandes conviene un anillo más: por ejemplo Piloto (2–3 equipos) → Servidores no críticos (o un OU concreto) → Resto. Así limitas el impacto si un parche falla y tienes tiempo de desaprobar antes de que llegue a todo el parque.

No hace falta implementar todo el primer día; con piloto + posibilidad de desaprobar/Uninstall y deadlines razonables ya ganas mucho. Si algo sale mal en piloto, no promociones a producción y revisa supersedence o el KB correcto.

Mantenimiento y referencias

• Programa Invoke-WsusServerCleanup periódicamente (como en el post de reparar SUSDB) para evitar que WSUS se llene de revisiones obsoletas.
• Mantén productos y clasificaciones ajustados a lo que realmente usas.
• Si Wazuh dispara muchas alertas nuevas de golpe —por ejemplo, tras el anuncio de cientos de CVEs en bibliotecas open source—, prioriza siempre los que afecten a Windows y componentes de red en tus servidores.

Enlaces útiles

• Wazuh Vulnerability Detector
• Microsoft Security Update Guide
• WSUS PowerShell (Microsoft.UpdateServices)

Conclusión

Con Wazuh identificas qué sistemas están vulnerables y con WSUS controlas qué parches se despliegan y en qué orden. Priorizar por severidad y exposición real (DCs y servidores expuestos primero), revisar supersedence y falsos positivos del inventario, usar un grupo piloto y mapear CVE → KB evita desplegar todo a ciegas. Añadir rollback (desaprobar o Uninstall), deadlines razonables y anillos de despliegue reduce el impacto cuando un parche rompe algo — algo que en WSUS ocurre más de lo que gustaría.