Canal seguro de Netlogon: hardening tras ZeroLogon

Cada equipo unido al dominio y cada confianza mantienen un canal seguro con un controlador de dominio mediante el protocolo remoto Netlogon (MS-NRPC). Por él viajan la autenticación NTLM de paso (pass-through), los cambios de contraseña de las cuentas de equipo y la validación de las confianzas. ZeroLogon (CVE-2020-1472) demostró lo grave que puede ser un canal seguro débil: un fallo en el protocolo de enlace AES-CFB8 permitía a un atacante no autenticado en la red dejar vacía la contraseña de la cuenta de equipo de un DC y hacerse con el dominio en segundos.

El parche ya es antiguo, pero el hardening que lo rodea a menudo no está terminado. Los GPO de lista de permitidos creados durante el despliegue de 2020 siguen concediendo excepciones. El requisito posterior de sellado de CVE-2022-38023 nunca se comprobó, y algunos dispositivos NAS o hosts Samba antiguos registran rechazos a diario sin que nadie se entere. Esta guía va más allá de la comprobación de una línea de la línea base del DC. Muestra cómo medir qué sigue usando Netlogon débil, aplicar cada capa y demostrarlo.

Cuáles son las capas de hardening

El hardening de Netlogon llegó por fases. Cada fase tiene su propio control y sus propios eventos:

Qué significan los eventos de ZeroLogon:

• 5827: el DC rechazó una conexión Netlogon vulnerable de una cuenta de equipo.
• 5828: el DC rechazó una conexión Netlogon vulnerable de una cuenta de confianza.
• 5829: el DC permitió una conexión de equipo vulnerable. Solo aparece en la fase previa a la aplicación, así que hoy, en un DC parcheado, significa que algo va mal.
• 5830: el DC permitió una conexión de equipo vulnerable debido al GPO de lista de permitidos.
• 5831: el DC permitió una conexión de confianza vulnerable debido al GPO de lista de permitidos.

Los eventos 5838 y 5839 indican que una cuenta de equipo o de confianza usó firma RPC cuando se esperaba sellado. En un DC totalmente actualizado y pasada la fecha de aplicación, esos clientes se rechazan, no se les advierte.

Medir: recopilar los eventos de todos los DC

Extraiga un mes de eventos de Netlogon de cada DC de una sola pasada. Si reenvía los registros System a un SIEM, ejecute allí la consulta equivalente. El objetivo es saber qué dispositivos y confianzas siguen en el límite.

$ids = 5827,5828,5829,5830,5831,5838,5839
$since = (Get-Date).AddDays(-30)

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'System'; ProviderName = 'NETLOGON'; Id = $ids; StartTime = $since
    } -ErrorAction SilentlyContinue
} | Select-Object MachineName, Id, TimeCreated,
    @{ n = 'Detail'; e = { ($_.Message -split "`n" | Select-String 'Machine|Account|Domain|OS' ) -join ' | ' } } |
    Sort-Object Id, TimeCreated |
    Export-Csv C:\Reports\netlogon-events.csv -NoTypeInformation

Cada evento registra el nombre del equipo o de la confianza, su dominio y, cuando se conoce, la versión del sistema operativo. Los hallazgos típicos son dispositivos de almacenamiento, impresoras y escáneres que se autentican en el dominio, versiones antiguas de Samba y sistemas Linux embebidos unidos al dominio con herramientas obsoletas.

A continuación, averigüe si alguien llegó a rellenar la lista de permitidos. Es un descriptor de seguridad almacenado en un GPO, así que léalo de la directiva resultante en cada DC:

Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    $p = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
    Get-ItemProperty $p | Select-Object PSComputerName,
        FullSecureChannelProtection, RequireSeal, VulnerableChannelAllowList,
        RequireSignOrSeal, SealSecureChannel, SignSecureChannel, RequireStrongKey
}

VulnerableChannelAllowList es el valor del Registro que hay detrás del GPO. Si tiene contenido, descodifique el SDDL (ConvertFrom-SddlString) para ver qué cuentas o grupos están exentos.

Auditar: resolver cada dispositivo antes de endurecer

Recorra el CSV dispositivo por dispositivo:

1. Identifique al responsable de cada cuenta de equipo de los eventos 5827, 5829, 5830 y 5838. Use Get-ADComputer <name> -Properties operatingSystem, whenChanged, ManagedBy, Description.
2. Actualice o sustituya. El firmware del fabricante o una versión actual de Samba corrige casi todos estos casos. Samba exige schannel seguro de forma predeterminada desde hace años, pero las compilaciones antiguas de algunos dispositivos pueden fijar una versión anterior.
3. Revise las confianzas para los eventos 5828, 5831 y 5839. Son confianzas externas o de bosque cuyo otro extremo tiene DC sin parchear, a menudo de un socio o de un dominio adquirido. Los DC de ese dominio necesitan el parche. No existe una solución local segura.
4. Elimine lo que ya no existe. Una parte sorprendente de las cuentas de equipo rechazadas pertenece a dispositivos que ya no existen. Deshabilítelas y, después, elimínelas según su proceso de objetos obsoletos.

Mantenga el barrido en marcha después de esta primera pasada. Se unen dispositivos nuevos, los socios reconstruyen sus DC y los dispositivos se restauran desde imágenes antiguas. Un informe mensual de cualquier evento de Netlogon en el rango 5827-5839, enviado al equipo responsable de las uniones al dominio, detecta estos casos mucho antes de que un cambio de aplicación los convierta en una interrupción del servicio.

