Kerberoasting Active Directory: Complete Operator Guide (2026)

Kerberoasting is one of the most reliable privilege escalation techniques in internal Active Directory assessments. It targets service accounts — accounts that run services and have a Service Principal Name (SPN) registered in the domain. The core insight is simple: any authenticated domain user can request a TGS ticket for any SPN, and that ticket is encrypted with the service account's password hash.

You take the ticket offline. You crack the hash. If the service account has a weak password, you have credentials — often for accounts with elevated privileges or direct paths to Domain Admin.

The attack is quiet, it requires no special permissions, and it scales across any domain. If you find service accounts with weak passwords, you own the domain. Here is how to find them.

MITRE ATT&CK: T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting

How does Kerberoasting work?

Kerberoasting works by requesting TGS service tickets for SPN-registered accounts from the KDC — tickets the KDC issues to any authenticated user — then cracking the RC4-encrypted ticket offline to recover the service account password.

To understand the attack, you need to understand the Kerberos ticket flow. When a user authenticates to Active Directory, the KDC issues a Ticket Granting Ticket (TGT) encrypted with the krbtgt hash. That TGT is then used to request service tickets (TGS) for specific resources.

When a client requests a TGS for a service — identified by its SPN — the KDC issues a ticket encrypted with the service account's NTLM password hash. This is by design. The target service needs to decrypt the ticket to validate the client, and it does so using its own credentials.

The attacker's position: you request a TGS for any SPN-registered account, receive the encrypted ticket, and take it offline. The KDC does not validate whether you actually need access to that service. It issues the ticket to any authenticated user who asks.

RC4 vs AES: By default, the KDC will encrypt TGS tickets using RC4-HMAC (etype 0x17) unless the account is configured for AES-only. RC4 tickets crack significantly faster because RC4 is weaker and hashcat handles etype 23 efficiently. When you enumerate SPNs, note which accounts support RC4 — those are your priority targets.

The attack does not touch the target account directly. There are no failed logins, no authentication attempts against the service account, and no account lockouts. The only forensic signal generated is a successful TGS request.

The detection signal is Event ID 4769 (Kerberos Service Ticket Operations) with Ticket Encryption Type 0x17. In a mature SOC, high-volume requests of this type for service accounts — especially from workstations — trigger alerts. In most environments, they do not.

Which Active Directory accounts are roastable via Kerberoasting?

An account is roastable when it has an SPN registered and is a user account rather than a computer account — computer accounts use randomly generated 120-character passwords that are not worth targeting.

An account is roastable if it meets two conditions: it has an SPN registered, and it is a user account (not a computer account). Computer accounts have long, randomly generated passwords that are not worth targeting. User accounts with SPNs — typically service accounts — are your target.

The LDAP filter to enumerate roastable accounts directly:

(&(servicePrincipalName=*)(objectCategory=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))

This returns all enabled user objects with at least one SPN. Run it with ldapsearch or any LDAP client. The output gives you the account list, their SPNs, and group memberships.

Not all roastable accounts are equal. Prioritize accounts that are:

• Members of Domain Admins, Enterprise Admins, or other privileged groups
• Delegated administrative rights over OUs, GPOs, or sensitive objects
• Configured with unconstrained or constrained delegation
• Named with patterns like svc_, _admin, backup, sql, exchange — these often have weak or default passwords set years ago and never rotated

Manual approach with impacket: GetUserSPNs.py from the impacket suite is the standard tool for Kerberoasting without ADscan. It authenticates to the domain, enumerates SPNs, requests TGS tickets, and outputs crackable hashes in a single command:

GetUserSPNs.py -request -dc-ip 192.168.1.1 DOMAIN/user:password

The output is ready for hashcat. The limitation is that you get a flat list of hashes with no context about which accounts matter most.

ADscan approach: After running start_auth to authenticate against the domain, run:

kerberoast

ADscan runs Kerberoasting natively — no impacket dependency, no Python environment to set up. It automatically identifies roastable accounts, extracts TGS tickets, and displays results ranked by attack path impact inside the interactive shell. Accounts with a path to Domain Admin are flagged first. You see not just the hash, but the attack path context.

How do you extract and crack Kerberoasting hashes?

RC4-HMAC TGS hashes (etype 23) are saved to a file and cracked with hashcat mode 13100 — on an RTX 4090, RC4 hashes run at roughly 4 billion guesses per second, making weak service account passwords recoverable in seconds.

With GetUserSPNs.py, the hash output looks like this:

$krb5tgs$23$*svc_sql$DOMAIN.LOCAL$DOMAIN.LOCAL/svc_sql*$a1b2c3...

