AS-REP Roasting — Deteccion & Remediacion

¿Qué es el AS-REP Roasting?

El AS-REP Roasting es un ataque de Active Directory contra cuentas que tienen la preautenticación Kerberos deshabilitada.

Cuando el flag DONT_REQ_PREAUTH está habilitado en un usuario o en una cuenta de servicio, el KDC puede devolver una AS-REP sin exigir antes una prueba de que el solicitante conoce la contraseña. Un atacante que conoce o adivina un nombre de cuenta válido puede pedir esa respuesta, extraer la parte cifrada e intentar romperla offline.

Ese es el motivo por el que el ajuste es serio: convierte una cuenta de dominio en un objetivo de cracking de contraseña antes de que exista una autenticación correcta.

La diferencia operativa frente a Kerberoasting es clara:

Kerberoasting requiere una identidad de dominio válida para solicitar tickets de servicio.
AS-REP Roasting no requiere credenciales válidas para solicitar una AS-REP de una cuenta conocida.

Eso no significa que LDAP anónimo esté abierto por defecto. Microsoft deshabilitó las operaciones LDAP anónimas en controladores de dominio Active Directory por defecto desde Windows Server 2003, salvo operaciones limitadas como rootDSE y bind. La obtención de nombres de usuario es un problema distinto de la recolección de AS-REP.

Cómo cambia el intercambio Kerberos

En un intercambio Kerberos normal, el cliente envía una AS-REQ con datos de preautenticación, normalmente un timestamp cifrado. Ese es el paso que demuestra al KDC que el cliente conoce la contraseña de la cuenta.

Si DONT_REQ_PREAUTH está activado, el KDC omite esa validación y devuelve una AS-REP de inmediato. La parte cifrada de esa respuesta queda protegida con la clave Kerberos de largo plazo de la cuenta, derivada de la contraseña.

Para un lector técnico importan dos puntos:

el ataque funciona porque la respuesta cifrada se entrega antes de que la autenticación se complete
esa respuesta puede usarse para cracking offline, así que la longitud y la calidad de la contraseña cambian directamente el impacto

No conviene asumir que todas las cuentas roastables devolverán el mismo tipo de cifrado. En entornos Windows modernos es razonable esperar tipos AES en muchos casos; en entornos más antiguos aún puede aparecer RC4. El modelo correcto no es “RC4 por defecto”, sino “el material devuelto depende de la configuración Kerberos y de los tipos de cifrado permitidos en ese entorno”.

Qué necesita realmente un atacante

Para un intento exitoso de AS-REP Roasting bastan tres cosas:

Conectividad de red hacia un controlador de dominio que responda solicitudes Kerberos AS.
Nombres de cuenta candidatos.
Al menos una cuenta con DONT_REQ_PREAUTH habilitado.

Eso explica por qué la técnica es atractiva. El atacante no necesita comprometer primero una sesión Windows ni robar una primera cuenta antes de empezar a recolectar.

En la práctica, los nombres de usuario suelen salir de:

convenciones de correo y directorios públicos
un acceso previo de bajo privilegio al dominio
exportaciones, scripts o inventarios antiguos
enumeración AD autenticada con una cuenta de dominio común

LDAP anónimo es, por tanto, un error adicional, no un requisito del ataque.

La cadena de ataque

Paso 1 - Identificar cuentas roastables

Con acceso autenticado, esto se puede consultar directamente en AD:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Sin credenciales, un atacante aún puede probar nombres conocidos enviando solicitudes AS y observando qué cuentas devuelven material explotable.

Paso 2 - Solicitar respuestas AS-REP

# Solicitar AS-REP para una lista de nombres conocidos
impacket-GetNPUsers corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.0.1

Con una cuenta de dominio válida, la enumeración puede ser más directa:

impacket-GetNPUsers corp.local/user:password -request -dc-ip 10.10.0.1

En un host Windows, Rubeus hace lo mismo:

.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

Paso 3 - Crackear offline

A partir de ese punto, el controlador de dominio deja de importar. Los intentos de contraseña se realizan offline, a la velocidad del atacante.

Por eso las contraseñas antiguas de cuentas de servicio, las contraseñas creadas por humanos y las contraseñas que nunca expiran son especialmente peligrosas en este escenario.

Paso 4 - Usar la credencial recuperada

Si la contraseña se recupera, la cuenta puede utilizarse como cualquier otra identidad comprometida:

acceso interactivo si está permitido
LDAP y PowerShell para ampliar la visibilidad
movimiento lateral hacia sistemas donde la cuenta tenga permisos locales o delegados
escalada si la cuenta está ligada a grupos privilegiados, servicios, tareas planificadas o aplicaciones críticas

Una sola excepción creada para una aplicación legacy puede convertirse así en el primer paso de una ruta de identidad mucho mayor.

Detección

El mejor punto de detección sigue siendo el controlador de dominio.

Event 4768 es la señal principal

La documentación de Microsoft para Event ID 4768 hace especialmente útiles dos campos:

Pre-Authentication Type = 0 significa que la solicitud de TGT ocurrió sin preautenticación Kerberos.
Ticket Encryption Type muestra qué tipo de cifrado Kerberos se usó realmente.

Para AS-REP Roasting, el indicador que debe priorizarse es un 4768 con Pre-Authentication Type 0.

Patrones prácticos de hunting

Empieza por estos casos:

eventos 4768 repetidos con Pre-Authentication Type = 0
ráfagas de solicitudes desde una misma IP contra múltiples cuentas
solicitudes dirigidas a cuentas de servicio o admin que no deberían autenticarse de forma interactiva
picos de 4768 Result Code 0x6, que pueden indicar adivinación de usuarios antes de las solicitudes válidas
cambios de cuenta que activan DONT_REQ_PREAUTH, sobre todo en identidades de servicio o con privilegios

Ejemplo de consulta SIEM

event.code: "4768" AND
winlog.event_data.PreAuthType: "0" AND
winlog.event_data.Status: "0x0"

Si el auditor de cambios del directorio está habilitado, conviene revisar también las modificaciones que cambian el bit de userAccountControl correspondiente. Muchas veces ahí se detecta la excepción peligrosa antes de que se explote.

Remediación

1. Eliminar excepciones de preautenticación no justificadas

Set-ADAccountControl -Identity vulnerable_user -DoesNotRequirePreAuth $false

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

Ese es el arreglo principal. Si una cuenta no necesita la excepción por una razón técnica demostrable, no debería conservarla.

2. Rotar contraseñas después del cambio

No basta con volver a habilitar la preautenticación. Si la cuenta era roastable, hay que asumir que el material pudo haber sido recogido antes de la corrección.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
    Set-ADUser -ChangePasswordAtLogon $true

En cuentas de servicio, lo correcto es una rotación real del secreto, no solo un cambio de flag.

3. Revisar dependencias legacy

Si un equipo afirma que la cuenta debe seguir sin preautenticación, exige una revisión técnica:

qué sistema depende realmente de ello
si ese sistema puede modernizarse o aislarse
si la cuenta puede bajarse a privilegio mínimo
si pueden retirarse el logon interactivo, la delegación o pertenencias amplias a grupos

Una excepción de preauth sobre una cuenta privilegiada o muy reutilizada no es una pequeña concesión de compatibilidad. Es una exposición offline de contraseña.

4. Endurecer las cuentas que temporalmente deban seguir en excepción

Si una excepción debe mantenerse por un tiempo:

imponer una contraseña larga y aleatoria
retirar pertenencias privilegiadas donde sea posible
restringir derechos de inicio de sesión
monitorizar específicamente el 4768 de esa cuenta
definir owner y fecha de revisión

5. No confiar en ocultar nombres de usuario

Aunque LDAP anónimo esté deshabilitado, hay que asumir que un atacante puede construir listas de usuarios igualmente. El control duradero es eliminar cuentas roastables y reducir el valor de cualquier excepción que deba mantenerse.

Validación después del fix

Un cierre profesional de AS-REP Roasting se apoya en cuatro comprobaciones:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} devuelve solo excepciones documentadas.
Las contraseñas de las cuentas previamente expuestas fueron rotadas.
Los 4768 con Pre-Authentication Type = 0 desaparecieron para usuarios y cuentas de servicio ordinarias.
Toda excepción restante tiene owner, justificación de negocio, controles compensatorios y fecha de revisión.

Si no puedes demostrar esos cuatro puntos, el problema no está realmente cerrado.

Comprobación extra que vale la pena conservar

Conviene revisar también cada excepción residual junto con el inventario de servicios: SPN asociado, password last set, grupos a los que pertenece y sistema que sigue dependiendo de ella. Esa comprobación evita que una cuenta vieja de servicio siga roastable solo porque nadie quiso decidir si la aplicación seguía viva o no.

Errores frecuentes del lado defensor

Los errores recurrentes suelen ser los mismos:

asumir que LDAP anónimo es requisito del ataque
reactivar la preautenticación pero no rotar la contraseña
dejar la excepción en cuentas de servicio antiguas con privilegios amplios
tratar el ajuste como inocuo porque la cuenta “no es interactiva”
corregir una cuenta visible sin corregir el proceso de provisioning que creó la excepción

Para un lector técnico, la clave no es la complejidad del exploit. La clave es la cantidad de privilegio acumulado por la cuenta expuesta.

Referencias primarias

Cómo EtcSec detecta esto

EtcSec marca las cuentas con preautenticación Kerberos deshabilitada en cada auditoría AD.

El hallazgo principal es ASREP_ROASTING_RISK: cualquier cuenta con DONT_REQ_PREAUTH habilitado es candidata a exposición de contraseña.

Hallazgos relacionados que cambian la gravedad real:

PASSWORD_NEVER_EXPIRES
PASSWORD_POLICY_WEAK
WEAK_KERBEROS_POLICY

La combinación importa más que el flag aislado. Una cuenta roastable con una contraseña débil, antigua o que nunca expira es mucho más peligrosa que una excepción temporal controlada.

AS-REP Roasting: Recopilando Hashes Sin Credenciales