Active Directory AS-REP Roasting Cuentas de Servicio Privilegiadas: Las Cuentas Que la Preautenticación Debía Proteger

Active Directory AS-REP roasting de cuentas de servicio privilegiadas es el caso de mayor riesgo que cubre este artículo: cuentas Kerberos con la preautenticación deshabilitada que además forman parte de un grupo privilegiado o funcionan como cuenta de servicio, no un usuario estándar cualquiera.

Active Directory AS-REP Roasting de Cuentas de Servicio Privilegiadas

El catálogo de EtcSec rastrea el caso de las cuentas privilegiadas por separado como ADMIN_ASREP_ROASTABLE (Crítico), porque una cuenta que ya pertenece a Domain Admins, Enterprise Admins u otro grupo Tier 0 con este indicador activado convierte el AS-REP roasting en una carrera de cracking offline directa hacia el DA, no en una cadena de movimiento lateral de varios pasos. Para la versión general de este ataque aplicable a cualquier cuenta, consulta AS-REP Roasting: recopilando hashes sin credenciales — este artículo tiene un alcance más reducido, centrado en el clúster de cuentas privilegiadas y de servicio que aquel artículo no cubre.

El indicador subyacente es DONT_REQ_PREAUTH (0x400000 / decimal 4194304) en el atributo userAccountControl (Microsoft Learn: UserAccountControl property flags). Cuando está activado, cualquier cliente puede solicitar una respuesta Kerberos Authentication Server (AS-REP) para esa cuenta, y la respuesta vuelve con una parte cifrada usando una clave derivada de la contraseña de la cuenta — sin que el cliente tenga que demostrar en ningún momento que conoce esa contraseña. MITRE ATT&CK T1558.004 registra esto como «Steal or Forge Kerberos Tickets: AS-REP Roasting».

La mayoría de los artículos genéricos tratan esto como una medida de higiene única para todas las cuentas de usuario. Ese enfoque pasa por alto por qué dos clústeres específicos importan más:

• Cuentas privilegiadas sin preautenticación (ADMIN_ASREP_ROASTABLE, Crítico) — pertenencia a un grupo Tier 0 combinada con un hash roastable.
• Cuentas de servicio con el clúster de errores de configuración adyacente — sin preautenticación (SERVICE_ACCOUNT_NO_PREAUTH), inicio de sesión interactivo permitido (SERVICE_ACCOUNT_INTERACTIVE), y una contraseña que no ha rotado en más de un año (SERVICE_ACCOUNT_OLD_PASSWORD). Cada uno es de severidad Alta por separado; juntos significan que el hash es fácil de obtener y, una vez crackeado, sigue siendo válido durante mucho tiempo en una cuenta que también puede usarse indebidamente para acceso interactivo.

Por qué el indicador termina activado en cuentas reales

DONT_REQ_PREAUTH rara vez se activa con malicia — normalmente es un resto de una necesidad de compatibilidad específica que nunca se limpió. Las causas documentadas incluyen las migraciones de SIDHistory entre dominios, donde algunas soluciones de terceros de VPN o federación no logran completar la preautenticación Kerberos para identidades migradas a menos que el indicador se desactive temporalmente durante la transición (Quest support KB 4313059), y la compatibilidad con aplicaciones o dispositivos heredados, donde una biblioteca cliente Kerberos antigua no puede manejar la preautenticación en absoluto (Tenable: How to Stop the Kerberos Pre-Authentication Attack; JumpCloud: What Is Kerberos Pre-Authentication?). La migración o el dispositivo heredado terminan dados de baja; el indicador permanece activado en la cuenta indefinidamente porque nadie vuelve a revisarlo.

Cómo funciona

