Kerberoasting Under a Lockout Policy
You have a foothold on a workstation in the CORP.LOCAL domain with a standard user account, j.smith, obtained from a phishing simulation. The domain has 1,200 users and a password lockout policy of five attempts in 30 minutes. BloodHound shows that the service account svc_sql has an SPN of MSSQLSvc/sql01.corp.local:1433 and is a member of Domain Admins. You also find that WEB01 has unconstrained Kerberos delegation enabled and is a production intranet server that cannot be rebooted. The svc_sql password was last set three years ago and the account is not a group managed service account. The client's rules of engagement prohibit password spraying, any denial-of-service, and any change to production systems. You have 48 hours left.
1. How would you obtain and crack the Kerberoast hash for svc_sql without triggering lockout, and what should you confirm first?
Read the worked answer
Confirm three things first: svc_sql is in scope, the account is not a honeypot or a decoy that the client wants excluded, and the account is not a gMSA (already confirmed). Also check msDS-SupportedEncryptionTypes; if only AES is enabled, the crack is harder but still offline.
Kerberoasting does not require guessing a password and does not increment bad-password counters. As j.smith, request a service ticket for the SPN:
- Rubeus kerberoast /user:svc_sql /format:hashcat /outfile:svc_sql.hash
- Or Impacket GetUserSPNs.py CORP.LOCAL/j.smith -request -outputfile svc_sql.hash
Requesting a TGS generates a 4769 event but no lockout. Crack offline with hashcat -m 13100 for RC4 or -m 19700/19600 for AES. Do not attempt online authentication against svc_sql until you have the plaintext, and even then avoid interactive logons to production unless the ROE allows it. If the password cracks, use it for the minimum necessary proof and document the 4769 evidence.
2. What are the risks and prerequisites for abusing WEB01's unconstrained delegation, and what would you do given the constraints?
Read the worked answer
Unconstrained delegation means WEB01 can receive and cache a forwarded TGT for any user who authenticates to it. To abuse it, you need a privileged user to authenticate to WEB01, then you need administrative access to WEB01 to extract the cached ticket. Coercion techniques such as PetitPotam or PrinterBug can force a machine or user authentication, but they can disrupt production services, trigger authentication loops, or require changes to the server. The ROE prohibits DoS and changes to production, so coercion is not authorised by default.
Given the constraints, do not run coercion. Instead:
- Document the delegation configuration as a high-risk finding with the exact account and server.
- Check whether any Domain Admin sessions already exist on WEB01 through BloodHound or existing share/session data; if so, that is a lower-impact path, but extracting tickets still requires admin access.
- Ask the client in writing whether a controlled coercion test is permitted in a maintenance window; if yes, scope it narrowly and have rollback ready.
- Recommend removing unconstrained delegation, adding privileged accounts to Protected Users, and disabling protocol transition where possible.
A production outage is worse than an unexploited finding.
3. If the Kerberoast crack fails, what alternative path to Domain Admin would you pursue within the rules of engagement?
Read the worked answer
Stay with read-only or low-impact paths. Use BloodHound to look for ACL abuse (GenericAll, WriteDACL, ForceChangePassword), GPO control, local administrator reuse, and session hunting. Check ADCS for ESC1/ESC8-style misconfigurations, but do not request a certificate that grants DA unless the ROE permits it. Review MSSQL linked servers and service-account rights from svc_sql's group membership. Look for password reuse between j.smith's local admin rights and other hosts. Avoid password spraying entirely. If a path requires a change to production, stop and seek written approval. The goal is a defensible path, not a fast one.