Rotación de contraseña krbtgt, cuenta de confianza, controlador de dominio: los tres secretos de AD que nunca rotan solos

Active Directory parece un sistema que mantiene sus propios secretos siempre actualizados. Los equipos unidos al dominio cambian su contraseña según un calendario, los trusts se renuevan solos en segundo plano y nadie recibe jamás un ticket por ello. Esa impresión explica exactamente por qué la higiene de rotación de contraseña krbtgt, cuenta de confianza, controlador de dominio es el vacío más silencioso en la mayoría de los entornos AD: uno de esos tres secretos no tiene ninguna rotación automática, y los otros dos solo rotan mientras nada está silenciosamente roto. Este artículo explica qué hace realmente cada mecanismo, cómo comprobar los tres en pocos minutos y cómo corregirlos sin provocar una interrupción de autenticación en todo el dominio.

Rotación de contraseña krbtgt, cuenta de confianza, controlador de dominio: quién rota qué

La trampa es una inferencia perfectamente razonable. La documentación de políticas de Microsoft afirma que "en los dominios basados en Active Directory, cada dispositivo tiene una cuenta y una contraseña. Por defecto, los miembros del dominio envían un cambio de contraseña cada 30 días" (Domain member: Maximum machine account password age). Los equipos realmente se mantienen solos, así que los administradores generalizan: el directorio gestiona sus propios secretos.

Dos de los tres secretos anteriores son, en efecto, automáticos. Pero automático aquí significa automático mientras todo está sano, y el secreto más valioso del dominio nunca fue automático, para empezar.

krbtgt: la contraseña que Active Directory nunca cambia por ti

La cuenta krbtgt es donde vive el material de claves Kerberos del dominio — cada TGT del dominio se cifra y se firma con su clave. Microsoft describe la cuenta exactamente en esos términos: "admite el almacenamiento de claves en todos los Key Distribution Centers (KDC) de Kerberos", y "[p]ara renovar las claves Kerberos usadas en el cifrado de TGT, cambie periódicamente la contraseña de la cuenta krbtgt" (Accounts security posture assessment). Nada en el directorio realiza ese cambio en tu nombre: no existe ningún temporizador de Netlogon ni ninguna configuración de política detrás de ello, solo un administrador ejecutando el restablecimiento a mano.

Ese es todo el problema. Sin rotación, el radio de explosión de una sola copia histórica de la base de datos de cuentas nunca se reduce, y Microsoft explica la consecuencia con claridad: "Si la contraseña de la cuenta KRBTGT se ve comprometida, un atacante puede usar su hash para generar tickets de autenticación Kerberos válidos, lo que le permite realizar ataques Golden Ticket y obtener acceso a cualquier recurso del dominio AD. Dado que Kerberos depende de la contraseña de KRBTGT para firmar todos los tickets, monitorizar de cerca y cambiar regularmente esta contraseña es esencial para mitigar el riesgo de este tipo de ataques." Su propia línea base pone una cifra a regularmente: Defender for Identity incluye una recomendación llamada Change password for krbtgt account, que "enumera cualquier cuenta krbtgt de tu entorno cuya contraseña se estableció por última vez hace más de 180 días". Qué algoritmos usan esas claves es la otra mitad de la historia, cubierta en nuestra guía sobre fallback de Kerberos RC4.

Lo que un atacante hace con esa clave se cubre en profundidad en nuestra guía de ataque Golden Ticket — este artículo trata sobre la higiene de rotación que hace que el ticket falsificado caduque en lugar de vivir para siempre.

Contraseñas de trust: automáticas solo desde un lado

Los trusts entre dominios sí rotan, y lo hacen sin que nadie lo pida. La documentación de Microsoft sobre el funcionamiento interno de los trusts describe el mecanismo: "Ambos dominios de una relación de trust comparten una contraseña, que se almacena en el objeto TDO en Active Directory. Como parte del proceso de mantenimiento de cuentas, cada treinta días, el controlador de dominio trusting cambia la contraseña almacenada en el TDO" (How Domain and Forest Trusts Work — un documento archivado de Windows Server 2003, todavía la descripción pública más detallada del proceso).

Tres detalles de ese documento importan a nivel operativo:

• Solo un lado lo impulsa. "Un controlador de dominio del dominio trusted nunca inicia el cambio de contraseña; siempre lo inicia el emulador de PDC del dominio trusting."
• La contraseña antigua se conserva deliberadamente. Si la autenticación con la nueva contraseña falla, el controlador de dominio trusting "intenta autenticarse usando la contraseña antigua", y si eso tiene éxito "reanuda el proceso de cambio de contraseña en un plazo de 15 minutos" — por eso tanto el valor antiguo como el nuevo viven en el TDO.
• La replicación tiene un plazo estricto. "Las actualizaciones de contraseña del trust deben replicarse a los controladores de dominio de ambos lados del trust en un plazo de 30 días. Si la contraseña del trust cambia después de 30 días y un controlador de dominio solo tiene entonces la contraseña N-2, no puede usar el trust desde el lado trusting y no puede crear un canal seguro en el lado trusted."

El secreto en sí no es un atributo de contraseña normal: Microsoft señala que los secretos de trust "están representados por atributos especiales en las cuentas de trust entre dominios", trustAuthIncoming en el lado trusted y trustAuthOutgoing en el lado trusting, y que "los mantiene el controlador de dominio que ejerce el rol FSMO (Flexible Single Master Operation) de emulador de PDC (primary domain controller) en el dominio trusting" (UserAccountControl property flags).

Lo que sí puedes leer es la cuenta de trust entre dominios que acompaña al TDO. Según MS-ADTS, los trusts cuyo trustDirection es entrante o bidireccional tienen una cuenta de usuario asociada en el contenedor de usuarios por defecto, y los dos objetos están vinculados por el nombre NetBIOS del socio: el flatName del TDO es igual al sAMAccountName de la cuenta menos el $ final. El checkpoint de ANSSI Trust account passwords unchanged for more than a year lee exactamente el pwdLastSet de esa cuenta, y su veredicto merece citarse: un valor obsoleto "puede ser indicativo de relaciones de trust eliminadas mientras sus cuentas de trust correspondientes siguen presentes", y cuando el trust sigue vivo, "debe investigarse la causa de la falta de renovación automática".

Si estás auditando trusts de forma más amplia, combina esto con nuestros artículos sobre rutas de ataque de trust y auditoría de SID filtering y autenticación selectiva.

Contraseñas de equipo del controlador de dominio: automáticas hasta que algo las bloquea

Los controladores de dominio también son miembros del dominio, y sus cuentas de equipo rotan según el mismo calendario de Netlogon que una estación de trabajo. El KB 154501 de Microsoft lo dice sin rodeos: "A partir de los equipos basados en Windows 2000, la contraseña de la cuenta de equipo cambia automáticamente cada 30 días" (Disable machine account password changes). La política que rige el intervalo permite un "número de días definido por el usuario, entre 1 y 999", con un valor por defecto efectivo de 30 días tanto en controladores de dominio como en servidores miembro y clientes.

Un DC cuya contraseña de equipo no se ha movido en meses no es, por tanto, una elección de política — es una señal. El checkpoint de ANSSI Domain controllers with passwords unchanged for more than 45 days es inequívoco: "Algunos controladores de dominio no han cambiado su contraseña en más de 45 días, lo que indica que sus secretos no se renuevan", y "debe investigarse el motivo por el que este cambio no se produce correctamente, ya que puede ser indicativo de un compromiso."

Los culpables habituales son locales a la máquina:

• DisablePasswordChange establecido en 1 bajo HKLM\System\CurrentControlSet\Services\Netlogon\Parameters, que impide que la máquina llegue a enviar un cambio — este es el que congela el propio secreto de un controlador de dominio.
• Un valor de MaximumPasswordAge empujado muy alto, o una GPO que establece silenciosamente cualquiera de los dos valores.
• El servicio Netlogon no está en ejecución, o un canal seguro que ya está roto.

Aquí se culpa a un valor de registro que no tiene nada que ver. RefusePasswordChange establecido en 1 "hace que el controlador de dominio rechace las solicitudes de cambio de contraseña solo de estaciones de trabajo o servidores miembro que ejecuten Windows NT versión 4.0 o posterior" — congela las contraseñas de equipo de tus miembros, no la del propio DC. Revísalo cuando los objetos de equipo miembro dejen de rotar: con RefusePasswordChange, "el tráfico de replicación se detendrá, pero no el tráfico de cliente", mientras que DisablePasswordChange detiene ambos.

Merece la pena repetir la propia advertencia de Microsoft sobre desactivar esto: "Si deshabilita los cambios de contraseña de la cuenta de equipo, existen riesgos de seguridad porque el canal seguro se utiliza para la autenticación pass-through. Si alguien descubre una contraseña, podría potencialmente realizar autenticación pass-through hacia el controlador de dominio." La documentación de la política añade la otra mitad: "Aumentar significativamente el intervalo de cambio de contraseña (o deshabilitar los cambios de contraseña) le da a un atacante más tiempo para llevar a cabo un ataque de fuerza bruta contra una de las cuentas de equipo."