La preautenticación Kerberos existe precisamente para detener esta clase de ataque: el cliente debe cifrar una marca de tiempo con una clave derivada de su contraseña y enviarla en el AS-REQ antes de que el KDC emita nada. Sin ese requisito, la secuencia se reduce a cuatro pasos: el atacante envía un AS-REQ para el nombre de usuario objetivo sin contraseña y sin autenticación previa al dominio, siempre que la cuenta sea enumerable (LDAP, RPC, o una lista de nombres de usuario filtrada); el KDC responde inmediatamente con un AS-REP porque no se requiere preautenticación; parte de ese AS-REP está cifrada con una clave derivada de la contraseña de la cuenta; y el atacante crackea esa parte offline, sin ningún registro por parte del dominio de los intentos de contraseña fallidos, ya que cada intento ocurre en el hardware del atacante, no contra el DC.

La velocidad de cracking depende del tipo de cifrado Kerberos negociado. Si la cuenta todavía permite RC4 (etype 23), el atacante solicita RC4, y el modo hashcat 18200 ($krb5asrep$23$...) lo crackea órdenes de magnitud más rápido que una respuesta AES-256 (etype 18). Vale la pena cerrar el fallback a RC4 al mismo tiempo — consulta Kerberos RC4 Fallback in Active Directory para esa ruta de detección y eliminación.

La cadena de ataque

El AS-REP roasting rara vez aparece aislado en un compromiso real. Un walkthrough publicado del laboratorio ShadowGate de Hack Smarter Labs — «ShadowGate Active Directory Lab Walkthrough» por incoggeek — describe una cadena que comienza con enumeración SMB anónima, pasa al AS-REP roasting como primer paso autenticado, y luego gira hacia abuso de ACL mapeado con BloodHound (un permiso GenericWrite explotado vía Shadow Credentials) y ataques de inscripción de AD CS (ESC8, mediante autenticación forzada por PetitPotam hacia el endpoint web de inscripción de la CA) en el camino hacia un certificado de controlador de dominio. El AS-REP roasting es lo que convierte un punto de apoyo totalmente no autenticado en el primer secreto crackeable de esa cadena — la misma razón por la que Active Directory Attack Paths to Domain Admin trata un paso temprano de roasting Kerberos como una arista pivote, y exactamente por qué un hallazgo ADMIN_ASREP_ROASTABLE en una cuenta Tier 0 se puntúa como Crítico en lugar de tratarse como higiene rutinaria.

Paso 1 — Enumerar y solicitar

# Impacket -- enumera cada cuenta de usersfile.txt con la preautenticación deshabilitada
# y extrae hashes AS-REP crackeables sin ninguna credencial de dominio válida
impacket-GetNPUsers CORP.LOCAL/ -no-pass -usersfile usersfile.txt -format hashcat -outputfile asrep_hashes.txt

Paso 2 — Crackear offline

# Crackear offline los hashes $krb5asrep$23$... resultantes (modo 18200 = Kerberos 5, AS-REP, etype 23)
hashcat -m 18200 asrep_hashes.txt rockyou.txt

Detección

La señal de mayor confianza es el Event ID 4768 de Windows Security (solicitud de ticket de autenticación Kerberos) con Pre-Authentication Type 0, que solo ocurre legítimamente cuando la cuenta objetivo tiene la preautenticación deshabilitada (MITRE ATT&CK Detection Strategy DET0113; HackTheBox: AS-REP roasting detection). Combínalo con el tipo de cifrado negociado: 0x17 (RC4) junto con Pre-Auth Type 0 es el indicador combinado más fuerte, ya que un atacante degrada deliberadamente a RC4 para acelerar el cracking offline. Para la base más amplia de política de auditoría e ID de eventos sobre la que se apoya esta detección, consulta Active Directory Monitoring: Security Event IDs That Matter.

Dos consultas de PowerShell cubren directamente los detectores de este clúster:

# Cuentas privilegiadas con preautenticación deshabilitada (candidatas a ADMIN_ASREP_ROASTABLE)
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (adminCount -eq 1)} `
    -Properties userAccountControl, adminCount, ServicePrincipalName, MemberOf |
    Select-Object Name, DistinguishedName, ServicePrincipalName

# Cuentas de servicio (con SPN) con preautenticación deshabilitada, más la antigüedad de la contraseña
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (ServicePrincipalName -like '*')} `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate |
    Select-Object Name, ServicePrincipalName, PasswordLastSet,
        @{N='PasswordAgeDays';E={(New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days}}

SERVICE_ACCOUNT_INTERACTIVE no es un indicador de userAccountControl — es un hallazgo de comportamiento. Confírmalo correlacionando el sAMAccountName de la cuenta de servicio con eventos 4624 con Logon Type 2 (Interactive) o 10 (RemoteInteractive/RDP). Una cuenta de servicio genuina solo debería mostrar Logon Type 3 (Network) o 5 (Service).

Remediación

Para cuentas privilegiadas

Desactiva el indicador: desmarca «No requerir preautenticación Kerberos» en la pestaña Cuenta de la cuenta, o ejecuta Set-ADAccountControl -Identity <account> -DoesNotRequirePreAuth $false. Vuelve a ejecutar la consulta de detección anterior y confirma que devuelve cero filas. Si la cuenta fue marcada por una migración de SIDHistory pasada o una transición de federación, confirma que esa migración está completamente terminada — incluida la limpieza de SIDHistory — antes de reactivar la preautenticación, para que no rompa una dependencia todavía activa.

Para cuentas de servicio

1. Migra las cuentas de servicio roastables a gMSA. Las Group Managed Service Accounts rotan automáticamente una contraseña de 120 caracteres y, por diseño, no pueden usarse para inicio de sesión interactivo, cerrando SERVICE_ACCOUNT_OLD_PASSWORD y SERVICE_ACCOUNT_INTERACTIVE en el mismo movimiento. Consulta gMSA Password Exposure in Active Directory para conocer las salvedades sobre quién todavía puede leer la contraseña de un gMSA una vez desplegado.
2. Restringe explícitamente el inicio de sesión interactivo. Donde una cuenta todavía no pueda migrar a gMSA, aplica «Denegar inicio de sesión local» y «Denegar inicio de sesión a través de Servicios de Escritorio remoto» mediante una GPO limitada a la OU de la cuenta de servicio, y restringe «Iniciar sesión como servicio» a los hosts que realmente lo necesitan.
3. Rota la contraseña y exige Kerberos AES. Establece ahora una contraseña fuerte y única, y coloca la cuenta bajo una política de contraseñas o una Fine-Grained Password Policy que realmente imponga la rotación en lugar de dejarla estática durante un año o más. Por separado, exige AES en lugar de RC4 mediante «Seguridad de red: configurar tipos de cifrado permitidos para Kerberos» — esto no corrige la falta de exigencia de preautenticación, pero eleva el coste de cracking de cada ticket que la cuenta negocia legítimamente.
4. No recurras a Protected Users como solución. El grupo de seguridad Protected Users es el control correcto para cuentas privilegiadas humanas, pero Microsoft desaconseja explícitamente añadir cuentas de servicio o de equipo: la pertenencia bloquea el almacenamiento en caché de credenciales, por lo que una cuenta de servicio que no pueda alcanzar un DC ni siquiera brevemente fallará por completo. La pertenencia tampoco elimina el indicador DONT_REQ_PREAUTH — una cuenta de servicio que permanezca en el grupo con ese indicador todavía activado sigue siendo exactamente igual de roastable que antes. Consulta Active Directory Privileged Accounts: Protected Users, Delegation, and Service Account Gaps para saber dónde se aplica este grupo y dónde no.

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec verifica este clúster directamente: ADMIN_ASREP_ROASTABLE marca a los miembros de grupos privilegiados con la preautenticación Kerberos deshabilitada, SERVICE_ACCOUNT_NO_PREAUTH cubre el mismo indicador en cualquier cuenta de servicio con SPN, SERVICE_ACCOUNT_INTERACTIVE marca las cuentas de servicio observadas o configuradas para inicio de sesión interactivo, y SERVICE_ACCOUNT_OLD_PASSWORD marca las cuentas de servicio cuya contraseña no ha rotado dentro de la política. Ninguno de estos requiere una simulación de ataque en vivo — son verificaciones de atributos LDAP y de comportamiento de inicio de sesión que se ejecutan en cada pasada de auditoría.