ResetNightmare CVE-2026-27912, Kerberos Cambio de Contraseña, Active Directory: escribir tu propio userPrincipalName basta para reiniciar un Domain Admin

Qué es ResetNightmare CVE-2026-27912 Kerberos Cambio de Contraseña Active Directory

ResetNightmare CVE-2026-27912 Kerberos Cambio de Contraseña Active Directory: esa cadena de palabras nombra un único fallo, y es el camino más corto en un dominio entre el acceso de escritura sobre una cuenta desechable y una contraseña de Domain Admin reiniciada. El atacante nunca conoce la contraseña anterior de la víctima, nunca retransmite una credencial y nunca rompe un hash. Simplemente establece una nueva contraseña en una cuenta sobre la que nunca se le delegó ningún derecho.

El fallo fue descubierto por el investigador de Semperis Shai Laron y publicado en la investigación Identity Crisis de la empresa, junto a una segunda vulnerabilidad independiente que la misma investigación llama KerberLoss (CVE-2026-25177). La descripción del National Vulnerability Database es escueta: «Improper authorization in Windows Kerberos allows an authorized attacker to elevate privileges over an adjacent network.»

Esa frase oculta la parte interesante. La «autorización incorrecta» no es una comprobación de ACL ausente sobre un objeto. Es una verificación de identidad que existe, que funciona correctamente, y que simplemente nunca se alcanza, porque el protocolo abusado toma un atajo que salta exactamente el paso donde vive esa verificación.

Cómo funciona, y por qué importa la ausencia de TGS-REQ

Kerberos no tiene una única forma de nombrar a un principal, y Active Directory usa habitualmente dos. NT-PRINCIPAL nombra una cuenta por su sAMAccountName. NT-ENTERPRISE la nombra por su userPrincipalName, el UPN. Un cliente puede incluir cualquiera de las dos formas en una AS-REQ, y el KDC la resuelve a una cuenta y emite un ticket.

Los ataques que abusan de esa ambigüedad no son nuevos. En noviembre de 2021, la cadena noPac, CVE-2021-42278 y CVE-2021-42287, permitía a un atacante renombrar una cuenta que controlaba para que un ticket emitido para una identidad pudiera canjearse como otra. La corrección de Microsoft para CVE-2021-42287, KB5008380, publicada el 9 de noviembre de 2021, añadió «nueva información sobre el solicitante original en los PAC de los Ticket-Granting Tickets (TGT) de Kerberos», el buffer PAC Requestor. El KDC lo usa, en palabras de Microsoft, al «generar un ticket de servicio Kerberos», para verificar que «la cuenta que solicitó el TGT es la misma cuenta referenciada en el ticket de servicio».

Léalo con atención, porque ResetNightmare vive exactamente en el hueco que eso deja. El SID PAC Requestor se valida cuando se genera un ticket de servicio, durante el intercambio TGS-REQ.

El protocolo Kerberos de cambio de contraseña no tiene TGS-REQ.

Definido en la RFC 3244 y servido en el puerto 464, kpasswd, el flujo de cambio de contraseña es deliberadamente corto. Un cliente obtiene un TGT y luego va directamente a una AP-REQ contra el servicio de cambio de contraseña. No hay ningún intercambio de tipo ticket-granting intermedio, porque el cliente no está solicitando acceso a un servicio en el sentido habitual. Está presentando prueba de su propia identidad para cambiar una contraseña. Semperis describe el flujo como yendo directamente de la solicitud de TGT a una AP-REQ, «sin un TGS-REQ de por medio».

Sáltese el TGS-REQ y se salta con él la validación del PAC Requestor. Nada más en ese camino vuelve a derivar el SID del solicitante a partir del ticket. Así, un TGT emitido porque un nombre NT-ENTERPRISE se resolvía, en ese momento, al objeto del atacante, es aceptado por kpasswd como autoridad sobre la cuenta a la que ese nombre se resuelve ahora.

El resultado se agrava de la forma en que siempre se agravan los enlaces de identidad rotos. El atacante establece una contraseña que conoce, en una cuenta que no posee, y cada inicio de sesión posterior como esa cuenta es completamente legítimo. Compárese con las shadow credentials, donde el atacante añade una clave en lugar de una contraseña: mismo resultado, atributo distinto, y ambas derriban la suposición de que «el atacante aún tiene que romper algo», sobre la que todavía descansa buena parte del modelado de rutas de ataque de Active Directory. Las dos también se combinan: Semperis atribuye a Andrea Pierini la observación de que ResetNightmare «también puede combinarse con la técnica Shadow Credentials, permitiendo una ruta de ataque más sigilosa mediante el abuso de cuentas de equipo con permiso de escritura».

