Defensa contra Kerberoasting y AS-REP roasting

El Kerberoasting no necesita más que una cuenta de dominio. El atacante enumera las cuentas con un nombre de entidad de seguridad de servicio (SPN), solicita un ticket de servicio para cada una y descifra los tickets sin conexión con herramientas como Hashcat. El DC registra un evento 4769 rutinario y no ocurre nada más hasta que cae la contraseña de una cuenta de servicio. El AS-REP roasting es la misma idea aplicada a las cuentas que no requieren la preautenticación Kerberos, y ni siquiera necesita una cuenta de dominio. Ambos ataques se dirigen a contraseñas elegidas por personas en cuentas que a menudo tienen muchos más privilegios de los que creen sus responsables.

La guía de Hardening de Kerberos presentó ambos ataques. Esta es el plan operativo: medir su superficie expuesta al roasting, eliminar lo que no necesita, hacer indescifrable el resto y detectar los intentos que no puede evitar.

Medir: su superficie expuesta al roasting

Las cuentas de equipo también tienen SPN, pero sus contraseñas son aleatorias y rotan cada 30 días, así que no son objetivos prácticos. El riesgo son las cuentas de usuario con SPN. Excluya krbtgt, que tiene el SPN kadmin/changepw pero no puede someterse a roasting mediante una solicitud normal de ticket de servicio.

Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate, AdminCount,
                msDS-SupportedEncryptionTypes, MemberOf, Enabled |
    Where-Object { $_.SamAccountName -ne 'krbtgt' } |
    Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, AdminCount,
        @{n='EncTypes';e={$_.'msDS-SupportedEncryptionTypes'}},
        @{n='SPNs';e={$_.ServicePrincipalName -join '; '}} |
    Sort-Object PasswordLastSet

Clasifique el resultado según tres preguntas:

1. ¿Es privilegiada? AdminCount = 1 o la pertenencia a cualquier grupo Tier 0 significa que una contraseña descifrada equivale a un compromiso del dominio. Estas van primero. Trátelas como Tier 0 mientras no se demuestre lo contrario.
2. ¿Qué antigüedad tiene la contraseña? Un PasswordLastSet de hace años casi siempre significa una contraseña corta elegida por una persona y, posiblemente, ninguna clave AES.
3. ¿Permite RC4? Un msDS-SupportedEncryptionTypes vacío o que incluya RC4 significa que el KDC puede emitir tickets RC4 para ella.

En el caso del AS-REP roasting, la exposición es el indicador DONT_REQ_PREAUTH (bit 0x400000 de userAccountControl):

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, Enabled, PasswordLastSet

No olvide quién puede crear nueva exposición. Cualquier entidad de seguridad con acceso de escritura a servicePrincipalName en un usuario puede añadir un SPN y someterlo a roasting (el llamado Kerberoasting dirigido), y cualquiera que pueda cambiar userAccountControl puede deshabilitar la preautenticación. Es un problema de ACL; audítelo con seguridad de ACL y objetos.

Por qué importa el tipo de cifrado

Un ticket de servicio RC4 se cifra con una clave que es simplemente el hash NT de la cuenta, así que cada intento de adivinar la contraseña cuesta un cálculo MD4. Un ticket AES usa una clave derivada con PBKDF2 (4.096 iteraciones de HMAC-SHA1) con sal basada en el dominio Kerberos y el nombre de la cuenta, lo que hace que cada intento sea miles de veces más costoso en el mismo hardware. Esa diferencia convierte una contraseña de ocho caracteres de «descifrada durante la comida» en «no compensa la electricidad», pero no salva a una contraseña que aparece en un diccionario. Trate AES como un multiplicador de la robustez de la contraseña, no como un sustituto, y recuerde que muchas herramientas de roasting solicitarán RC4 siempre que la cuenta aún lo permita.

Auditar: decidir cuenta por cuenta

Para cada cuenta de usuario con SPN, elija un resultado:

Compruebe LastLogonDate y los eventos 4769 para confirmar si un SPN se solicita realmente antes de eliminarlo:

# Eliminar un SPN obsoleto de una cuenta
Set-ADUser -Identity 'svc-oldreport' -ServicePrincipalNames @{ Remove = 'HTTP/oldreport.corp.example.com' }

# Buscar SPN duplicados en todo el dominio (los duplicados también rompen Kerberos)
setspn -X

Aplicar: hacer indescifrables los tickets restantes

Migrar a gMSA

Una gMSA tiene una contraseña aleatoria de 120 caracteres gestionada por el dominio y rotada automáticamente. Sus tickets se pueden seguir solicitando, pero descifrarlos no es realista. SQL Server, los grupos de aplicaciones de IIS, las tareas programadas y la mayoría de los servicios de Windows admiten gMSA. Los detalles por aplicación están en migrar cuentas de servicio a gMSA.

# Tras la migración: la cuenta antigua no debe tener ningún SPN
Get-ADUser 'svc-sql01' -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName
Get-ADServiceAccount 'gmsa-sql01' -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName

Contraseñas largas y solo AES para el resto

Para las cuentas que deban seguir siendo cuentas de usuario:

• Genere una contraseña aleatoria de al menos 25 caracteres con su PAM o gestor de contraseñas, y rótela con una periodicidad que la aplicación pueda tolerar.
• Imponga la longitud con una directiva de contraseñas específica (fine-grained password policy) aplicada a un grupo ServiceAccounts, para que los restablecimientos manuales no puedan quedar por debajo.
• Establezca msDS-SupportedEncryptionTypes en 24 (AES128 + AES256) y restablezca después la contraseña si es anterior a la compatibilidad con AES, para que existan claves AES.

New-ADFineGrainedPasswordPolicy -Name 'PSO-ServiceAccounts' -Precedence 10 `
    -MinPasswordLength 25 -ComplexityEnabled $true -PasswordHistoryCount 24 `
    -MaxPasswordAge '365.00:00:00' -LockoutThreshold 0
Add-ADFineGrainedPasswordPolicySubject -Identity 'PSO-ServiceAccounts' -Subjects 'ServiceAccounts'

Set-ADUser 'svc-app01' -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }

AES por sí solo no salva una contraseña débil; solo encarece cada intento. La longitud y la aleatoriedad hacen el trabajo real. La eliminación de RC4 en todo el dominio se trata en deshabilitar RC4 en Kerberos.

Ocuparse primero de las cuentas de servicio privilegiadas

El peor hallazgo en casi todas las evaluaciones es una cuenta de servicio con SPN que además es Domain Admin, a menudo porque un instalador lo pidió hace una década. Descifrar esa única contraseña pone fin al ejercicio. Antes de cualquier otra corrección, saque estas cuentas de los grupos privilegiados y concédales solo los derechos que la aplicación usa realmente, que suelen ser administrador local en unos pocos servidores o un permiso delegado sobre una OU.

Esto requiere negociar con los responsables de las aplicaciones, así que reúna primero las evidencias: en qué servidores inicia sesión la cuenta (eventos 4624 en esos servidores, o LastLogonDate más los nombres de host de los SPN), qué tareas programadas y servicios la usan y qué permisos de AD ejerce. Cuando la aplicación no pueda funcionar sin derechos a nivel de dominio, la cuenta y todos los servidores en los que se ejecuta son Tier 0 y deben gestionarse como tales. Cualquiera de los dos resultados es mejor que un Domain Admin susceptible de roasting.

Corregir las cuentas expuestas al AS-REP roasting

Elimine el indicador y después restablezca la contraseña de todas las cuentas que lo tenían, porque puede que su AS-REP ya se haya recopilado:

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' |
    ForEach-Object { Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false }

Si una aplicación heredada lo requiere de verdad, documente la excepción, asigne a la cuenta una contraseña aleatoria de 25 caracteres o más y supervísela.

Detectar lo que queda

Directiva de auditoría

En los DC: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon > Audit Kerberos Service Ticket Operations y Audit Kerberos Authentication Service, aciertos y errores. Reenvíe los eventos 4768 y 4769 a su SIEM o a un recopilador central.

Lógica de detección

