Deshabilitar RC4 en Kerberos: auditar, corregir y exigir AES

RC4-HMAC es el tipo de cifrado de Kerberos que abarata el Kerberoasting: un ticket RC4 se cifra con el hash NT sin sal de la cuenta, así que descifrarlo cuesta más o menos lo mismo que descifrar un hash NTLM, y un atacante que ya tenga el hash NT puede falsificar tickets RC4 sin conocer la contraseña. Los tickets AES usan una derivación de clave con sal e iteraciones y son órdenes de magnitud más lentos de atacar. La mayoría de los dominios siguen emitiendo tickets RC4 al menos para algunas cuentas, no porque algo los necesite, sino porque nadie ha demostrado que nada los necesita.

Esta guía es la versión paso a paso de la sección sobre RC4 de Hardening de Kerberos: cómo elige realmente el KDC un tipo de cifrado, cómo medir el uso de RC4, cómo corregir las cuentas que no pueden usar AES y cómo aplicarlo sin interrupciones del servicio.

Cómo elige el KDC un tipo de cifrado

Tres entradas deciden el tipo de cifrado de un ticket de servicio:

1. El msDS-SupportedEncryptionTypes de la cuenta de destino (indicadores de bits: 0x4 RC4, 0x8 AES128, 0x10 AES256, 0x20 claves de sesión AES). Si está configurado, el KDC usa el tipo más robusto que la cuenta enumera y para el que tiene una clave.
2. DefaultDomainSupportedEncTypes en el KDC, usado cuando el atributo está vacío. Las cuentas sin el atributo configurado son mayoría, así que este valor del registro es el verdadero valor predeterminado de todo el dominio.
3. Las claves almacenadas para la cuenta. Un tipo enumerado en el atributo no sirve de nada si la cuenta no tiene clave para él.

Las cuentas de equipo rellenan ellas mismas msDS-SupportedEncryptionTypes a partir de la directiva del cliente. Las cuentas de servicio basadas en usuarios casi nunca lo tienen configurado, así que siguen DefaultDomainSupportedEncTypes, lo que históricamente significaba tickets RC4. Desde las actualizaciones de Kerberos de noviembre de 2022 (CVE-2022-37966), el valor predeterminado que se asume para las cuentas sin el atributo es 0x27 (DES, RC4 y claves de sesión AES), lo que proporciona claves de sesión AES pero sigue cifrando el ticket con RC4. Microsoft ha anunciado nuevos cambios para llevar los DC a valores predeterminados solo AES durante 2026, así que confirme el comportamiento de su nivel de actualización actual en las notas de la versión antes de confiar en los valores predeterminados.

Medir: encontrar dónde se usa RC4

Habilitar la auditoría adecuada

En los DC: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon, habilite Audit Kerberos Authentication Service y Audit Kerberos Service Ticket Operations para aciertos y errores. Esto genera los eventos 4768 (TGT) y 4769 (ticket de servicio), ambos con un campo TicketEncryptionType: 0x17 es RC4, 0x11 AES128, 0x12 AES256. Las actualizaciones recientes de Windows Server han añadido a estos eventos campos que describen las claves disponibles y los tipos admitidos de la cuenta, lo que facilita los pasos siguientes si sus DC los incluyen.

# Tickets de servicio RC4 de las últimas 24 horas, agrupados por servicio y cliente
$since = (Get-Date).AddHours(-24)
Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'Security'; Id = 4769; StartTime = $since
    } -ErrorAction SilentlyContinue
} | ForEach-Object {
    $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    if ($d.TicketEncryptionType -eq '0x17') {
        [pscustomobject]@{ Service = $d.ServiceName; Client = $d.TargetUserName; Address = $d.IpAddress }
    }
} | Group-Object Service, Client, Address | Sort-Object Count -Descending |
    Select-Object Count, Name

Ejecute la misma consulta sobre el evento 4768 para encontrar clientes que solicitan TGT RC4. Reenvíe estos eventos a su SIEM para disponer de una ventana adecuada de 30 a 90 días; Get-WinEvent en DC con mucha carga solo ve lo que conserva el registro local. Microsoft también publica scripts auxiliares en su repositorio de GitHub Kerberos-Crypto que resumen el uso del cifrado a partir de estos eventos.

