Zerologon CVE-2020-1472 Aplicación Active Directory: qué significa
Las brechas de Zerologon CVE-2020-1472 Aplicación Active Directory son la parte de la remediación de esta vulnerabilidad que sigue quedando pendiente, aunque la vulnerabilidad en sí ya no sea una novedad. Zerologon es un fallo crítico (CVSS 10.0) de elevación de privilegios en el protocolo Netlogon Remote Protocol (MS-NRPC), el mecanismo que usan las máquinas unidas al dominio para establecer un canal seguro con un controlador de dominio. Fue descubierto y divulgado de forma responsable por Tom Tervoort de Secura, quien publicó el whitepaper técnico en septiembre de 2020 (Secura). El propio aviso de Microsoft lo cataloga como una vulnerabilidad de elevación de privilegios de Netlogon (MSRC CVE-2020-1472).
La razón por la que sigue mereciendo la pena escribir sobre esto más de tres años después de su divulgación no es el exploit en sí, sino la fase de aplicación (enforcement). Microsoft entregó los parches de Zerologon en dos etapas, y es en la segunda etapa donde la mayoría de los entornos se quedan silenciosamente estancados: parcheados, pero nunca confirmados como aplicando realmente la protección. Esto importa porque «Zerologon» tiene suficiente reconocimiento de nombre como para que muchos equipos lo traten como un problema resuelto e histórico en lugar de algo que merece revisarse en una auditoría rutinaria — y sigue apareciendo junto a las configuraciones incorrectas de Active Directory más comunes que las auditorías encuentran cada año.
⚠️ Advertencia: «Parcheamos Zerologon en 2020» y «La aplicación de Zerologon está activa en todos los DC» son dos afirmaciones distintas. Las auditorías todavía encuentran con regularidad controladores de dominio donde la primera es cierta y la segunda nunca se verificó.
Cómo funciona Zerologon
La causa raíz es un error de implementación criptográfica en ComputeNetlogonCredential, la función que MS-NRPC usa para derivar una clave de sesión durante NetrServerAuthenticate3. Netlogon usa AES-CFB8 para este intercambio, pero la implementación de Microsoft fijaba el vector de inicialización (IV) en un valor fijo de 16 bytes en cero en lugar de uno aleatorio — una violación de cómo se supone que debe usarse AES-CFB8 (whitepaper de Secura, vía Pwnie Awards).
Ese fallo tiene una consecuencia explotable concreta: para aproximadamente 1 de cada 256 claves posibles, cifrar un texto plano completamente en cero con AES-CFB8 y un IV en cero produce un texto cifrado completamente en cero.
La secuencia del ataque
Un atacante no autenticado en la red puede:
- Suplantar una cuenta de equipo (incluida la propia cuenta del controlador de dominio) en el intercambio de Netlogon.
- Enviar un desafío de cliente compuesto por 8 bytes en cero.
- Repetir el intercambio — en promedio unos 256 intentos — hasta que el servidor acepte la credencial completamente en cero.
- Una vez autenticado, llamar a
NetrServerPasswordSet2para restablecer la contraseña de la cuenta de equipo de un objetivo, incluido el propio DC, a un valor conocido.
A partir de ahí, un atacante que ha restablecido la contraseña de la cuenta de equipo de un controlador de dominio puede autenticarse como ese DC y ejecutar DCSync para extraer todos los hashes de contraseñas del dominio — compromiso completo del dominio, sin autenticación, en minutos. Sin credenciales, sin phishing, sin malware en el endpoint — solo se necesita alcance de red hacia el servicio Netlogon de un controlador de dominio. Nuestro artículo complementario sobre abuso de ACL y DCSync explica cómo se ve ese abuso de replicación una vez que un atacante tiene los derechos para desencadenarlo.
Explotación confirmada en el mundo real
CISA añadió el CVE-2020-1472 a su catálogo de vulnerabilidades explotadas conocidas (Known Exploited Vulnerabilities) y emitió la Directiva de Emergencia 20-04, ordenando a todas las agencias federales de EE. UU. parchear o desconectar los controladores de dominio afectados antes de las 23:59 EDT del 21 de septiembre de 2020 (CISA ED 20-04). CISA confirmó después la explotación activa del fallo por parte de actores estatales (alerta de CISA, octubre de 2020), y desde entonces se ha observado en intrusiones de ransomware dirigidas a controladores de dominio sin parchear. La combinación de una puntuación CVSS máxima, la ausencia de requisito de autenticación y una prueba de concepto pública es exactamente la razón por la que esta clase de vulnerabilidad merece una revisión periódica en lugar de un parcheo puntual y olvido.
Por qué la aplicación es un problema distinto del parcheo
Microsoft entregó el parche en dos fases, y ese escalonamiento es precisamente la razón por la que las brechas de aplicación persisten años después de que todos crean que el asunto está cerrado.
Fase 1 — Actualización del 11 de agosto de 2020
Este parche cambió cómo gestionan los DC las conexiones Netlogon vulnerables e introdujo el valor de registro FullSecureChannelProtection bajo HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, pero la aplicación era opcional. Los DC entraban en una «fase de implementación inicial» donde los dispositivos no conformes se registraban en el log, sin bloquearse, a menos que un administrador estableciera explícitamente el valor de registro o desplegara la GPO de aplicación (Soporte de Microsoft: gestión de las conexiones de canal seguro de Netlogon).
Fase 2 — Actualización del 9 de febrero de 2021
Esta actualización convirtió el modo de aplicación en el comportamiento predeterminado para todos los controladores de dominio Windows, sin importar el valor de registro o la directiva de grupo (Tenable: Microsoft finaliza la aplicación por defecto de Zerologon).
La brecha de la lista de excepciones de GPO
La brecha que la mayoría de las auditorías encuentran hoy no es «Zerologon sin parchear» — son entornos donde dispositivos heredados o de terceros (NAS, servidores de impresión, clientes Netlogon antiguos no Windows) dejaron de funcionar bajo la aplicación en 2021, y un administrador los añadió a la lista de excepciones de la directiva de grupo «Controlador de dominio: permitir conexiones de canal seguro Netlogon vulnerables» para detener la interrupción. Esa lista de excepciones es exactamente la brecha de aplicación: sigue ahí, sin revisar, años después, permitiendo silenciosamente el mismo intercambio vulnerable que explota Zerologon — limitada a las cuentas que fueron exentadas. Un controlador de dominio puede estar completamente parcheado y aun así tener este agujero abierto por política, razón por la cual el nivel de parche por sí solo no es evidencia suficiente de aplicación.
Detección
Netlogon registra IDs de evento específicos para la actividad de canal seguro vulnerable en cada controlador de dominio. Supervise estos en todos los DC, no solo en uno:
| ID de evento | Significado | Qué indica |
|---|---|---|
| 5827 | Conexión vulnerable de una cuenta de equipo denegada | La aplicación está activa y bloquea a un cliente no conforme |
| 5828 | Conexión vulnerable de una cuenta de confianza denegada | La aplicación está activa y bloquea una confianza no conforme |
| 5829 | Conexión vulnerable permitida durante la fase de implementación inicial | El DC NO está aplicando la protección — este evento no debería existir en un DC totalmente parcheado y en modo de aplicación |
| 5830 | Conexión vulnerable de una cuenta de equipo permitida por la GPO «Permitir conexiones de canal seguro Netlogon vulnerables» | Hay una excepción explícita vigente — audite a quién/qué cubre |
| 5831 | Conexión vulnerable de una cuenta de confianza permitida por la misma excepción de GPO | Igual que el anterior, para una confianza de dominio |
(Soporte de Microsoft: gestión de las conexiones de canal seguro de Netlogon)
Extraer los eventos
En concreto, en cada controlador de dominio:
# Extraer eventos recientes de canal Netlogon vulnerable del log Sistema
Get-WinEvent -LogName System -FilterXPath "*[System[(EventID=5827 or EventID=5828 or EventID=5829 or EventID=5830 or EventID=5831)]]" -MaxEvents 200 |
Select-Object TimeCreated, Id, Message |
Format-Table -AutoSize
# Confirmar directamente el estado de aplicación en el registro (informativo en DC parcheados
# desde febrero de 2021, donde la aplicación es la opción predeterminada sin importar este valor)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name FullSecureChannelProtection -ErrorAction SilentlyContinue
ℹ️ Nota: En un DC parcheado con la actualización de febrero de 2021 o posterior, la aplicación está activada por defecto y FullSecureChannelProtection pasa a ser en gran medida informativo — lo que realmente importa en ese punto es si la lista de excepciones de GPO «Permitir conexiones de canal seguro Netlogon vulnerables» está vacía. Una lista de excepciones no vacía es la verdadera brecha de aplicación persistente.
Cualquier evento 5829, 5830 o 5831 merece investigarse — identifica exactamente qué dispositivo sigue dependiendo del intercambio vulnerable y por qué, y le da una lista concreta con la que trabajar en lugar de una suposición de política. Combine la supervisión de eventos de Netlogon con el conjunto más amplio de IDs de eventos de seguridad de Active Directory que ya deberían estar en su SIEM, y con una revisión más amplia de prioridades de fortalecimiento para que correcciones a nivel de protocolo como esta no se traten como proyectos puntuales que quedan fuera del alcance con el tiempo.
Remediación
💡 Solución rápida: si no puede producir, ahora mismo, una lista de todos los controladores de dominio confirmados en la actualización acumulativa de febrero de 2021 (o posterior) Y una GPO de excepción de Netlogon vacía (o plenamente justificada), trate la aplicación de Zerologon como no verificada, no como «resuelto en 2020».
- Confirme el nivel de parche en cada DC, no en una muestra. Verifique que cada controlador de dominio tenga como mínimo la actualización del 11 de agosto de 2020, e idealmente la actualización acumulativa del 9 de febrero de 2021 o posterior, que activa la aplicación por defecto. Los DC pasados por alto (incluidos los DC de solo lectura y los DC en dominios/bosques menos visibles) son la brecha más común.
- Audite la GPO «Controlador de dominio: permitir conexiones de canal seguro Netlogon vulnerables». Revise cada entrada de la lista de excepciones. Para cada dispositivo exento, confirme que aún existe, que todavía necesita la excepción, y que no hay una actualización de firmware/software del proveedor disponible que añada soporte RPC seguro adecuado. Elimine las entradas obsoletas.
- Supervise continuamente los eventos 5829/5830/5831, no solo durante una ventana de implementación puntual. Cualquier nueva aparición significa que un dispositivo depende hoy de la ruta vulnerable.
- Establezca (o verifique)
FullSecureChannelProtection = 1en cualquier DC que aún no haya recibido la actualización de febrero de 2021 o posterior, como control provisional mientras se completa el parcheo. - Vuelva a verificar tras cambios de infraestructura. Nuevos controladores de dominio, promociones de DC desde plantillas/imágenes, y cambios de confianza de bosque/dominio pueden reintroducir un estado sin aplicar o sin parchear — incorpore esto a la revisión estándar de GPO y de builds de DC, no solo al despliegue inicial de 2020/2021.
- Trate la exposición a DCSync como el riesgo posterior. El impacto real de Zerologon es que le da a un atacante la capacidad de restablecer la contraseña de la propia cuenta de un DC y extraer los hashes de contraseñas del dominio. Revisar quién y qué ya tiene derechos de replicación legítimos compatibles con DCSync cierra la segunda mitad de esta ruta de ataque — vea nuestra guía sobre abuso de ACL y DCSync.
Cómo lo detecta EtcSec
El control ZEROLOGON_PATCH_ENFORCEMENT de EtcSec señala los controladores de dominio donde no se puede confirmar la aplicación de Zerologon — ya sea por un parche faltante, un valor FullSecureChannelProtection deshabilitado en un DC anterior a febrero de 2021, o una GPO de excepción de Netlogon activa — para que no se dé por «resuelto en 2020» de forma silenciosa. Se combina con DCSYNC_CAPABLE, que señala cuentas y objetos de equipo con derechos de replicación que un compromiso tipo Zerologon permitiría a un atacante explotar para una extracción completa de credenciales. Juntos, ambos controles cubren toda la ruta de ataque: el punto de apoyo inicial no autenticado y los derechos de replicación privilegiados que lo convierten en una brecha de todo el dominio.
ℹ️ Nota: EtcSec verifica automáticamente esta vulnerabilidad en cada auditoría de AD, en cada controlador de dominio — no en una muestra. Ejecute una auditoría gratuita para verificar que la aplicación está realmente activa en su entorno, y no simplemente asumida.
Explore las páginas de identidad que apoyan este tema
