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

Criterios de priorización

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

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"
)

[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) {
    $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"

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, usar un grupo piloto y mapear CVE → KB evita desplegar todo a ciegas y reduce el riesgo de reinicios inesperados o incompatibilidades.