SecurityLayer

6 - AS_REP_Roast

Este ataque ocurre durante las solicitudes KRB_AS_REQ y KRB_AS_REP, cuyos mensajes se compone de los siguientes elementos:

Durante este primer intercambio del protocolo Kerberos el cliente debe autenticarse ante el controlador de dominio para obtener un Ticket Granting Ticket (TGT). En este proceso, parte de la respuesta enviada por el KDC (el paquete KRB_AS_REP) se cifra utilizando una clave derivada de la contraseña del usuario solicitante (User secret Key). Este mecanismo garantiza que sólo quien conoce la contraseña pueda descifrar la respuesta y obtener la clave de sesión. Por este motivo, generalmente el cliente debe incluir en su solicitud (KRB_AS_REQ) un autenticador cifrado con su propia clave secreta (User secret Key), que el controlador de dominio verifica antes de emitir una respuesta válida, de esta forma si un atacante quisiera explotar un AS-REP-Roasting fallaria. Esto se ilustraría de la siguiente manera:

Sin embargo, si una cuenta de usuario está configurada con la opción "DONT_REQUIRE_PREAUTH", el KDC no exigirá ese autenticador previo, y directamente enviará un KRB_AS_REP sin validación. Esto abre la puerta al ataque conocido como AS-REP Roasting: un atacante que conozca el nombre de una cuenta sin pre autenticación puede solicitar un TGT para esa cuenta, y el KDC le responderá con un paquete cifrado con el hash derivado de la contraseña del usuario objetivo. El atacante puede entonces capturar ese paquete y realizar un ataque offline por fuerza bruta o diccionario para intentar recuperar la contraseña del usuario, sin necesidad de haber comprometido previamente ninguna cuenta en el dominio. Esta falla no es un error de Kerberos, sino una consecuencia de una configuración insegura que puede pasar desapercibida si no se auditan las cuentas con esta opción habilitada.

Ejemplo Practico 1

Para este escenario contamos con una lista de usuarios del Dominio (usernames.txt), y lo que vamos a hacer es implementar Kerbrute para verificar que cuentas requieren o no pre autenticación. En aquellas cuentas que tengan la flag DONT_REQ_PREAUTH kerbrute nos extraerá automáticamente parte del mensaje AS-REP que contiene la clave de sesión cifrada con la clave del usuario para crackearlo con JohnTheRipper

Este resultado nos está indicando que:

  • El usuario fsmith existe en el dominio.

  • No tiene habilitada la pre autenticación Kerberos, lo cual permite al atacante recibir un KRB_AS_REP del KDC sin necesidad de autenticarse.

  • La herramienta descarga el AS-REP cifrado con la clave secreta de fsmith (derivada de su contraseña) y lo guarda en formato crackeable (como lo hace Hashcat).

Ejemplo Practico 2

Otra herramienta que podemos implementar para obtener ese paquete cifrado por el KDC con la clave del usuario fsmith es impacket-GetNPUsers, de la siguiente manera:

📌Parámetros

  • EGOTISTICAL-BANK.LOCAL/fsmith: dominio y nombre de usuario objetivo.

  • -dc-ip 10.10.10.175: IP del Domain Controller (donde está corriendo el KDC).

  • -no-pass: indica que no se usará contraseña para autenticarse (clave en este ataque, ya que la cuenta no requiere preautenticación).

  • -format john: genera el hash en formato compatible con John the Ripper (para romperlo offline).

  • -outputfile hashes.txt: guarda los hashes extraídos en ese archivo.

Este comando interactúa directamente con el Authentication Server del KDC, solicitando un KRB_AS_REP para fsmith. Como fsmith no requiere pre autenticación, el KDC entrega el paquete con el bloque cifrado que se puede crackear. El hash extraído representa ese bloque, y es el que romperemos con JohnTheRipper de la siguiente manera:

Last updated