Active Directory Pentest: Step-by-Step Kerberoasting in a GOAD Lab

Kerberoasting is the attack that pays rent on almost every internal engagement, because it needs nothing more than a single valid domain account and turns quietly requested service tickets into offline password cracking with no special privileges and no noisy exploit. In this walkthrough you build a lab with GOAD, the Game of Active Directory by Orange Cyberdefense, and run the full chain: understand how Kerberos issues tickets, enumerate service principal names, request the tickets, crack them offline with hashcat, and then close the loop with the detection and hardening that actually stops it. Everything runs against your own domain controllers, in an isolated network, under written authorization; the goal is fluency in the mechanism, not a trophy.

How Kerberos authentication works

Kerberos is a ticket protocol with three parties: the client, the Key Distribution Center that lives on the domain controller, and the service. First the client proves who it is with an AS-REQ and receives a Ticket Granting Ticket, encrypted with the krbtgt account key so only the KDC can read it. When the client wants to reach a service, it presents the TGT in a TGS-REQ and asks for a service ticket; the KDC responds with a TGS encrypted using the service account's own key, which is derived from that account's password. The client hands that ticket to the service, which decrypts it to prove the client is authorized. The critical detail is that the KDC will hand any authenticated user a service ticket for any service, and that ticket is encrypted with a key derived from a human-chosen password.

Why Kerberoasting works

That one design fact is the whole vulnerability. Any domain user can request a TGS for any account that has a Service Principal Name registered, and the returned ticket is encrypted with the service account's password-derived key. Take the ticket offline and you can brute-force the password without ever touching the domain again, because verification happens on your own hardware. It gets worse when the ticket comes back as RC4 (etype 23, the $krb5tgs$23$ hash), which cracks far faster than AES. Service accounts are the perfect victims: they often carry weak, ancient, human-set passwords, they rarely rotate, and they are frequently over-privileged because someone granted them domain admin years ago to make an installer work.

Building the GOAD lab

GOAD ships a deliberately vulnerable multi-domain Active Directory forest built for exactly this practice. Provision it with Ludus or with the Vagrant and Ansible path on a hypervisor with enough RAM, since a realistic forest wants several Windows Server virtual machines and a Kali or Windows attack host. Keep the whole environment on an isolated network with no route to production or the internet, because GOAD is intentionally weak and must never touch anything real. Once the domain controllers are up and you hold one low-privilege domain account, you have the exact starting position of an attacker who just phished a single helpdesk user, which is the realistic entry point Kerberoasting is designed to exploit.

Enumeration: finding the service accounts