Encontrar cuentas sin claves AES

Las claves AES se crean cuando se establece una contraseña en un DC con Windows Server 2008 o posterior en un dominio con nivel funcional 2008 o superior. La fecha de creación del grupo Read-only Domain Controllers (RID 521) es un marcador fiable del momento en que el dominio se preparó para ese nivel. Cualquier cuenta cuya contraseña sea anterior no tiene claves AES.

$domainSid = (Get-ADDomain).DomainSID.Value
$aesDate = (Get-ADGroup -Identity "$domainSid-521" -Properties whenCreated).whenCreated

Get-ADUser -Filter 'Enabled -eq $true' -Properties PasswordLastSet, ServicePrincipalName |
    Where-Object { $_.PasswordLastSet -lt $aesDate } |
    Select-Object SamAccountName, PasswordLastSet, @{n='HasSPN';e={[bool]$_.ServicePrincipalName}}

Incluya krbtgt y las cuentas de confianza en la revisión. Una contraseña de krbtgt anterior a esa fecha es un hallazgo en sí misma; rótela siguiendo el procedimiento de rotación de krbtgt.

Comprobar configuraciones RC4 explícitas

# Cuentas con RC4 o DES permitidos explícitamente (cualquiera de los bits 0x1, 0x2, 0x4)
Get-ADObject -LDAPFilter '(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.804:=7)' `
    -Properties msDS-SupportedEncryptionTypes, objectClass |
    Select-Object Name, objectClass, msDS-SupportedEncryptionTypes

# Confianzas: los TDO sin indicadores AES recurren a tickets de referencia RC4
Get-ADObject -Filter 'objectClass -eq "trustedDomain"' -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

Auditar: corregir los bloqueos

Recorra la lista de la fase de medición:

• Cuentas sin claves AES: restablezca la contraseña. Para las cuentas de servicio, coordínese con el responsable de la aplicación o, mejor aún, migre a una gMSA (consulte migración a gMSA).
• Cuentas de servicio usadas por sistemas no Windows: regenere los keytabs con AES, por ejemplo ktpass /crypto AES256-SHA1 para la asignación del SPN, y actualice permitted_enctypes en el krb5.conf del cliente. Los keytabs antiguos que solo contienen claves RC4 fallan en cuanto se elimina RC4.
• Dispositivos y software heredado que solicitan RC4 explícitamente: actualícelos, reconfigúrelos o documente una excepción con fecha de caducidad estableciendo msDS-SupportedEncryptionTypes en 0x1C (RC4 más AES) solo en esa cuenta.
• Confianzas: habilite AES en ambos lados con The other domain supports Kerberos AES Encryption en las propiedades de la confianza, o con ksetup /setenctypeattr <trusted domain> AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96.

Marque explícitamente las cuentas de servicio como compatibles con AES para que dejen de depender del valor predeterminado del KDC:

# AES128 + AES256 en las cuentas de usuario que tienen SPN
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.SamAccountName -ne 'krbtgt' } |
    ForEach-Object { Set-ADUser $_ -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 } }

Planificar el despliegue

Eliminar RC4 es de bajo riesgo cuando resulta aburrido: pasos pequeños, cada uno reversible y cada uno medido. Un plan que funciona en la mayoría de los dominios medianos:

1. Semanas 1 a 4: solo medir. Auditoría activada, eventos reenviados, informe de cuentas sin claves AES generado. Elabore una lista de todos los clientes y servicios que han aparecido en un evento RC4, con un responsable para cada uno.
2. Semanas 3 a 8: corregir cuentas. Restablezca las contraseñas de las cuentas sin claves AES, establezca msDS-SupportedEncryptionTypes en 24 en las cuentas de servicio, regenere los keytabs y habilite AES en las confianzas. Cada corrección debería hacer desaparecer una línea del informe de RC4; si no lo hace, la causa raíz está en otra parte.
3. Semanas 6 a 10: directiva de cliente por anillos. Estaciones de trabajo piloto, después todas las estaciones de trabajo y después los servidores miembro. Los clientes que dejan de solicitar RC4 no necesitan que el KDC lo rechace, así que este anillo rara vez causa problemas.
4. Tras dos semanas sin incidencias: el KDC. Configure DefaultDomainSupportedEncTypes y la directiva Kerberos en los DC, empezando por los DC de un solo sitio si su topología lo permite.
5. De forma continua: excepciones. Cada cuenta que conserve RC4 recibe un ticket con un responsable y una fecha de caducidad, y se incluye en un grupo como Kerberos-RC4-Exceptions para que la excepción sea visible en AD y no en una hoja de cálculo.

La reversión en cada paso es un valor del registro o un vínculo de GPO. Planifique un reinicio de los DC en cada anillo del KDC para que el cambio del registro se aplique de forma fiable, y lo mismo para la reversión. Los tickets existentes siguen siendo válidos hasta que caducan, así que los problemas pueden tardar hasta la vigencia de los tickets (10 horas de forma predeterminada) en aparecer. Mantenga la ventana de cambios abierta el tiempo suficiente para verlos, y no acumule el cambio del KDC con otros cambios de autenticación, como la aplicación de la firma LDAP, en la misma semana, o no sabrá cuál de ellos rompió una aplicación determinada.

Aplicar

Aplique en dos capas, un anillo cada vez.

Valor predeterminado del KDC. En cada DC, configure el valor que se aplica a todas las cuentas sin atributo explícito:

# 0x18 = AES128 + AES256. Use 0x38 para anunciar también las claves de sesión AES.
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' `
    -Name 'DefaultDomainSupportedEncTypes' -Type DWord -Value 0x18

