During an internal assessment, a tester has valid domain credentials for a standard user and captures Kerberos traffic with Wireshark. The tester notices several TGS-REQ packets for service principal names ending in "/MSSQLSvc" across multiple hosts. The tester wants to identify which accounts are vulnerable to offline password cracking without triggering account lockouts. Which action should the tester take next?
Requesting TGS tickets for accounts with registered SPNs returns the service ticket encrypted with the target account's NTLM hash, which can be cracked offline without contacting the target service. Rubeus kerberoast automates this extraction and produces a hashcat-compatible format. The compromised user only needs a valid TGT, so no lockout risk is introduced against the service account.
Why this answer
Requesting service tickets for accounts with registered SPNs yields TGS material encrypted with the service account's key, enabling offline cracking without lockout risk. The captured TGS-REQ traffic for MSSQLSvc SPNs confirms kerberoastable targets. Tools like Rubeus automate extraction and output hashcat-compatible hashes, letting the tester verify weak service account passwords safely.
Exam trap
The trap here is confusing kerberoasting with interactive service authentication or AS-REP Roasting, when the observed TGS-REQ traffic points specifically to extracting TGS tickets for offline cracking.