The 23 identifies this as RC4-HMAC (etype 23). Save the hash to a file and run hashcat with mode 13100:

hashcat -m 13100 hash.txt rockyou.txt

For AES-encrypted tickets (etype 18), use hashcat mode 19700:

hashcat -m 19700 aes_hash.txt rockyou.txt

Throughput based on Chick3nman hashcat benchmarks (RTX 4090).

Wordlist strategy for service accounts: rockyou.txt covers weak passwords, but service accounts often have passwords set by administrators following internal conventions. Build a custom wordlist from:

• Corporate naming patterns: CompanyName2024!, Servicename123
• Season + year combos: Spring2024!, Winter2023, Autumn2025@
• Product names visible in the environment (SQL server versions, application names)
• The company name itself combined with common suffixes

In real engagements, service account passwords are often set once during deployment and never rotated. Crack rates for roastable accounts in real environments can be substantial — especially in organizations without a Tier 0 password policy.

If you have access to a domain workstation, running hashcat locally or against a dedicated cracking rig significantly improves throughput.

What does ADscan do differently for Kerberoasting compared to impacket?

ADscan runs Kerberoasting natively without impacket and maps each roastable account against the full attack graph, so you know which hashes to crack first based on the account's distance to Domain Admin.

Most Kerberoasting tools give you a list of hashes. ADscan gives you a prioritized attack path.

ADscan runs Kerberoasting natively — no impacket, no additional Python dependencies. The tool runs inside Docker, so setup is a single pull with no dependency conflicts. After start_auth, the kerberoast command handles SPN enumeration, TGS extraction, and hash saving in one step.

The key differentiator is context. ADscan maps roastable accounts against the full attack graph computed from the domain enumeration. You can see immediately which service accounts have a path to Domain Admin — through group membership, ACL abuse, delegation, or any other relationship in the graph. This lets you prioritize cracking efforts against accounts that actually matter.

Evidence is collected automatically. Hashes are saved to the workspace, linked to the finding, and included in the audit trail.

With ADscan PRO, adscan deliver generates a client-ready PDF documenting the Kerberoasting finding with CVSS scoring, evidence, affected accounts, and remediation guidance — formatted for the client report without manual editing.

Running 2+ AD engagements per year? Get PRO beta access — free for 30 days.

How is Kerberoasting detected and prevented?

Kerberoasting is detected by monitoring Event ID 4769 with Ticket Encryption Type 0x17 — RC4 TGS requests from workstations for multiple service accounts in a short window is the primary signal.

Detection: Monitor for Event ID 4769 (Kerberos Service Ticket Operations) with Ticket Encryption Type 0x17. A workstation or user account requesting RC4 TGS tickets for multiple service accounts in a short window is a reliable signal. Baseline normal TGS request volumes per account and alert on anomalies.

Microsoft Defender for Identity (MDI) includes a built-in Kerberoasting detection that correlates TGS requests by source, timing, and encryption type.

Prevention:

• Managed Service Accounts (MSA/gMSA): Computer-managed accounts with 240-character randomly generated passwords that rotate automatically. If a service supports gMSA, use it. The password is uncrackable.
• AES-only Kerberos encryption: Configure service accounts to require AES encryption. This eliminates RC4 tickets and makes offline cracking significantly harder.
• No SPNs on privileged accounts: Tier 0 and Tier 1 accounts should not have SPNs. A Domain Admin with an SPN is a critical finding.
• Regular SPN audits: Enumerate SPNs quarterly. Remove SPNs from accounts that no longer run services. Many orphaned SPNs exist in mature domains from decommissioned services.
• Strong, unique passwords on legacy service accounts: Where gMSA is not possible, enforce passwords of 25+ characters with complexity. Document a rotation schedule.

ADscan automatically flags roastable accounts in every scan and marks privileged service accounts as high-priority findings.

Is Kerberoasting still effective against modern Active Directory environments in 2026?

Kerberoasting remains effective in 2026 because service account passwords set years ago are still crackable, and gMSA adoption remains low in environments that have never conducted a Tier 0 hygiene audit.

Kerberoasting remains one of the most consistent privilege escalation paths in real Active Directory environments. No special privileges are needed to run it — any authenticated domain user can enumerate SPNs and request TGS tickets. The attack generates minimal noise and targets accounts that are frequently misconfigured and never audited.

The technique has been well-known for over a decade. Environments are still vulnerable because service account hygiene is operationally difficult. Passwords set in 2018 are still crackable in 2026.

Get started with ADscan LITE — free and open source — and run Kerberoasting as part of your next internal assessment:

• Download ADscan LITE: https://github.com/ADScanPro/adscan
• Request PRO beta: https://adscanpro.com/pro