Hardening de Kerberos: RC4, roasting y golden tickets

Kerberos es la columna vertebral de la autenticación en AD, y sus formatos de ticket descifrables sin conexión lo convierten en un objetivo predilecto: Kerberoasting y AS-REP roasting convierten a cualquier atacante unido al dominio en un descifrador de contraseñas que trabaja sobre las propias respuestas de su DC, mientras que los golden y silver tickets permiten a un atacante que ya ha comprometido krbtgt o una cuenta de servicio falsificar autenticaciones indefinidamente. Nada de esto requiere una vulnerabilidad: funciona contra Kerberos exactamente tal como está diseñado cuando los tipos de cifrado y la configuración de las cuentas se dejan en los valores heredados predeterminados.

Esta guía cubre el endurecimiento del cifrado, la preautenticación y la higiene de SPN, el procedimiento de doble restablecimiento de krbtgt, el blindaje de Kerberos y cómo supervisar el abuso de falsificación de tickets.

Imponer AES, deshabilitar RC4

Cada cuenta (usuario, equipo y servicio) tiene un atributo msDS-SupportedEncryptionTypes que controla qué tipos de cifrado Kerberos acepta. Los valores heredados predeterminados suelen seguir permitiendo RC4-HMAC, mucho más fácil de descifrar sin conexión que AES-256.

Comprobar el estado actual en todo el dominio

# Cuentas que aún permiten RC4 o sin valor (el KDC aplica entonces su valor predeterminado, que sigue incluyendo RC4)
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 -or -not $_."msDS-SupportedEncryptionTypes" } |
    Select-Object Name, msDS-SupportedEncryptionTypes

Valores de bit de los tipos de cifrado: 1 = DES-CBC-CRC, 2 = DES-CBC-MD5, 4 = RC4-HMAC, 8 = AES128, 16 = AES256. Un valor de 24 significa solo AES128+AES256 (sin RC4/DES): ese es el estado objetivo.

Imponer mediante GPO

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos

Marque solo AES128_HMAC_SHA1 y AES256_HMAC_SHA1 (y Future encryption types si aparece). Deje sin marcar DES y RC4_HMAC_MD5.

Configurar por cuenta mediante PowerShell

# Establecer solo AES (valor 24) en una cuenta de servicio concreta
Set-ADUser -Identity "svc-sqlreporting" -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Corregir en bloque todas las cuentas de usuario que aún permiten RC4
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 } |
    ForEach-Object { Set-ADUser -Identity $_ -Replace @{"msDS-SupportedEncryptionTypes" = 24} }

Verificar

# Confirmar que ninguna cuenta anuncia todavía RC4
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 }
# No debe devolver nada

# Auditar el cifrado real de los tickets en uso mediante el registro de seguridad de los DC
# Event ID 4768 (solicitud de TGT) / 4769 (solicitud de ticket de servicio) — campo "Ticket Encryption Type"
# 0x12 = AES256, 0x17 = RC4
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 200 |
    ForEach-Object { [xml]$_.ToXml() } |
    ForEach-Object { $_.Event.EventData.Data | Where-Object Name -eq 'TicketEncryptionType' } |
    Group-Object '#text'

Cualquier entrada 0x17 (RC4) tras la aplicación indica un cliente o servicio que sigue negociando a la baja: investíguelo antes de dar por eliminado RC4 por completo.

Preautenticación y AS-REP roasting

La preautenticación Kerberos exige que el cliente cifre una marca de tiempo con la clave derivada de su contraseña antes de que el KDC emita un TGT: una prueba de conocimiento de la contraseña antes de entregar cualquier material de ticket. El indicador de cuenta DONT_REQ_PREAUTH la deshabilita, lo que permite a cualquiera solicitar un AS-REP para esa cuenta sin credencial alguna y después descifrar el ticket devuelto sin conexión contra la contraseña de la cuenta. Consulte AS-REP roasting para la ruta de ataque conceptual.

# Buscar cuentas con la preautenticación deshabilitada
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol |
    Select-Object Name, SamAccountName

# Corregir: eliminar el indicador DONT_REQ_PREAUTH
Set-ADAccountControl -Identity "jsmith" -DoesNotRequirePreAuth $false

