CVE-2020-1472 Zerologon: Active Directory en 3 Segundos (2020)
CVE-2020-1472 (Zerologon) permitía a cualquier atacante con acceso de red a un Domain Controller tomar control completo del dominio en menos de 3 segundos. Un fallo criptográfico en AES-CFB8 con IV de ceros convirtió la autenticación Netlogon en un trámite trivial. CVSS 10.0, explotada por APTs iraníes, chinos y grupos de ransomware.
Una vulnerabilidad de una línea de código
En septiembre de 2020, Tom Tervoort, investigador de la empresa holandesa Secura, publicó un whitepaper que sacudió los cimientos de la seguridad de Active Directory. En él describía cómo un único fallo criptográfico en el protocolo de autenticación Netlogon permitía a cualquier persona con acceso de red a un Domain Controller tomar control completo del dominio en menos de 3 segundos y con menos de 256 intentos.
La vulnerabilidad, bautizada como Zerologon (CVE-2020-1472), recibió la puntuación CVSS máxima de 10.0. No requería autenticación previa, ni credenciales válidas, ni interacción del usuario. Solo acceso de red al puerto 445 de un Domain Controller. En un entorno corporativo típico, cualquier empleado con un portátil conectado a la red local cumplía ese requisito. En organizaciones con VPN comprometidas o servicios expuestos a Internet, el atacante ni siquiera necesitaba presencia física.
Microsoft parcheó la vulnerabilidad en su actualización de agosto de 2020, pero la complejidad del fix y la necesidad de mantener compatibilidad con sistemas legacy llevó a un despliegue en dos fases que se extendió hasta febrero de 2021. Mientras tanto, grupos de amenazas iraníes, chinos y operadores de ransomware ya habían incorporado Zerologon a su arsenal ofensivo.
El protocolo Netlogon y MS-NRPC
Para qué existe Netlogon
Netlogon es un servicio fundamental de Windows que gestiona la relación de confianza entre máquinas y Domain Controllers en un entorno Active Directory. Cada vez que un ordenador se une a un dominio, establece una relación de confianza con el DC que se mantiene mediante un secreto compartido (la contraseña de la cuenta de máquina).
El Netlogon Remote Protocol (MS-NRPC) es la interfaz RPC que implementa esta comunicación. Sus funciones incluyen:
- Autenticación de máquinas: Verificar que un ordenador del dominio es quien dice ser.
- Cambio de contraseñas de máquina: Rotar periódicamente el secreto compartido.
- Localización de Domain Controllers: Descubrir DCs disponibles para autenticación.
- Replicación de datos: Sincronizar información entre DCs (parcialmente).
El flujo de autenticación de MS-NRPC es un handshake challenge-response:
Cliente (máquina del dominio) Domain Controller
│ │
│──── NetrServerReqChallenge ────────────→│
│ (client_challenge: 8 bytes random) │
│ │
│←─── NetrServerReqChallenge ─────────────│
│ (server_challenge: 8 bytes random) │
│ │
│ [Ambos calculan session_key usando │
│ client_challenge + server_challenge │
│ + shared_secret (machine password)] │
│ │
│──── NetrServerAuthenticate3 ───────────→│
│ (client_credential: cifrado) │
│ │
│←─── NetrServerAuthenticate3 ────────────│
│ (server_credential: cifrado) │
La función ComputeNetlogonCredential toma el challenge de 8 bytes como entrada, lo cifra usando la session key derivada del secreto compartido, y produce un credential de 8 bytes. El servidor verifica que el credential del cliente coincida con lo esperado. Si coincide, la autenticación es exitosa.
El cifrado AES-CFB8
Microsoft actualizó MS-NRPC para soportar AES (además del antiguo DES/3DES) como algoritmo criptográfico para ComputeNetlogonCredential. El modo de operación elegido fue AES-CFB8 (Cipher Feedback con bloques de 8 bits).
En AES-CFB8, el cifrado funciona byte a byte:
Para cifrar el byte plaintext[i]:
1. Cifrar el registro de estado (16 bytes) con AES-ECB
2. Tomar el primer byte del resultado
3. XOR ese byte con plaintext[i] → ciphertext[i]
4. Desplazar el registro de estado 1 byte a la izquierda
5. Insertar ciphertext[i] en la última posición del registro
El registro de estado se inicializa con un IV (initialization vector) de 16 bytes. Para que AES-CFB8 sea seguro, este IV debe ser aleatorio y único para cada operación de cifrado con la misma clave.
El fallo: IV de ceros
La línea de código que rompió Active Directory
En la implementación de Microsoft de ComputeNetlogonCredential, el IV se establece como 16 bytes a cero. Siempre. Para todas las operaciones. Con cualquier clave.
IV = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Esta decisión de implementación viola el requisito fundamental de AES-CFB8 y convierte todo el esquema criptográfico en determinístico, eliminando la propiedad de indistinguishability que hace seguro al cifrado.
La matemática del exploit
Tervoort observó que cuando un atacante controla el plaintext (el client challenge) y el IV es siempre cero, puede elegir un plaintext específico que produzca un ciphertext predecible con alta probabilidad.
Si el atacante envía un client challenge de 8 bytes a cero:
client_challenge = 00 00 00 00 00 00 00 00
El proceso de cifrado AES-CFB8 comienza así:
- El registro de estado es el IV:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Se cifra con AES-ECB usando la session key, produciendo 16 bytes de salida.
- Se toma el primer byte del resultado: llamémoslo
K[0]. - Se calcula:
ciphertext[0] = K[0] XOR plaintext[0] = K[0] XOR 0x00 = K[0].
Si K[0] resulta ser 0x00 (probabilidad 1/256), entonces ciphertext[0] = 0x00. Este cero se retroalimenta al registro de estado, que vuelve a ser todo ceros (desplazado un byte, con un cero añadido al final, que ya era todo ceros). El proceso se repite y todo el ciphertext de 8 bytes será ceros.
La probabilidad de que K[0] = 0x00 es exactamente 1/256, porque el output de AES-ECB se comporta como una permutación pseudoaleatoria. Esto significa que, en promedio, 1 de cada 256 session keys producirá un credential de todo ceros cuando el client challenge es todo ceros.
El ataque paso a paso
PASO 1: El atacante envía NetrServerReqChallenge
client_challenge = 00 00 00 00 00 00 00 00
(El servidor responde con un server_challenge aleatorio)
PASO 2: El atacante envía NetrServerAuthenticate3
client_credential = 00 00 00 00 00 00 00 00
negotiate_flags = sin "secure RPC" flag
(Si falla, volver al PASO 1 con nuevo intento)
PASO 3: Repetir hasta éxito
Estadísticamente: ~256 intentos
Tiempo: < 3 segundos
No hay lockout ni rate limiting en Netlogon
PASO 4: Tras autenticación exitosa, llamar
NetrServerPasswordSet2 para establecer
la contraseña de la cuenta de máquina del DC
a un string vacío.
PASO 5: Con la contraseña vacía conocida,
usar secretsdump.py (Impacket) para
ejecutar DCSync y extraer todos los
hashes NTLM del dominio.
PASO 6: Golden Ticket o Pass-the-Hash
→ Control total del dominio
Lo más notable es que Netlogon no implementa ningún mecanismo de bloqueo (account lockout) ni limitación de intentos. El atacante puede enviar 256 intentos en ráfaga sin que el servidor registre nada anormal. Y como la autenticación Netlogon ocurre entre máquinas (no entre usuarios), no hay política de contraseñas ni MFA que aplique.
El impacto: dominio comprometido en segundos
Qué significa "tomar un dominio"
Cuando se dice que Zerologon permite "tomar el dominio", conviene ser específico sobre qué implica eso:
Acceso a todos los hashes NTLM. Mediante DCSync, el atacante obtiene el hash NTLM de cada cuenta del dominio: usuarios regulares, administradores, cuentas de servicio, y la cuenta krbtgt.
Golden Ticket. Con el hash de krbtgt, el atacante puede crear tickets Kerberos arbitrarios que le otorgan acceso como cualquier usuario, incluyendo Domain Admin. Estos tickets son válidos durante el tiempo que el atacante configure (potencialmente años) y sobreviven a cambios de contraseña de usuarios individuales.
Persistencia invisible. Un atacante con Golden Ticket no genera eventos de autenticación normales. Puede crear cuentas de backdoor, modificar Group Policies para establecer persistencia, o simplemente esperar y observar el tráfico de red.
Acceso a todos los recursos del dominio. Servidores de archivos, bases de datos, aplicaciones internas, buzones de correo, sistemas de backup. Todo lo que esté integrado con Active Directory queda comprometido.
La escala del problema
En el momento de la divulgación (septiembre 2020), prácticamente todos los Domain Controllers de Windows Server eran vulnerables: Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019 y 2022. Cualquier red corporativa con Active Directory estaba en riesgo.
La herramienta Zerologon de Impacket (secretsdump.py con la opción -just-dc) hacía que la explotación fuera accesible para atacantes con conocimientos técnicos moderados. No se necesitaba desarrollar un exploit propio: la implementación de referencia era pública y funcional.
Explotación en el mundo real
MERCURY (MuddyWater): los primeros en actuar
El 6 de octubre de 2020, el Microsoft Threat Intelligence Center (MSTIC) informó que MERCURY (también conocido como MuddyWater, Static Kitten y Seedworm) había estado explotando Zerologon activamente durante al menos dos semanas.
MERCURY es un grupo APT vinculado al Ministerio de Inteligencia y Seguridad de Irán (MOIS). Su historial incluye campañas de espionaje contra organizaciones gubernamentales en Oriente Medio, incluyendo entidades que trabajan con refugiados. La incorporación de Zerologon a su arsenal les permitía comprometer dominios Active Directory completos después de obtener un punto de apoyo inicial en la red, acelerando drásticamente la fase de escalado de privilegios.
APTs chinos
Grupos de amenazas vinculados a China también incorporaron Zerologon. TA505, un grupo asociado históricamente con operaciones de cibercrimen y espionaje, fue detectado usando el exploit como paso intermedio en cadenas de ataque más complejas contra objetivos en Norteamérica y Europa.
Ransomware: aceleración del time-to-ransom
Para los operadores de ransomware, Zerologon fue un multiplicador de fuerza. Antes de Zerologon, comprometer un dominio Active Directory desde un acceso inicial (phishing, VPN comprometida) podía tomar días o semanas de movimiento lateral cuidadoso. Con Zerologon, el salto de "acceso a la red" a "Domain Admin" se reducía a segundos.
Grupos documentados que usaron Zerologon incluyen:
- Ryuk/Conti: Lo integraron en su cadena de ataque estándar como paso de escalado de privilegios.
- Cuba Ransomware: Usado como técnica de movimiento rápido hacia Domain Controllers.
- AvosLocker: Documentado por el FBI en un aviso conjunto (AA22-075A) como parte de su toolkit.
- PYSA/Mespinoza: Detectado usando Zerologon en ataques contra el sector educativo.
El patrón era consistente: acceso inicial (phishing, VPN vulnerable, RDP expuesto) → reconocimiento rápido → Zerologon contra el DC → DCSync → despliegue masivo de ransomware. El tiempo total desde el acceso inicial hasta el cifrado de sistemas podía reducirse a horas.
El parche en dos fases
Fase 1: agosto 2020 (detección)
Microsoft incluyó el parche para CVE-2020-1472 en la actualización acumulativa de agosto de 2020. Sin embargo, la corrección no bloqueaba inmediatamente todas las conexiones Netlogon inseguras. En su lugar, implementaba:
- Secure RPC enforcement para cuentas de Windows. Las cuentas de máquina de Windows debían usar Secure RPC (Netlogon con protección de integridad y confidencialidad).
- Registro de eventos para conexiones inseguras. El Event ID 5829 se registraba cuando un dispositivo no Windows se conectaba sin Secure RPC.
- Group Policy para excepciones. Los administradores podían configurar una lista de dispositivos permitidos para usar conexiones inseguras.
La razón de esta implementación gradual era la compatibilidad. Dispositivos Linux (incluidos NAS de Synology, QNAP y similares), impresoras de red y otros equipos que usaban Samba u otras implementaciones de Netlogon no soportaban Secure RPC. Bloquearlos inmediatamente habría causado interrupciones operativas masivas.
Fase 2: febrero 2021 (enforcement)
A partir del 9 de febrero de 2021, Microsoft activó el modo de enforcement: todas las conexiones Netlogon debían usar Secure RPC, sin excepciones. Los dispositivos que no cumplían este requisito quedaban incapaces de unirse al dominio o autenticarse.
Para entonces, los fabricantes de dispositivos de almacenamiento (Synology, QNAP), distribuciones Linux (actualización de Samba) y otros vendors habían tenido seis meses para actualizar sus implementaciones.
El problema de la remediación post-compromiso
Parchear el Domain Controller detenía la explotación futura, pero no remediaba un compromiso ya ocurrido. Las organizaciones comprometidas necesitaban:
- Restablecer la contraseña de la cuenta de máquina del DC. El atacante la había vaciado, y este cambio persistía incluso después de parchear.
- Restablecer la contraseña de krbtgt dos veces. Kerberos mantiene la clave actual y la anterior. Para invalidar todos los Golden Tickets potenciales, había que rotar krbtgt dos veces con al menos 12 horas de separación.
- Auditar todas las cuentas del dominio. Buscar cuentas nuevas creadas por el atacante, cambios en Group Policies, y otros mecanismos de persistencia.
- Verificar la integridad de los backups. Si el atacante tuvo acceso al dominio durante un período prolongado, los backups también podían estar comprometidos.
En casos de compromiso prolongado o incierto, la recomendación era reconstruir el dominio desde cero, un proceso que puede tomar semanas o meses en organizaciones grandes.
El análisis criptográfico en profundidad
Por qué AES-CFB8 fue una mala elección
El modo CFB8 no es inherentemente inseguro. Con un IV aleatorio, AES-CFB8 proporciona las propiedades de seguridad esperadas. El problema fue específicamente la decisión de usar un IV estático de ceros.
Sin embargo, incluso con un IV aleatorio, CFB8 habría sido una elección subóptima para este caso de uso. Las razones son varias:
Rendimiento. CFB8 necesita una operación AES-ECB completa (16 bytes) por cada byte de plaintext. Para cifrar 8 bytes, necesita 8 invocaciones de AES. Un modo como AES-CBC o AES-GCM habría sido más eficiente.
Fragilidad. CFB8 es más sensible a errores de implementación que otros modos. Un error en el manejo del IV (como establecerlo a ceros) tiene consecuencias catastróficas, mientras que en AES-GCM el mismo error produciría una vulnerabilidad menos directamente explotable.
Autenticación. CFB8 no proporciona autenticación (AEAD). AES-GCM o AES-CCM habrían proporcionado tanto confidencialidad como integridad, detectando modificaciones del ciphertext.
La lección criptográfica
Zerologon es un caso de libro de texto sobre por qué la criptografía aplicada es difícil. El algoritmo (AES) era seguro. El modo de operación (CFB8) era estándar. Pero un detalle de implementación (IV estático) anuló completamente todas las garantías de seguridad.
La comunidad criptográfica señaló que este tipo de errores se previenen con:
- APIs criptográficas de alto nivel que no permiten al desarrollador configurar el IV manualmente.
- Protocolos modernos como TLS 1.3 que encapsulan toda la complejidad criptográfica.
- Revisiones de código específicas para implementaciones criptográficas, realizadas por expertos en criptografía aplicada, no solo por desarrolladores generalistas.
Contexto histórico: vulnerabilidades de Active Directory
Zerologon no fue la primera ni la última vulnerabilidad devastadora en Active Directory, pero ocupó un lugar especial por la simplicidad del exploit y la gravedad del impacto:
MS14-068 (noviembre 2014): Vulnerabilidad en Kerberos PAC validation que permitía a un usuario regular del dominio forjar un ticket Kerberos con privilegios de Domain Admin. Similar a Zerologon en impacto, pero requería credenciales válidas de un usuario del dominio.
Zerologon (agosto 2020): No requería ninguna credencial. Solo acceso de red.
PrintNightmare (junio 2021): Permitía ejecución de código como SYSTEM en cualquier máquina Windows con Print Spooler habilitado, incluyendo Domain Controllers. Complementaria a Zerologon: si Zerologon era la escalada al dominio, PrintNightmare era la escalada a SYSTEM en máquinas individuales.
noPac / SamAccountName (diciembre 2021): CVE-2021-42278 y CVE-2021-42287 permitían a un usuario del dominio con privilegios mínimos impersonar un Domain Controller y obtener Domain Admin. Otra variante del mismo tema: autenticación Kerberos/Netlogon insuficiente.
El patrón común de todas estas vulnerabilidades es que Active Directory fue diseñado en los años 90 con un modelo de confianza donde la red interna se consideraba segura. Dos décadas de evolución del panorama de amenazas han demostrado que esa asunción es insostenible.
Detección y hunting
Indicadores de explotación
La detección de Zerologon en logs requiere monitorizar eventos específicos:
Event ID 4742 (Security log): Cambio de cuenta de máquina. Si la contraseña de la cuenta de máquina del DC cambia fuera de la rotación programada, es un indicador de compromiso.
Event ID 5805 (System log): Error de autenticación de la cuenta de máquina. Después de que el atacante vacía la contraseña, el DC legítimo no puede autenticarse contra otros DCs, generando estos eventos.
Event ID 5829 (System log): Conexión Netlogon vulnerable permitida (después del parche de agosto 2020). Indica que un dispositivo se conectó sin Secure RPC.
Tráfico de red: Ráfagas de intentos de autenticación Netlogon (puerto 445) contra un DC desde una única fuente, seguidas inmediatamente de una llamada NetrServerPasswordSet2, son un patrón altamente indicativo de explotación de Zerologon.
Reglas de detección
# Sigma rule (simplificada) para detección de Zerologon
title: Zerologon Exploitation Attempt
status: production
logsource:
product: windows
service: system
detection:
selection:
EventID: 5805
LogonType: 3
condition: selection
timeframe: 5m
count: > 10
level: critical
Lecciones de Zerologon
Zerologon expuso verdades incómodas sobre la seguridad de Active Directory:
La red interna no es segura. Cualquier modelo de seguridad que asuma que los atacantes no tienen acceso a la red local es fundamentalmente frágil. VPNs comprometidas, phishing, USB malicioso, empleados descontentos: los vectores de acceso a la red interna son múltiples y diversos.
La criptografía mal implementada es peor que ninguna. Usar AES no proporciona seguridad por sí mismo. La implementación debe seguir las mejores prácticas del modo de operación elegido. Un IV de ceros en CFB8 convierte AES en una puerta abierta.
Active Directory es un single point of failure. El compromiso de un Domain Controller equivale al compromiso de toda la organización. No hay compartimentación, no hay blast radius limitado. Esta realidad hace que cada vulnerabilidad en AD sea automáticamente crítica.
Los parches complejos necesitan planes de despliegue. El enfoque en dos fases de Microsoft fue necesario por la compatibilidad, pero dejó una ventana de seis meses donde la explotación seguía siendo posible incluso en sistemas parcheados si los administradores no configuraban correctamente el enforcement. La complejidad del parche puede ser tan peligrosa como la vulnerabilidad misma.
Tom Tervoort demostró con Zerologon que a veces las vulnerabilidades más devastadoras no requieren técnicas sofisticadas. Basta con una línea de código que establezca un IV a ceros para que la autenticación de millones de dominios Active Directory se reduzca a un juego de probabilidades que el atacante siempre gana.
Preguntas frecuentes
Artículos relacionados
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.