El secreto de una cuenta de equipo también es material para tickets de servicio de todo lo que se ejecuta en ese host, que es el mecanismo detrás de un ataque Silver Ticket — y en un controlador de dominio, las anomalías alrededor del objeto de equipo merecen el mismo escrutinio que una fuente de replicación inesperada, el truco que usa DCShadow. Para una visión más amplia de la identidad de equipo, consulta nuestro desglose de la superficie de ataque de los objetos de equipo.

Detección

Tres consultas, ejecutadas desde una estación de administración unida al dominio con RSAT, cubren el trío completo.

1. Las cuentas krbtgt, incluidas las de cada RODC:

Get-ADUser -Filter "SamAccountName -like 'krbtgt*'" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet, Enabled

2. Las cuentas de trust entre dominios, resueltas a partir de los propios TDO:

Get-ADObject -Filter "objectClass -eq 'trustedDomain'" -Properties flatName, trustDirection |
    ForEach-Object {
        Get-ADUser -Identity ('{0}$' -f $_.flatName) -Properties PasswordLastSet -ErrorAction SilentlyContinue |
            Select-Object SamAccountName, PasswordLastSet
    }

Las mismas cuentas se pueden listar directamente mediante el flag INTERDOMAIN_TRUST_ACCOUNT — decimal 2048, hexadecimal 0x0800 — usando la regla de coincidencia LDAP_MATCHING_RULE_BIT_AND con el OID 1.2.840.113556.1.4.803 (Search Filter Syntax):

Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=2048)" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

3. Todos los objetos de equipo de los controladores de dominio:

Get-ADDomainController -Filter * | ForEach-Object {
    Get-ADComputer $_.ComputerObjectDN -Properties PasswordLastSet |
        Select-Object Name, PasswordLastSet
}

Lee la salida frente a estos umbrales:

Las señales de registro de eventos correspondientes:

El evento 4742 "se genera solo en controladores de dominio", lo que hace que la recopilación del lado del DC sea suficiente para esta comprobación. En una máquina sospechosa, nltest /sc_query:<domain> devuelve ERROR_ACCESS_DENIED cuando el canal seguro está roto (Broken trust relationship between a domain-joined device and its domain).

Remediación

🚨 Peligro: nunca ejecutes los dos restablecimientos de krbtgt uno detrás de otro. El segundo restablecimiento antes de que el primero se haya replicado por completo invalida los tickets en todo el dominio y puede tumbar la autenticación con él.

Rotar krbtgt, por etapas

1. Verifica primero la replicación. El procedimiento de doble restablecimiento solo funciona si todos los controladores de dominio han visto la primera contraseña nueva antes de que llegue la segunda, así que confirma que la replicación está sana antes de empezar. repadmin /replsummary "identifica los controladores de dominio que están fallando en la replicación entrante o saliente, y resume los resultados en un informe".
2. Restablécela una vez, usando el procedimiento soportado en AD Forest Recovery - Reset the krbtgt password. La contraseña que escribas es irrelevante: "el sistema genera automáticamente una contraseña segura, independiente de la contraseña que especifiques".
3. Espera. Microsoft: "Debe realizar esta operación dos veces. Debe esperar 10 horas entre restablecimientos de contraseña. 10 horas es el valor por defecto de las configuraciones de política Maximum lifetime for user ticket y Maximum lifetime for service ticket, por lo que, en caso de que el periodo de vida máxima cambie, el periodo mínimo de espera entre restablecimientos debería ser mayor que el valor configurado." Trata las 10 horas como un mínimo y no como un objetivo: en un bosque grande o con replicación lenta, dejar un día completo entre los dos restablecimientos no cuesta nada.
4. Restablécela una segunda vez. Ambos restablecimientos son necesarios porque "el valor del historial de contraseñas de la cuenta krbtgt es 2, lo que significa que incluye las dos contraseñas más recientes" — un solo restablecimiento deja la clave anterior en el historial y todavía utilizable. Microsoft: "Al restablecer la contraseña dos veces, se eliminan efectivamente las contraseñas antiguas del historial, de modo que no hay forma de que otro DC replique con este DC usando una contraseña antigua."
5. Ponlo en un calendario. Defender for Identity empieza a marcar la cuenta a partir de los 180 días, lo que convierte una rotación dos veces al año en un valor por defecto defendible. Sea cual sea el intervalo que elijas, la rotación solo existe si alguien es responsable de ella.

