Kerberoasting is one of the most effective post-exploitation techniques used against Active Directory environments, allowing an attacker to extract service account password hashes entirely offline — without generating excessive noise or requiring special privileges. If your organization runs Windows Active Directory with service accounts that have Service Principal Names (SPNs) registered, you are likely vulnerable. This guide covers the full attack methodology, detection strategies, and hardening measures every security team should implement.
How Kerberos Service Authentication Works
To understand kerberoasting, you need to understand how Kerberos service ticket issuance works. When a domain-joined host authenticates to a service (say, a SQL Server), the Kerberos Key Distribution Center (KDC) on the domain controller issues a Ticket Granting Service (TGS) ticket. This ticket is encrypted with the NTLM hash of the service account's password — not with any session key specific to the requesting user.
This design decision, baked into the Kerberos protocol, creates a critical security property: any authenticated domain user can request a TGS ticket for any registered SPN, regardless of whether they have permission to access the underlying service. The KDC will happily issue the ticket. The attacker then takes that ticket offline and cracks it at their leisure.
Attack Methodology: Step by Step
Step 1: Authenticate to the Domain
Kerberoasting requires only a valid domain user account — no elevated privileges. In a penetration test, this often comes from a phishing compromise, a password spray, or a leaked credential found in a code repository. From any domain-joined machine or from a Linux host with network access to the DC, the attack proceeds identically.
Step 2: Enumerate Service Principal Names
The attacker first identifies which accounts have SPNs registered. On Windows, the built-in setspn utility can list all SPNs in the domain:
setspn -T CORP -Q */*
This returns every SPN registered in the domain, including the account it belongs to. From a Linux host, the Impacket toolkit's GetUserSPNs.py performs both enumeration and ticket extraction in one step:
python3 GetUserSPNs.py -dc-ip 10.10.10.10 CORP.LOCAL/jsmith:Password123 -request
The output includes the Kerberos 5 TGS-REP hashes in hashcat-compatible format (mode 13100). Critically, this activity uses legitimate Kerberos protocol requests — the domain controller cannot distinguish a legitimate service ticket request from an attacker's enumeration.
Step 3: Identify High-Value Targets
Not all SPNs are equal. The attacker focuses on service accounts that are likely to have weak passwords and high privileges. Common high-value targets include:
- SQL Service Accounts: Often configured with SPNs like
MSSQLSvc/sqlserver.corp.local:1433. Frequently run as domain users with DBA-level access or even Domain Admin membership. - IIS Application Pool Accounts: Registered with SPNs for web application authentication, often provisioned years ago with static passwords.
- Scheduled Task Service Accounts: Frequently set up by developers with simple, never-expiring passwords.
- Legacy Application Accounts: Any service account that predates modern password policies is a prime target.
Step 4: Offline Hash Cracking
The extracted hashes are cracked offline using hashcat with mode 13100 (Kerberos 5 TGS-REP etype 23). A GPU-equipped cracking rig can test billions of combinations per second:
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt -r rules/best64.rule
For AES-encrypted tickets (etype 17/18), use modes 19600 and 19700 respectively. RC4-HMAC (etype 23) is significantly weaker and cracks much faster — which is precisely why forcing AES-only encryption is a critical hardening step.
Step 5: OPSEC Considerations
From an offensive security perspective, kerberoasting can be tuned to reduce detection. Requesting tickets for every SPN simultaneously generates a burst of Event ID 4769 logs with RC4 encryption type — a well-known detection signature. A measured attacker will space requests out over hours, target only accounts with common SPNs, and prioritize accounts where AES encryption is not enforced (indicating a likely weak password).
The --delay flag in Impacket's GetUserSPNs.py controls the inter-request timing. Some threat actors request tickets from multiple source IPs or sacrifice operational accounts to stay below threshold-based alerting.
Detection: What to Monitor
The primary detection opportunity is Windows Event ID 4769 (A Kerberos service ticket was requested) with a specific filter on the encryption type. When a ticket is requested using RC4-HMAC (encryption type 0x17) rather than AES, it is a strong indicator of kerberoasting activity — modern Kerberos clients default to AES when available.
Detection criteria to implement in your SIEM:
- Event ID 4769 where Ticket Encryption Type = 0x17 (RC4)
- Multiple 4769 events from a single source workstation within a short time window
- 4769 events requesting tickets for service accounts that have not been accessed recently
- 4769 events originating from hosts where the requesting user does not normally access that service
Advanced detection layers include deploying honeypot service accounts — accounts with SPNs registered but that no legitimate service or user should ever request tickets for. Any 4769 event targeting a honeypot SPN is an unambiguous indicator of kerberoasting activity.
Remediation and Hardening
Managed Service Accounts and Group Managed Service Accounts
Microsoft's Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) are the definitive solution to kerberoasting. gMSAs use 240-byte automatically-rotated passwords managed entirely by Active Directory — it is computationally infeasible to crack a 240-byte random password in any timeframe. gMSAs work across multiple servers (unlike individual MSAs) and support service principal name automatic registration.
Migration to gMSAs is the most impactful single remediation step you can take. Our penetration testing engagements consistently show that organizations using gMSAs for all service accounts eliminate kerberoasting as a viable attack path.
Strong Password Policy for Remaining Service Accounts
For service accounts that cannot use gMSAs (some legacy applications do not support MSA authentication), enforce passwords of 25 characters or more composed of random characters. At this length, even RC4-encrypted tickets become impractical to crack with current GPU hardware. Use a password manager or secrets vault to generate and store these passwords.
Force AES Encryption
Configure service accounts to require Kerberos AES encryption by setting the msDS-SupportedEncryptionTypes attribute to require AES-128 or AES-256. This eliminates the weak RC4 encryption path entirely and significantly increases cracking time for any extracted tickets. Set "This account supports Kerberos AES 256 bit encryption" and "This account supports Kerberos AES 128 bit encryption" flags in the account properties, and disable "Do not require Kerberos preauthentication."
Principle of Least Privilege
Audit the domain group membership of every service account with an SPN. Any service account that is a member of Domain Admins, Administrators, or any other privileged group is an extreme risk. Service accounts should have only the permissions required for the specific service they support — nothing more. Regularly review and right-size service account permissions as part of your proactive security program.
Regular Penetration Testing
Kerberoasting is a staple of every internal network penetration test. Organizations that conduct annual or more frequent internal assessments consistently catch and remediate vulnerable service accounts before attackers do. Contact Fortress MSSP to schedule an Active Directory security assessment that specifically evaluates your kerberoasting exposure surface.