Lion Cipher Lab

Kerberoast service accounts and crack the tickets in your own AD lab

• Penetration Testing / Red Team
• Intermediate
• ~60 min
• Free · no account required

Why it matters

Kerberoasting is one of the most reliable privilege-escalation moves in the whole Active Directory playbook, and it is devastating precisely because it abuses Kerberos working exactly as designed. Active Directory uses Kerberos to authenticate users to services, and every account that runs a service -- a SQL Server, a web app pool, a backup agent -- can carry a Service Principal Name (SPN) that ties the service to that account. Here is the catch that makes the technique work: any authenticated domain user, however low-privileged, is allowed to ask a domain controller for a service ticket for…

What you'll learn

• explaining Kerberos, an SPN, a TGS and a TGS-REP in plain words, and why ANY authenticated domain user can request a service ticket for ANY SPN-bearing account
• understanding why part of a service ticket is encrypted with a key derived from the service account's PASSWORD, which is what makes the ticket crackable offline
• seeing why the crack is OFFLINE and STEALTHY: no traffic to the service, no failed logons, no account lockout -- the whole reason Kerberoasting is a first-choice technique once you hold any domain creds
• creating a domain service account in your OWN lab, registering an SPN with setspn -s, and DELIBERATELY giving it a weak password so you have something crackable to attack
• requesting and exporting crackable tickets from a low-privilege account with impacket's GetUserSPNs.py -request -outputfile, and reading the $krb5tgs$ hash format
• cracking the exported hash offline with hashcat -m 13100 against rockyou.txt and measuring how fast a weak service-account password falls
• the judgment: WHEN you reach for Kerberoasting (post-compromise escalation once you hold any domain creds), WHY it works (RC4/etype 23, offline crack), and how a pro targets high-value SPNs and works on a GPU offline
• hardening for real: a 25+ char random password or a Group Managed Service Account (gMSA) with a machine-managed 120-char password, removing unused SPNs, enforcing AES over RC4, and monitoring event 4769 -- then re-running the SAME crack to prove it no longer falls
• the honest negative: the request ALWAYS succeeds because it is by-design Kerberos, so the defence is password strength / gMSA / AES, never blocking the request

Steps in this lab

1. First: this is your lab, and Kerberoasting is a real domain-escalation technique
2. The words you need: Kerberos, KDC, TGT, SPN, TGS and TGS-REP
3. Why any user can do this, and why the crack is offline and silent
4. Set up the target: a service account with an SPN and a DELIBERATELY weak password
5. Request and export the tickets with impacket GetUserSPNs.py
6. Crack it offline with hashcat -- and measure how fast weak falls
7. Fix and re-measure: strong password or a gMSA, AES over RC4, remove dead SPNs, watch 4769
8. The honest negative, when to reach for it, and how a pro does it better

Open the full interactive lab →