Despliéguelo mediante las preferencias de directiva de grupo (Computer Configuration > Preferences > Windows Settings > Registry) vinculadas a la OU Domain Controllers para que todo DC nuevo lo reciba.

Directiva Kerberos. Aplique Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos con solo AES128_HMAC_SHA1, AES256_HMAC_SHA1 y Future encryption types marcados. Escribe SupportedEncryptionTypes en HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. En los equipos miembro limita lo que solicita el cliente y actualiza el atributo de la cuenta de equipo; en los DC limita lo que emitirá el KDC. Despliéguela primero en una OU piloto de estaciones de trabajo y servidores, después en el Tier 1 y, por último, en los DC.

Verificar

Tras cada anillo, repita la consulta del evento 4769. El objetivo es cero tickets 0x17 fuera de las excepciones documentadas.

# En un DC: confirmar la configuración efectiva
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' -Name DefaultDomainSupportedEncTypes
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
    -Name SupportedEncryptionTypes

# En un cliente: los tickets de la caché deben mostrar AES-256-CTS-HMAC-SHA1-96
klist

Vigile también los errores de los eventos 4768 y 4769 con el código de resultado 0xE (KDC_ERR_ETYPE_NOTSUPP): cada uno es un cliente o servicio que ha perdido la capacidad de autenticarse y requiere atención.

Qué rompe

• Las cuentas sin claves AES, incluidas las cuentas de servicio antiguas que nadie se atrevía a restablecer, no pueden obtener tickets. La solución es un restablecimiento de contraseña, que puede a su vez romper la aplicación si la contraseña está codificada en algún sitio.
• Las integraciones basadas en keytabs en Linux, Java y dispositivos (SSO web, SAP, almacenamiento) dejan de autenticarse hasta que se regeneran los keytabs con claves AES.
• Las versiones antiguas de NAS y Samba que no admiten AES para cuentas de equipo o de servicio, y algunas aplicaciones de negocio heredadas que fijan RC4.
• Las confianzas entre bosques y externas sin AES habilitado en el objeto de confianza rompen los tickets de referencia una vez eliminado RC4.
• Los sistemas de la época de Windows XP / Server 2003: no admiten AES en absoluto. No deberían existir, pero si existen, dejarán de autenticarse.

Lecturas relacionadas: el área de Kerberos y autenticación, defensa contra Kerberoasting para entender por qué AES es importante en las cuentas de servicio, y restringir NTLM para cerrar la exposición del hash NT que la eliminación de RC4 no resuelve.