Listen to this Post
Introduction:
Kerberoasting is a pervasive attack technique targeting Microsoft’s Kerberos authentication protocol in Active Directory environments. By exploiting the very tickets designed for secure service access, attackers can offline-crack service account passwords, often leading to significant domain compromise. This article deconstructs the attack from both offensive and defensive perspectives, providing the commands and knowledge needed to understand, simulate, and defend against it.
Learning Objectives:
- Understand the core components of the Kerberos protocol and the role of Service Principal Names (SPNs).
- Learn the step-by-step process of performing a Kerberoasting attack using common security tools.
- Implement effective detection and mitigation strategies to protect your Active Directory environment.
You Should Know:
1. Kerberos Authentication in a Nutshell
The Kerberos protocol is the cornerstone of authentication in Active Directory. It relies on a Key Distribution Center (KDC), which consists of the Authentication Service (AS) and the Ticket-Granting Service (TGS). The flow begins when a user requests a Ticket-Granting Ticket (TGT) from the AS. This TGT, encrypted with the KRBTGT account’s password hash, is used to request service-specific tickets from the TGS.
Command: `klist` (Windows)
This native Windows command displays currently cached Kerberos tickets.
C:> klist
Step-by-Step Guide: Simply open a command prompt and type klist. It will show you all the TGTs and service tickets cached for your current logon session. This is useful for verifying that authentication is working as expected and for basic troubleshooting. The output includes the server name, client name, session key type, and ticket expiration time.
- The Critical Role of Service Principal Names (SPNs)
An SPN is a unique identifier for a service instance, linking a service to a domain user account (the service account). When a client wants to access a service like SQL Server or a web application, it uses the SPN to request a service ticket from the KDC. Kerberoasting preys on services that use SPNs registered to user accounts (as opposed to computer accounts), as these passwords are often weaker and changed less frequently.
Command: `setspn` (Windows)
This command is used to query, register, or delete SPNs in Active Directory.
C:> setspn -Q / Query all SPNs in the domain (requires domain admin) C:> setspn -L DOMAIN\sqlserviceaccount List SPNs for a specific user account
Step-by-Step Guide: To discover services potentially vulnerable to Kerberoasting, an attacker (or auditor) would first need to enumerate all SPNs in the domain. The command `setspn -Q /` performs a broad query. A more targeted approach is to list SPNs for known service accounts using setspn -L <accountname>. The output reveals the services running under those accounts.
- The Kerberoasting Attack: Step 1 – Requesting a Service Ticket
The attack begins once an attacker has initial foothold in the domain (even as a low-privileged user). They request a Ticket-Granting Service (TGS) ticket for a service with a registered SPN. Crucially, the TGS-REP (reply) from the KDC contains a section encrypted with the password hash of the service account associated with the SPN. This is the core of the vulnerability.
Command: `Add-Type` in PowerShell (Windows)
To perform this step programmatically in PowerShell, we need to load the necessary .NET classes.
PS C:> Add-Type -AssemblyName System.IdentityModel
Step-by-Step Guide: This command is a prerequisite for using the `System.IdentityModel` namespace directly in PowerShell to craft Kerberos requests. It’s the first step in a manual Kerberos ticket request process, setting the stage for the actual ticket retrieval.
- The Kerberoasting Attack: Step 2 – Extracting the Exploitable Ticket
After requesting the TGS ticket, the attacker extracts it from memory. This ticket, still encrypted with the service account’s hash, is saved to a file. The key point is that any domain user can request these tickets for any SPN, and the encrypted part can be extracted for offline cracking.
Tool: `Rubeus.exe` (Windows)
Rubeus is a powerful offensive tool for raw Kerberos interaction and abuse.
C:> Rubeus.exe kerberoast /simple /outfile:hashes.txt
Step-by-Step Guide: Rubeus automates the entire Kerberoasting process. The `kerberoast` command finds user accounts with SPNs, requests TGS tickets for them, and extracts the encrypted parts into a format ready for cracking (like Hashcat mode 13100). The `/simple` flag filters for accounts that may have simpler passwords. The extracted hashes are saved to hashes.txt.
5. Cracking the Service Password Offline
The attacker transfers the extracted hash file to a powerful cracking machine. Using tools like Hashcat or John the Ripper, they attempt to crack the service account’s password. The success of this step depends entirely on the password’s strength.
Command: `hashcat` (Linux)
Hashcat is a high-speed password recovery tool.
$ hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt -O -w 3
Step-by-Step Guide: This command tells Hashcat to crack Kerberos 5 TGS-REP etype 23 hashes (mode -m 13100) found in `hashes.txt` using the `rockyou.txt` wordlist. The `-O` flag enables optimized kernels, and `-w 3` sets the workload profile to high for faster cracking. If the service account uses a weak password, it will be revealed in seconds or minutes.
6. Blue Team Detection: Monitoring for Kerberoasting Activity
Defenders can detect Kerberoasting by monitoring Windows Security Event Logs for specific patterns. A key indicator is a surge in TGS requests from a single account in a short period, especially if the requests are for diverse SPNs.
Event ID: 4769 (A Kerberos service ticket was requested)
The critical fields to monitor within Event ID 4769 are:
Account Name: The user making the request.
Service Name: The SPN being targeted.
Ticket Encryption Type: Attackers often request RC4 encryption (etype 0x17) if supported, as it’s faster to crack.
Result Code: A code of `0x0` indicates a successful ticket request.
Query (Splunk/Sentinel Example):
index=windows EventCode=4769 | stats count by Account_Name, Service_Name | where count > 10
Step-by-Step Guide: This Splunk-like query aggregates Event ID 4769 and counts how many times each user account has requested tickets for each service. The `where count > 10` filter highlights accounts that have made an excessive number of requests, which is a strong indicator of Kerberoasting. Correlating this with requests for RC4 encryption increases confidence in the alert.
- Primary Mitigation: Use Group Managed Service Accounts (gMSAs)
The most effective mitigation is to stop using standard user accounts for services. Group Managed Service Accounts (gMSAs) provide automatic password management, with long, complex, and frequently rotated passwords that are nearly impossible to crack offline.
PowerShell Command: `New-ADServiceAccount`
This command creates a new gMSA in Active Directory.
PS C:> New-ADServiceAccount -Name "myWebService" -DNSHostName "webserver01.domain.com" -PrincipalsAllowedToRetrieveManagedPassword "WEB_SERVERS$"
Step-by-Step Guide: This creates a gMSA named myWebService. The `-PrincipalsAllowedToRetrieveManagedPassword` parameter specifies which computer accounts (e.g., a security group containing web servers) are allowed to retrieve the password for this account. Once created, you configure your service (e.g., IIS Application Pool) to run under this gMSA instead of a standard user account.
What Undercode Say:
- The Attack is a Permission Issue, Not a Flaw: Kerberoasting is not a vulnerability in the Kerberos protocol itself but a legitimate feature being abused. The protocol correctly provides a service ticket encrypted with the service’s secret. The problem lies in the combination of weak service account passwords and the ability of any authenticated user to trigger this process.
- Detection Over Absolute Prevention: While gMSAs are the gold standard for mitigation, legacy applications often prevent their immediate adoption. Therefore, a robust detection strategy based on Event ID 4769 analysis is critical for most organizations. Layering this with a policy to enforce strong, unique passwords for all service accounts provides a strong defense-in-depth posture.
Prediction:
Kerberoasting will remain a staple of AD attacks for the foreseeable future due to the vast number of legacy systems and applications that rely on traditional service accounts. However, the increasing adoption of gMSAs and cloud-based identities (like Azure AD Managed Identities) will slowly shrink the attack surface. The future of this technique lies in more sophisticated detection evasion, such as “slow-roasting” where attackers spread ticket requests over weeks or months to avoid triggering threshold-based alerts. This will push defenders towards more advanced behavioral analytics and machine learning models to identify low-and-slow attack patterns.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Omar Moamen – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