• Tickets de servicio RC4 para cuentas de usuario: evento 4769 con TicketEncryptionType 0x17 en el que el servicio es una cuenta de usuario, en un entorno donde AES es la norma. Muchas herramientas de roasting solicitan RC4 explícitamente.
• Volumen: una cuenta que solicita tickets de servicio para muchos SPN distintos en poco tiempo (por ejemplo, más de 10 en 5 minutos).
• AS-REP roasting: evento 4768 con PreAuthType 0.

# Clientes que han solicitado tickets RC4 para más de 10 servicios distintos en la última hora
$since = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4769; StartTime=$since } |
    ForEach-Object {
        $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        if ($d.TicketEncryptionType -eq '0x17' -and $d.ServiceName -notlike '*$') {
            [pscustomobject]@{ Client = $d.TargetUserName; Service = $d.ServiceName }
        }
    } | Group-Object Client | Where-Object { ($_.Group.Service | Sort-Object -Unique).Count -gt 10 }

Ajuste

Cuente con algo de ruido el primer día. Los escáneres de vulnerabilidades, las herramientas de gobierno de identidades y algunos productos de monitorización enumeran los SPN y solicitan tickets en bloque, y los clientes antiguos negocian legítimamente RC4 con cuentas que aún lo permiten. Cree una lista de permitidos con las direcciones de origen de los escáneres conocidos y las identidades de servicio, y revísela trimestralmente. La señal de RC4 se vuelve mucho más nítida una vez que las cuentas de servicio son solo AES: a partir de entonces, cualquier ticket RC4 para una cuenta de servicio basada en usuario es o bien un cliente heredado sin corregir, o bien una herramienta de roasting que solicita a propósito el tipo de cifrado más débil.

Honey SPN

Cree un honeytoken: una cuenta de usuario con un nombre y un SPN realistas, una contraseña larga y aleatoria, sin actividad de inicio de sesión y sin ningún servicio real detrás. Cualquier 4769 para ella es una alerta. Los detalles de diseño están en honeytokens y engaño.

New-ADUser -Name 'svc-sqlbackup-legacy' -SamAccountName 'svc-sqlbackup-legacy' `
    -Path 'OU=ServiceAccounts,DC=corp,DC=example,DC=com' -Enabled $true `
    -AccountPassword (Read-Host -AsSecureString 'Random 30+ char password') `
    -ServicePrincipalNames 'MSSQLSvc/sqlbackup01.corp.example.com:1433'

Verificar

• La consulta de inventario de SPN solo devuelve gMSA, cuentas de equipo y una lista corta y documentada de cuentas de usuario, cada una con una contraseña más reciente que su intervalo de rotación y msDS-SupportedEncryptionTypes establecido en 24.
• La consulta de DoesNotRequirePreAuth no devuelve nada, o solo excepciones documentadas.
• Ninguna cuenta de usuario con SPN es miembro de un grupo privilegiado.
• Una solicitud de ticket de prueba para el honey SPN (klist get MSSQLSvc/sqlbackup01.corp.example.com:1433 desde una estación de administración, anunciada al SOC) genera una alerta.

Qué rompe

• Eliminar SPN que todavía se usan rompe Kerberos hacia ese servicio; los clientes recurren a NTLM donde esté permitido, o fallan. Revise el historial de eventos 4769 antes de eliminarlos.
• Restablecer contraseñas de cuentas de servicio heredadas rompe todos los lugares donde la contraseña antigua está codificada: servicios, tareas programadas, archivos de configuración de aplicaciones, scripts en otros servidores.
• Solo AES en las cuentas de servicio rompe los clientes y keytabs que solo admiten RC4, en particular las integraciones antiguas de Java y Linux.
• La migración a gMSA no funciona para las aplicaciones que necesitan la contraseña en texto claro, ni para servicios en hosts fuera del dominio.
• Eliminar DONT_REQ_PREAUTH puede romper alguna rara integración heredada de Unix o de un dispositivo que dependía de ello.

Lecturas relacionadas: el área de Kerberos y autenticación y hardening de cuentas de servicio con gMSA y LAPS para el programa más amplio de cuentas de servicio.