Corregir una contraseña de trust obsoleta

1. Decide si el trust todavía existe. Compara las cuentas de trust que encontraste con los TDO activos. La remediación de ANSSI para los huérfanos es directa: "Algunas cuentas de trust pueden permanecer aunque sus relaciones de trust hayan sido eliminadas. Deben eliminarse manualmente."
2. Para un trust activo, verifica el canal seguro antes de tocar nada: netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify — el parámetro /verify "verifica los secretos del canal seguro para una relación de trust específica" (netdom trust).
3. Investiga antes de restablecer. Una contraseña de trust que no se ha movido en meses significa que el emulador de PDC del dominio trusting no pudo completar el intercambio — comprueba la conectividad con el socio, la salud del rol de emulador de PDC y la replicación del TDO en ambos lados, recordando la regla N-2 mencionada antes.
4. Restablece el secreto del trust solo dentro de una ventana de cambios, con credenciales de ambos lados: netdom trust <TrustingDomain> /domain:<TrustedDomain> /userd:<TrustedDomain>\admin /passwordd:* /reset. El parámetro /reset "restablece el secreto de trust entre dominios trusted, o entre el controlador de dominio (DC) y la estación de trabajo".

Volver a poner en marcha la rotación de un controlador de dominio

1. Confirma que el servicio está en ejecución: sc.exe query netlogon.
2. Comprueba los dos valores de registro de Netlogon bajo HKLM\System\CurrentControlSet\Services\Netlogon\Parameters — la remediación de ANSSI espera que DisablePasswordChange sea 0 o esté ausente, y que MaximumPasswordAge sea 30, y te indica que confirmes que ninguna GPO los está sobrescribiendo.
3. Verifica que la contraseña de la máquina coincide con la del directorio: nltest /sc_verify:<NetBIOSDomainName> debería devolver 0 0x0 NERR_Success.
4. Si el DC está desincronizado porque se restauró desde un estado anterior, trátalo como una reparación de canal seguro, no como un problema de rotación — Microsoft documenta ambas direcciones del desajuste (el dispositivo más reciente que AD, y AD más reciente que el dispositivo).

La higiene de rotación se sitúa junto al resto de tu postura de credenciales — las políticas débiles, las contraseñas que no caducan y el almacenamiento en texto claro se cubren en Seguridad de contraseñas en Active Directory, y las tres comprobaciones anteriores encajan directamente en una auditoría de seguridad de Active Directory más amplia.

Cómo lo detecta EtcSec

Una auditoría de EtcSec comprueba los tres secretos en la misma pasada. ANSSI_R28_KRBTGT_NOT_ROTATED (Crítico) lee el pwdLastSet de cada cuenta krbtgt y marca los dominios que superan la marca de 180 días. ANSSI_R42_TRUST_PASSWORD_OLD (Alto) resuelve cada objeto de dominio trusted a su cuenta de trust entre dominios y reporta las contraseñas que dejaron de rotar — incluidas las cuentas huérfanas que dejan atrás los trusts eliminados. ANSSI_R43_DC_PASSWORD_OLD (Alto) y COMPUTER_PASSWORD_OLD comparan cada controlador de dominio y objeto de equipo miembro con la cadencia de 30 días de Netlogon, de modo que un canal seguro bloqueado aparece como un hallazgo en lugar de como un ticket de soporte seis meses después. GOLDEN_TICKET_RISK conecta el resultado de krbtgt con lo que un atacante realmente hace con una clave que nunca cambia.

Referencias

• Microsoft — AD Forest Recovery: Reset the krbtgt password
• Microsoft — Accounts security posture assessment (Defender for Identity)
• Microsoft — How Domain and Forest Trusts Work
• Microsoft — UserAccountControl property flags (KB 305144)
• Microsoft — Disable machine account password changes (KB 154501)
• Microsoft — Domain member: Maximum machine account password age
• Microsoft — MS-ADTS: Essential Attributes of Interdomain Trust Accounts
• Microsoft — 4742(S): A computer account was changed and 4724(S, F): An attempt was made to reset an account's password
• Microsoft (archived) — New-KrbtgtKeys.ps1, de solo lectura desde el 8 de marzo de 2024
• ANSSI / CERT-FR — Points de controle Active Directory (CERTFR-2020-DUR-001), colección de checkpoints en cert.ssi.gouv.fr/uploads/ad_checklist.html — checkpoints Trust account passwords unchanged for more than a year y Domain controllers with passwords unchanged for more than 45 days