You cannot roast what you cannot see, so first enumerate accounts that carry an SPN. From Windows, setspn -T domain -Q */* lists registered service principal names, while PowerView's Get-DomainUser -SPN filters straight to user accounts with an SPN set, which are the crackable targets. From Linux, an authenticated ldapsearch for servicePrincipalName=* does the same. Feed the domain into BloodHound and it will not only list Kerberoastable users but show which of them are members of high-value groups, so you can prioritize the service account that also happens to sit in Domain Admins. Note the encryption types each account supports; an account still allowing RC4 is the softest target on the board.

Requesting and extracting the tickets

With targets chosen, request the tickets. From a Windows foothold, Rubeus.exe kerberoast /outfile:hashes.txt requests a TGS for every Kerberoastable account and writes the hashes in a crackable format; add /tgtdeleg or filter by user to stay quiet. From Linux with Impacket, GetUserSPNs.py DOMAIN/user:password -dc-ip 10.0.0.10 -request does the same in one command and dumps the $krb5tgs$ blobs. If you can, deliberately target accounts that respond with RC4 hashes; if the KDC returns AES etype 18 ($krb5tgs$18$), you can still crack it, just far more slowly. Every hash you collect is now completely detached from the network, which is exactly why the next step happens on your own machine.

Cracking the tickets offline

Offline is where Kerberoasting turns cruel. Feed the hashes to hashcat with mode -m 13100 for RC4 TGS tickets or -m 19700 for AES, point it at a strong wordlist such as rockyou plus targeted rules, and let the GPU work. A weak service password falls in seconds; a twelve-character human password with predictable structure often falls in hours. Because verification is local, there is no lockout, no rate limit, and no log entry on the domain to give you away. This asymmetry is the entire point: the defender's password policy is the only thing standing between a single low-privilege account and a cracked service credential that may hold far more access than the account you started with.

Post-crack: turning a password into domain power

A cracked service account is rarely the end; it is a pivot. Log in as the service account and re-run BloodHound from its context to map what it can reach, because service accounts routinely hold local admin on many servers or sit inside privileged groups. If the account is a SQL or backup service, it may own paths to a domain controller through delegation or DACL abuse. This is why Kerberoasting is so valued on real engagements: it converts the weakest possible starting position, one ordinary user, into credentials that were provisioned for machines and therefore trusted far more than any human account should be.

Detection: the defender's view

Every Kerberoast leaves a trace if you are watching for it. Windows Event ID 4769 records each TGS request, and the tell is the encryption type field: a burst of 4769 events with encryption type 0x17 (RC4) from a single user against many distinct services in a short window is the signature of a roasting run. Alert on that pattern in your SIEM rather than on individual events, since one 4769 is normal and a thousand in a minute is not. The strongest single detection is a honeypot SPN: create a decoy service account with an SPN, never use it for anything, and fire a high-severity alert the instant anyone requests its ticket, because no legitimate process ever will.

Mitigation and hardening

The fix targets the crackability, not the request. Replace human-managed service accounts with group Managed Service Accounts, whose 240-character machine-generated passwords rotate automatically and are effectively impossible to crack offline. Where a gMSA is not yet possible, enforce a very long, random password on every service account and rotate it. Disable RC4 across the domain so tickets come back as AES only, which raises the cracking cost by orders of magnitude, and audit every service account for unnecessary privilege so that even a cracked credential leads nowhere. Layer the honeypot SPN and the 4769 detection on top, and you have shrunk both the odds of a successful crack and the blast radius if one happens.

Pitfalls and a checklist

The common mistakes cut both ways. Attackers get caught requesting every ticket at once instead of pacing and targeting, or they waste days cracking an AES hash they could have skipped for an RC4 one. Defenders assume they are safe because they enforced a password policy on users while their service accounts still carry a decade-old password and RC4 enabled. Before you call the domain hardened, confirm that no user account allows RC4, that every service account is a gMSA or holds a long random password, that a honeypot SPN exists and alerts, that 4769 anomaly detection is live, and that no Kerberoastable account sits in a privileged group. Prove it by roasting your own domain and watching the honeypot fire.

A close cousin: AS-REP roasting

Once Kerberoasting clicks, its sibling costs almost nothing to add. AS-REP roasting targets accounts that have Kerberos pre-authentication disabled, a setting that lets the KDC return an AS-REP encrypted with the user's own password-derived key before the user has proven anything. That means you can request the blob for such an account without any credentials at all and crack it offline exactly like a TGS. Enumerate the victims with Get-DomainUser -PreauthNotRequired in PowerView or GetNPUsers.py in Impacket, then feed the resulting $krb5asrep$ hash to hashcat mode -m 18200. The defensive story is identical in spirit: never disable pre-authentication, enforce strong passwords, and alert on the anomalous request. Running both attacks back to back in GOAD teaches you that the whole family of roasting bugs comes down to the same root, an encryption key derived from a weak human password that anyone is allowed to ask for.

FAQ

Do I need admin rights to Kerberoast? No, and that is exactly what makes it dangerous. Any single authenticated domain account can request service tickets and take them offline; no elevation, no exploit, and no special access is required, which is why it is one of the first moves after any foothold.

Does enabling AES stop Kerberoasting entirely? No, it makes it much harder, not impossible. AES tickets can still be requested and cracked, just far more slowly, so a weak service password remains vulnerable even under AES. The durable fix is gMSA passwords that no wordlist will ever reach, combined with least privilege so a crack yields nothing.

Practical takeaway: stand up GOAD, run the chain once from a single low-privilege account to a cracked service ticket to a privileged pivot, then flip to the blue side and build the honeypot SPN and the 4769 detection until your own roast lights them up. Kerberoasting is not an exotic technique; it is a design consequence of Kerberos meeting weak service passwords. Rotate to gMSA, kill RC4, strip privilege, and watch for the request, and you turn a reliable attacker payday into a dead end.