Kerberos Under Siege: Abusing the Trust Backbone of Windows Domains
Kerberos, introduced to Windows with Active Directory in 2000, is widely seen as a secure, modern replacement for NTLM. And yet, in the hands of an attacker, it becomes a double-edged sword. This post explores how Kerberos works, and how it can be abused through techniques like Kerberoasting, delegation abuse, and ticket impersonation.
How Kerberos Actually Works
Authentication starts when a user logs in and the Key Distribution Center (KDC), a service on the domain controller, issues a TGT (Ticket Granting Ticket) encrypted with the user’s secret. This lets the user request service tickets to access other services without sending credentials again.
From a security model perspective, this is elegant. Credentials never cross the wire. Everything is based on secret keys and symmetric encryption. But this also assumes every piece in the chain, from domain users to service accounts, is configured securely.
Spoiler: they rarely are.
Kerberoasting: Plaintext Passwords in Disguise
If a service account uses a weak password, it’s game over.
Service tickets are encrypted with the service account’s password hash. Any domain user can request a ticket to any SPN (Service Principal Name), even without legitimate access. The attacker just needs to capture the ticket and brute-force it offline.
Request SPN ticket → Extract ticket → Crack with hashcat
Kerberoasting doesn’t require elevated rights. Just domain access. And if that SPN maps to a privileged account (e.g. Domain Admin used for SQL service), cracking that password opens the domain.
Default AD configs don’t restrict this. Detection? Hard. Ticket requests look normal. Mitigation? Use strong, random passwords for service accounts. Monitor ticket requests for unusual patterns.
Delegation: More Trust, More Problems
Kerberos supports delegation, allowing services to act on behalf of users. Useful for SSO scenarios like web apps accessing databases, but dangerous if abused.
Unconstrained Delegation lets a service impersonate any user who authenticates to it. If an attacker compromises such a host, they can extract users’ TGTs and use them elsewhere, effectively becoming them. Golden ticket territory.
Constrained Delegation tries to limit this to specific services. But it’s often misconfigured. And worse, Resource-Based Constrained Delegation (RBCD) lets target systems define who can delegate to them, opening up attack chains where a low-priv user adds a rogue computer object and escalates.
These trust edges form a privilege escalation graph. BloodHound maps this beautifully.
Ticket Forgery and Impersonation
Once an attacker gets the KRBTGT account’s hash (e.g. via DCSync), they can create Golden Tickets, valid TGTs for any user, any group, any time. Total domain compromise.
More subtle is Silver Ticketing. Here, the attacker forges only the service ticket, not the TGT. Requires the service account’s hash, not KRBTGT. Harder to detect. Ideal for lateral movement.
Tools like Rubeus automate this: asktgt, s4u, tgtdeleg, kerberoast, golden, and silver.
Worked Example: Kerberoasting with Rubeus
Rubeus.exe kerberoast /format:hashcat /user:svc_sql /domain:corp.local
→ Dumps service tickets in hashcat format.
hashcat -m 13100 hashes.txt rockyou.txt
→ Cracks the SPN ticket. If the password is weak, you’re in.
This is achievable from any domain user account. No alerts triggered, unless you’ve configured ticket monitoring.
Final Thoughts
Kerberos isn’t broken. But it’s trust-heavy. And Windows environments are often too trusting.
Strong service account hygiene, strict delegation configs, and monitoring ticket activity are the bare minimum. Defensive tools like klist, event ID 4769, and Kerberoast detection rules help, but only if actively used.
In red team ops, Kerberos attacks are quiet, credential-free, and highly effective. They don’t break the protocol. They exploit how admins use it.
Want to defend the kingdom? Start by defending the keys.