Aplicar

Vaciar la lista de conexiones vulnerables permitidas

Abra el GPO que la configura (normalmente la Default Domain Controllers Policy o un GPO de la época de ZeroLogon) y vaya a:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: Allow vulnerable Netlogon secure channel connections

Establézcala en Not Defined cuando se hayan corregido todos los dispositivos de la lista. Si un dispositivo crítico para el negocio realmente no puede corregirse todavía, deje un único grupo dedicado en el descriptor, documente el responsable y la fecha de fin, y genere una alerta con cada 5830. Nunca la conceda a un grupo amplio como Domain Computers.

Confirmar la aplicación del sellado

En las compilaciones actuales y compatibles de Windows Server, el calendario de Microsoft para CVE-2022-38023 ya ha hecho obligatorio el sellado: desde las actualizaciones de julio de 2023, RequireSeal ya no puede establecerse en 0 (deshabilitado) ni en 1 (compatibilidad), de modo que en un DC actualizado el valor ya no cambia el comportamiento. Establecerlo en 2 es inocuo y solo marca la diferencia en un DC que se haya quedado en un nivel de actualizaciones de entre noviembre de 2022 y junio de 2023. Aun así, configure el valor explícitamente, para que un DC restaurado desde una copia de seguridad antigua o un DC que rara vez se parchea aparezca en el informe de desviaciones:

$p = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
Set-ItemProperty -Path $p -Name RequireSeal -Value 2 -Type DWord
Set-ItemProperty -Path $p -Name FullSecureChannelProtection -Value 1 -Type DWord

Despliegue estos valores como elementos de Registro de Preferencias de directiva de grupo en un GPO exclusivo de los DC, no a mano, para que se vuelvan a aplicar en cada actualización.

Bloquear las opciones clásicas del canal seguro

Estas opciones de seguridad existen desde Windows 2000 y deben estar habilitadas en todos los miembros del dominio y en los DC. Las líneas base de seguridad de Microsoft ya configuran la mayoría:

• Domain member: Digitally encrypt or sign secure channel data (always) = Enabled
• Domain member: Digitally encrypt secure channel data (when possible) = Enabled
• Domain member: Digitally sign secure channel data (when possible) = Enabled
• Domain member: Require strong (Windows 2000 or later) session key = Enabled
• Domain member: Disable machine account password changes = Disabled
• Domain member: Maximum machine account password age = 30 days
• Domain controller: Refuse machine account password changes = Disabled

La rotación periódica de la contraseña de equipo limita el tiempo durante el que un secreto de equipo robado resulta útil. Detenga cualquier proceso de creación de imágenes o de VDI que deshabilite la rotación para «mantener estable la confianza». Corrija la imagen en su lugar.

Verificar

Primero, compruebe que el canal seguro sigue funcionando en una muestra de miembros, con al menos uno por familia de sistema operativo:

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:corp.example.com

A continuación, repita el barrido de eventos y confirme que no hay eventos 5829, 5830 ni 5831 y que los eventos 5827, 5828, 5838 y 5839 solo mencionan dispositivos que ya ha decidido retirar. Repita la consulta del Registro y confirme que VulnerableChannelAllowList no existe en ningún DC.

Por último, añada detecciones que vigilen regresiones y explotación:

• Cualquier 5829, 5830 o 5831 es una regresión de configuración. Abra un ticket.
• Una ráfaga de 5827 desde un único origen puede ser un escaneo en busca de Netlogon débil.
• El evento 4742 (cuenta de equipo modificada) sobre la propia cuenta de un controlador de dominio, cuando el sujeto es ANONYMOUS LOGON y se ha cambiado la contraseña, es el artefacto clásico de explotación de ZeroLogon. Nunca debería producirse de forma legítima. Genere una alerta de gravedad alta. Los ID de evento que conviene reenviar figuran en la referencia de ID de eventos de AD.

Qué se rompe

• Dispositivos no Windows con pilas Netlogon antiguas. Los NAS, las impresoras multifunción, los servidores de archivos Samba antiguos y algunos agentes de unión al dominio de Linux no consiguen autenticarse ni cambiar las contraseñas de equipo una vez rechazados. Los usuarios ven errores de «trust relationship failed» o de inicio de sesión NTLM en esos dispositivos.
• Confianzas con dominios sin parchear. Se rechaza una confianza de bosque o externa cuyos DC remotos no pueden sellar. La autenticación a través de esa confianza falla hasta que el socio aplique los parches.
• Imágenes de VDI y de laboratorio congeladas. Las imágenes que deshabilitaron los cambios de contraseña de equipo se desincronizan y pierden su canal seguro cuando se reanuda la rotación. Reconstrúyalas con la rotación habilitada o use el mecanismo de gestión de contraseñas de equipo admitido por su proveedor de VDI.
• DC restaurados. Un DC restaurado desde una copia de seguridad anterior a su línea base de actualizaciones vuelve sin la aplicación hasta que se parchee. Incluya estos valores en las comprobaciones de su plan de recuperación del bosque.

Lecturas relacionadas: la línea base del DC para la configuración que lo rodea, bloquear la coerción de autenticación para la otra clase de ataques a DC basados en RPC, y restringir NTLM para reducir cuánto depende aún de la autenticación de paso de Netlogon.