Rara vez hay un motivo legítimo para este indicador fuera de casos concretos de interoperabilidad heredada: trate cualquier coincidencia como un hallazgo.

Riesgo de Kerberoasting por SPN en cuentas de usuario

Kerberoasting no requiere ningún indicador de configuración incorrecta en la cuenta: cualquier usuario autenticado puede solicitar un ticket de servicio para cualquier cuenta con un nombre de entidad de seguridad de servicio (SPN) e intentar descifrarlo sin conexión. El riesgo se concentra en las cuentas de usuario usadas como cuentas de servicio, porque suelen tener contraseñas elegidas por personas (más débiles y reutilizadas), a diferencia de las cuentas de equipo, que tienen contraseñas largas y aleatorias que rotan automáticamente. Consulte Kerberoasting.

# Buscar cuentas de usuario (no cuentas de equipo) con un SPN configurado
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, PasswordLastSet |
    Select-Object Name, ServicePrincipalName, PasswordLastSet

Mitigaciones, por orden de eficacia:

1. Migre las cuentas de servicio a Group Managed Service Accounts (gMSA): contraseñas aleatorias de 240 bytes (120 caracteres) que rotan automáticamente e inmunes en la práctica al descifrado sin conexión.
2. Donde no se admitan gMSA, use contraseñas largas (25 caracteres o más) generadas aleatoriamente y guardadas en una bóveda de contraseñas, nunca memorizadas por una persona.
3. Asegúrese de que msDS-SupportedEncryptionTypes sea solo AES en todas las cuentas con SPN: los tickets AES-256 son muchísimo más costosos de descifrar que los RC4.
4. Añada las cuentas con SPN de alto valor a Protected Users cuando sea compatible (consulte Tier 0 y acceso privilegiado).

El procedimiento de doble restablecimiento de krbtgt

La contraseña de la cuenta krbtgt deriva la clave usada para firmar todos los TGT de Kerberos del dominio. Si alguna vez se ve comprometida, directamente o mediante una extracción de tipo DCSync, un atacante puede falsificar TGT (golden tickets) para cualquier usuario, incluso para usuarios que no existen en AD, válidos hasta que rote la clave. Consulte DCSync.

Por qué dos restablecimientos, espaciados: AD mantiene válidos tanto el hash de la contraseña actual de krbtgt como el de la anterior, así que un único restablecimiento no invalida de inmediato los tickets falsificados con el hash antiguo: el DC los seguirá aceptando mediante el mecanismo de reserva de la «contraseña anterior». Debe restablecerla dos veces, con una separación de al menos la vigencia máxima de los tickets Kerberos (MaxTicketAge predeterminado = 10 horas; compruebe la directiva real MaxTicketAge/MaxRenewAge de su dominio, que puede haberse ampliado a días), para que la primera contraseña nueva salga por completo de ambas ranuras antes de aplicar el segundo restablecimiento.

# Comprobar primero la directiva de vigencia de tickets: determina la separación entre restablecimientos
# La directiva Kerberos no es un atributo de AD; reside en la GPO Default Domain Policy:
# Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy
[xml]$r = Get-GPOReport -Name "Default Domain Policy" -ReportType Xml
$r.GPO.Computer.ExtensionData.Extension.Account | Where-Object Type -eq 'Kerberos' | Select-Object Name, SettingNumber

# Restablecimiento 1
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<generate-random>" -Force)

# --- esperar al menos MaxTicketAge (normalmente 10 horas; confirme el valor de su dominio) ---

# Restablecimiento 2
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<generate-random-2>" -Force)

En entornos con varios DC, use el script publicado por Microsoft New-KrbtgtKeys.ps1 (o una herramienta equivalente contrastada) en lugar de restablecimientos improvisados: gestiona las comprobaciones de convergencia de la replicación entre ambos restablecimientos para que no rote antes de que todos los DC tengan el primer cambio. En un bosque con varios dominios, repita el proceso para la cuenta krbtgt de cada dominio, no solo para la raíz del bosque.

Ejecute esta rotación de forma periódica (muchas organizaciones lo hacen trimestralmente o tras cualquier sospecha de compromiso de credenciales), no solo como respuesta a incidentes.