La cadena de ataque

Semperis publica la cadena paso a paso. El pivote es el mismo que hacía funcionar noPac: el nombre que porta el ticket se resuelve dos veces, y el atacante cambia a qué se resuelve entre medias. El orden siguiente no es cosmético: el UPN debe retirarse antes del cambio de contraseña, no después, o el atacante solo reiniciará su propia contraseña.

Paso 1 — Apuntar el UPN de una cuenta controlada hacia la víctima

El atacante escribe el sAMAccountName de la víctima en el userPrincipalName de una cuenta que ya controla, o que acaba de crear.

Set-ADUser -Identity 'controlledUser' -UserPrincipalName 'da-admin'

Paso 2 — Solicitar un TGT para kadmin/changepw por nombre enterprise

El atacante solicita un TGT con ámbito en el SPN kadmin/changepw, usando el tipo de nombre NT-ENTERPRISE, aportando el nombre de usuario de la víctima y la contraseña de la cuenta controlada. Ese SPN pertenece a krbtgt, así que, como dice Semperis, «un ticket para kadmin/changepw no es más que un TGT con el SPN (sname) cambiado». El KDC resuelve el nombre enterprise a través del UPN recién escrito, encuentra el objeto del atacante, y devuelve un ticket que porta el nombre de la víctima pero el SID del atacante en PAC_REQUESTOR_SID.

Paso 3 — Retirar el UPN, antes de tocar la contraseña

Este es el paso cuya posición decide si la cadena escala o no. El atacante ahora cambia o borra el UPN de la cuenta controlada, «sin dejar ningún usuario con el UPN que aparece en el ticket». Ejecutar el cambio de contraseña mientras el UPN sigue en su sitio, y el nombre enterprise todavía se resuelve al propio objeto del atacante: Semperis es explícito en que hacerlo «restablecerá la contraseña de UPNUser» y nada más.

Paso 4 — Impulsar el protocolo de cambio de contraseña

El TGT ya emitido se usa para construir una solicitud de cambio de contraseña mediante Kerberos, directamente a una AP-REQ en el puerto 464. No se emite ninguna TGS-REQ, así que el SID PAC Requestor nunca se comprueba, y la nueva contraseña recae sobre la víctima real. Semperis registra el contraste con precisión: reutilizar ese mismo ticket en una TGS-REQ tras el cambio de UPN «resultará en un error KDC_ERR_TGT_REVOKED, debido al parche PAC_REQUESTOR_SID, bloqueando la suplantación. Sin embargo, usando este ticket para construir la solicitud de cambio de contraseña, el cambio de contraseña funciona.»

Paso 5 — Autenticarse como la víctima

Se solicita un nuevo TGT para la cuenta víctima real, usando la contraseña que el atacante acaba de establecer y sin el tipo de nombre NT-ENTERPRISE. Vuelve con el tipo de nombre NT-PRINCIPAL, que es la prueba de que el ticket pertenece al verdadero titular del sAMAccountName. A partir de aquí, el atacante posee una identidad normal y totalmente válida.

La prueba de concepto pública envuelve todo esto en una única función de PowerShell. Requiere el módulo ActiveDirectory y una copia de Rubeus, y su uso publicado es una sola llamada:

Invoke-ResetNightmare -TargetAccount "victim" -TargetNewPassword "NewP@ssw0rd!" -UPNUser "controlledUser" -UPNUserPassword "ControlledP@ss!"

Quién puede realmente ejecutar esto, y quién no

Aquí es donde buena parte de la cobertura secundaria exagera el fallo, así que vale la pena citar la investigación directamente. Semperis afirma que la vulnerabilidad «permite una toma de control completa del dominio por un atacante que tenga permisos Generic Write sobre cualquier objeto de usuario o equipo del dominio, o que pueda crear objetos de usuario o equipo en el dominio (excluyendo MachineAccountQuota)».

Dos cláusulas de esa frase merecen énfasis, porque juntas fijan la barra real:

• Generic Write sobre cualquier objeto de usuario o equipo. No sobre la víctima. El atacante necesita acceso de escritura sobre un objeto que pueda apuntar hacia la víctima, lo cual en la mayoría de los dominios es una concesión mucho más común que el acceso de escritura sobre una cuenta Tier 0.
• Excluyendo MachineAccountQuota. Este es el límite que separa ResetNightmare de noPac. La capacidad por defecto de un usuario autenticado de unir diez equipos al dominio no es suficiente aquí, así que «cualquier usuario del dominio por defecto» es el resumen equivocado de este CVE.

El propio FAQ de Microsoft fija la otra mitad de la barra, el vector de ataque adyacente (AV:A): la explotación «requiere que el atacante esté en el mismo dominio restringido de Active Directory que el sistema objetivo». En el momento de la publicación, el MSRC también registró el fallo como no divulgado públicamente, no explotado, y «Exploitation Less Likely» — una evaluación hecha en abril de 2026, antes de que existieran la publicación y la prueba de concepto.

Hay una precondición adicional. Semperis señala que «el único otro requisito es que la contraseña del usuario objetivo debe tener la antigüedad suficiente», y observa que la antigüedad mínima de contraseña por defecto en la Default Domain Policy es de 1 día, así que una cuenta admin real casi siempre cumplirá esta condición.

Detección

El indicador principal citado por la investigación es el Event ID 5136, «se modificó un objeto del servicio de directorio», filtrado para adiciones de un userPrincipalName que coincide con el sAMAccountName de una cuenta existente. Es una firma precisa y de bajo ruido: en un dominio sano, un prefijo de UPN prácticamente nunca debería colisionar con el nombre de inicio de sesión de un objeto distinto.

En el lado de la contraseña, espere 4723 en lugar de 4724. Semperis separa directamente las dos operaciones del protocolo, señalando que Microsoft usa los términos «change password» y «set password» «para diferenciar entre un usuario que cambia su propia contraseña y un administrador que establece la contraseña de un usuario». ResetNightmare impulsa la operación de cambio — que es también por qué la antigüedad mínima de contraseña del objetivo es una precondición — así que el controlador de dominio registra el 4723, «se realizó un intento de cambiar la contraseña de una cuenta». El evento 4724 cubre la ruta de reinicio que toma un administrador o una cuenta de helpdesk delegada. Vale la pena vigilarlo por sí mismo, pero no es el artefacto que deja este CVE.

La misma colisión puede buscarse retrospectivamente en el estado del directorio, lo cual vale la pena hacer una vez incluso si su auditoría estaba desactivada:

# Cada prefijo de UPN que colisiona con el sAMAccountName de un objeto distinto
$sam = @{}
Get-ADObject -LDAPFilter '(|(objectClass=user)(objectClass=computer))' -Properties sAMAccountName |
    ForEach-Object { if ($_.sAMAccountName) { $sam[$_.sAMAccountName] = $_.DistinguishedName } }

Get-ADUser -Filter 'userPrincipalName -like "*"' -Properties userPrincipalName |
    Where-Object {
        $prefix = ($_.UserPrincipalName -split '@')[0]
        $sam.ContainsKey($prefix) -and $sam[$prefix] -ne $_.DistinguishedName
    } | Select-Object SamAccountName, UserPrincipalName, DistinguishedName

Remediación (Remediation)

1. Demuestre el parche, no lo asuma. Semperis es explícito: «la mejor prevención para estas vulnerabilidades es parchear todos los DC». Un solo DC sin parchear, o desconectado durante mucho tiempo, mantiene el dominio explotable, así que enumere los números de build en lugar de confiar en un panel de cumplimiento.

Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem,
    @{n='Build';e={ (Get-CimInstance Win32_OperatingSystem -ComputerName $_.HostName).Version }}

2. Elimine la delegación de reinicio de contraseña fuera del Tier 0. La segunda recomendación de la investigación es que «las organizaciones deberían atenerse al principio de mínimo privilegio y vigilar adiciones anómalas de permisos no predeterminados». El derecho a auditar es el derecho extendido User-Force-Change-Password, documentado por Microsoft con el nombre para mostrar «Reset Password» y el Rights-GUID 00299570-246d-11d0-a768-00aa006e0529.

$resetPwd = [guid]'00299570-246d-11d0-a768-00aa006e0529'
Get-ADUser -Filter * -SearchBase (Get-ADDomain).DistinguishedName | ForEach-Object {
    $dn = $_.DistinguishedName
    (Get-Acl "AD:$dn").Access |
        Where-Object { $_.ObjectType -eq $resetPwd -and $_.AccessControlType -eq 'Allow' } |
        Select-Object @{n='Target';e={$dn}}, IdentityReference, ActiveDirectoryRights
}

3. Restrinja quién puede crear cuentas. Puesto que el ataque funciona para un atacante que puede crear objetos de usuario o equipo fuera del MachineAccountQuota, revise los derechos Create Child delegados en las OU. Una delegación concedida hace años para un helpdesk o una herramienta de despliegue es el hallazgo habitual aquí, y es la misma clase de concesión obsoleta cubierta en la auditoría de ACE peligrosas y SID huérfanos.

4. Active la auditoría que hace visible el paso 1 de la cadena. Habilite Audit Directory Service Changes y configure SACL para que las escrituras de userPrincipalName en objetos de usuario y equipo generen el 5136.

5. No asuma nada sobre la ventana de exposición. El parche es de abril de 2026 y la PoC ya es pública. Si un DC se quedó atrás, trate los cambios de contraseña privilegiados en ese intervalo como sospechosos: revise los eventos 4723 contra objetivos Tier 0, junto con los 4724 para la ruta de reinicio delegada, y confirme que cada uno se corresponde con un ticket real de helpdesk. La lista de higiene más amplia de auditar la seguridad de Active Directory y la revisión Tier 0 de cuentas privilegiadas, Protected Users y delegación se aplican ambas directamente.

Semperis no nombra ninguna mitigación más allá del parcheo y el mínimo privilegio, y ese techo merece decirse con claridad. La pertenencia a Protected Users en particular no debería esperarse que detenga este ataque: las protecciones que Microsoft documenta para ese grupo bloquean NTLM, prohíben DES y RC4 en la preautenticación Kerberos, prohíben la delegación restringida y no restringida y limitan la vida del TGT, y ninguna de ellas es lo que falla aquí. El fallo está en cómo el KDC vincula una identidad durante el intercambio de cambio de contraseña, lo que también explica por qué las medidas de endurecimiento dirigidas al robo de tickets, como la limpieza de la delegación Kerberos o la rotación de la contraseña krbtgt, son útiles por otras razones pero irrelevantes para el CVE-2026-27912.

Cómo lo detecta EtcSec

ResetNightmare es un problema que se corrige una sola vez, pero su requisito previo es un problema de permisos que sobrevive a cualquier CVE concreto. EtcSec audita exactamente esa superficie.

ACL_USER_FORCE_CHANGE_PASSWORD y ACL_FORCECHANGEPASSWORD enumeran cada principal que posee el derecho extendido Reset Password, y ACL_GENERICALL saca a la luz las concesiones de escritura genérica que permiten a un atacante reescribir el userPrincipalName de otro objeto en primer lugar.

Para los equipos que trabajan con un marco de cumplimiento, ANSSI_R12_1_FORCE_PWD_RESET_PRIVS señala el User-Force-Change-Password concedido fuera de cuentas de sistema, y ANSSI_R12_2_USER_RESTRICTIONS_PRIVS hace lo mismo para User-Account-Restrictions. Ambos responden a la pregunta «quién puede actuar sobre esta cuenta» que el CVE-2026-27912 convierte en compromiso del dominio. Los controladores de dominio más antiguos elevan aún más el riesgo, lo que explica por qué el fin de soporte de Windows Server 2016 importa aquí.

Fuentes

• MSRC — CVE-2026-27912, Windows Kerberos Elevation of Privilege Vulnerability
• NVD — CVE-2026-27912
• Semperis — Identity Crisis: novel vulnerabilities leading to Kerberos downgrade, DoS and full domain takeover
• Semperis-Community/ResetNightmare (proof of concept)
• Microsoft — KB5008380 authentication updates (CVE-2021-42287)
• Microsoft — User-Force-Change-Password extended right
• Microsoft — Event 4723, an attempt was made to change an account's password
• Microsoft — Event 4724, an attempt was made to reset an account's password
• Microsoft — Protected Users security group
• Microsoft — Minimum password age