Blindaje de Kerberos / FAST

FAST (Flexible Authentication Secure Tunneling), habilitado mediante Kerberos Armoring, encapsula el intercambio AS-REQ inicial en un canal cifrado y autenticado usando las propias credenciales del equipo solicitante, lo que protege los datos de preautenticación y reduce la exposición a ataques sin conexión contra contraseñas de usuario débiles.

Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring (llamada Support Dynamic Access Control and Kerberos armoring en Windows Server 2012): configúrela primero en Supported en los DC y después en Fail unarmored authentication requests solo cuando todos los DC y clientes lo admitan. En los clientes: Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring.

Requiere nivel funcional de dominio 2012 o superior y todos los DC actualizados antes de la aplicación.

Golden y silver tickets: cómo se combinan estas mitigaciones

Un golden ticket falsifica un TGT usando un hash robado de krbtgt; un silver ticket falsifica un ticket de servicio usando el hash robado de una cuenta de servicio, sin tocar nunca el KDC. Ninguno de los dos es una vulnerabilidad que se pueda «parchear»: son un abuso de la confianza legítima de Kerberos una vez robada una clave. La defensa es por capas:

• Solo AES + Protected Users en las cuentas Tier 0 y de servicio hace que los propios hashes sean más difíciles de obtener y más difíciles de descifrar si se exfiltran.
• La rotación de krbtgt (arriba) invalida cualquier golden ticket falsificado previamente y limita el valor de un hash robado en adelante.
• Supervisión de anomalías: TGT con vigencias inusualmente largas, tickets para cuentas que no existen o patrones de los eventos 4624/4768 incoherentes con los orígenes de inicio de sesión habituales.

# Un golden ticket falsificado nunca produce un 4768, así que los 4769 de una cuenta sin 4768
# correspondiente en ningún DC son la anomalía que hay que buscar. Ejecútelo en todos los DC (o consulte
# su SIEM) en una ventana mayor que la vigencia del TGT (10 h por defecto): un solo DC da falsos positivos.
$since  = (Get-Date).AddHours(-12)
$events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769; StartTime=$since} |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            Id      = $_.Id
            # 4769 registra user@REALM y 4768 el nombre sin dominio: normalizar antes de comparar
            Account = (($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text' -split '@')[0]
        }
    }
$withTgt = $events | Where-Object Id -eq 4768 | Select-Object -ExpandProperty Account -Unique
$events | Where-Object { $_.Id -eq 4769 -and $_.Account -notin $withTgt } |
    Group-Object Account | Sort-Object Count -Descending | Select-Object Name, Count

Qué rompe

• Las aplicaciones heredadas y los dispositivos de red (NAS antiguos, algunos programas de copia de seguridad, clientes Kerberos antiguos de Linux/Java, ciertos sistemas SCADA/industriales) que solo admiten RC4 no podrán autenticarse una vez deshabilitado RC4 en todo el dominio. Audite el TicketEncryptionType del evento 4769 durante 90 días antes de la aplicación para detectarlos.
• Los recursos compartidos de terceros o basados en versiones antiguas de Samba pueden no admitir AES256 de serie: verifíquelo antes del cambio.
• El doble restablecimiento de krbtgt, correctamente espaciado, tiene poco impacto visible porque el DC sigue aceptando los TGT firmados con la clave anterior. Restablecerla dos veces seguidas (el caso de respuesta a incidentes), o hacer el segundo restablecimiento antes de que el primero se haya replicado, invalida todos los TGT vigentes de ese dominio y obliga a usuarios y servicios a volver a autenticarse: programe una ventana de bajo impacto y espere una oleada de nuevos inicios de sesión.
• La aplicación del blindaje de Kerberos requiere que todos los sistemas operativos de DC y clientes admitan FAST; los entornos mixtos con DC heredados romperán la autenticación si se configura «Fail unarmored authentication requests» antes de tiempo.

Lecturas relacionadas: Tier 0 y acceso privilegiado para las protecciones a nivel de cuenta, Delegación para ver cómo se combinan los tickets falsificados con el abuso de la delegación, y NTLM y protocolos heredados para la capa de autenticación que Kerberos debe sustituir.