Kerberos for Offensive Security: How the Protocol Works
Kerberos for pentesters: AS-REQ, TGT, SPNs and the PAC, where AS-REP Roasting and Kerberoasting fit, and why clock skew breaks everything.
Kerberos gets much easier once you stop memorizing attack names and start following the tickets.
In an Active Directory domain, a client does not send the password to every server it accesses. It proves identity to the KDC, receives a TGT, and uses that TGT to request service tickets.
Almost every offensive Kerberos technique touches one of those stages.
The examples below assume a lab or an authorized penetration test.
The KDC sits in the middle
In Active Directory, the KDC runs on the Domain Controller.
It has two logical roles that appear often in documentation.
The Authentication Service participates in initial authentication.
The Ticket Granting Service issues tickets for specific services.
In practice, the client talks to the same KDC at different stages.
The first stage produces a TGT.
The second produces a service ticket.
AS-REQ and AS-REP
When a user needs a TGT, the client sends an AS-REQ.
In a normal configuration, pre-authentication is required.
The client proves knowledge of key material derived from the password before the KDC returns useful material.
Simplified:
1
2
3
4
5
6
7
8
9
user
|
| AS-REQ + pre-auth
v
KDC
|
| AS-REP
v
TGT
The TGT is protected so the client cannot alter its contents.
In Active Directory, it is protected with key material tied to the krbtgt account.
That detail explains why compromise of the krbtgt key changes the security model so dramatically.
A TGT does not directly access the server
After obtaining a TGT, the client still needs a ticket for the target resource.
If the user wants CIFS on fileserver.lab.local, the client asks for a ticket to something like:
1
cifs/fileserver.lab.local
That name is an SPN, a Service Principal Name.
The flow becomes:
1
2
3
4
5
6
7
8
9
10
11
12
TGT
|
| TGS-REQ
v
KDC
|
| TGS-REP
v
service ticket
|
v
CIFS
The service ticket is created for that service.
The server can validate it because it has the key associated with the service principal.
SPNs are service identities
An SPN can look like a syntax detail.
It decides which account represents a Kerberos service.
Example:
1
MSSQLSvc/sql01.lab.local:1433
If that SPN belongs to svc_sql, tickets for the service are protected with key material tied to that account.
That is what makes Kerberoasting possible.
The attacker requests a legitimate service ticket.
Then the attacker tests password candidates offline against cryptographic material from the ticket.
The practical weakness usually comes from a weak service-account password or legacy encryption.
AS-REP Roasting happens before the TGT
If an account is configured without Kerberos pre-authentication, the KDC may return an AS-REP without requiring the normal initial proof.
Part of that material can be tested offline against password candidates.
The security issue comes from account configuration. A useful protection in the initial exchange has been disabled.
With Impacket, lab enumeration may look like this:
1
2
3
4
5
6
impacket-GetNPUsers \
lab.local/ \
-dc-ip 10.10.10.10 \
-usersfile users.txt \
-no-pass \
-format hashcat
If a vulnerable account appears, the next part of the test is offline.
Kerberoasting happens after authentication
Kerberoasting requires a domain identity capable of requesting service tickets.
The attacker enumerates accounts with SPNs and requests tickets.
Example:
1
2
3
4
impacket-GetUserSPNs \
lab.local/gabriel:'Password123!' \
-dc-ip 10.10.10.10 \
-request
The returned material can be tested offline.
The service account keeps working normally.
That makes the technique especially relevant in environments with old service accounts and passwords that have not been rotated for years.
Tickets and credentials are different things
This distinction clears up a lot of confusion.
Passwords, NT hashes, AES keys, and certificates are different forms of authentication material.
TGTs and service tickets are temporary credentials issued by the KDC.
If you already possess a valid TGT, you may access resources without knowing the password at that moment.
That is the logic behind Pass-the-Ticket.
A tool places a valid ticket into the session context.
The service sees valid Kerberos authentication because the ticket remains cryptographically acceptable.
klist is more useful than it looks
On Windows:
1
klist
On Linux with MIT Kerberos:
1
klist
The command shows tickets present in the cache.
During offensive troubleshooting, this answers basic questions quickly.
Is there a TGT?
Is there a ticket for CIFS?
Which realm appears?
Has the ticket expired?
Is the SPN correct?
Before blaming DNS, time and tooling at once, I check the cache. Then I move toward the KDC.
Time breaks Kerberos quickly
Kerberos uses time as part of its replay protection.
If the client and KDC drift too far apart, authentication can fail.
This appears often in labs and pivoted environments.
An attacking machine may have a different clock from the DC.
Tools such as faketime appear in writeups for that reason.
The real fix in production is accurate time synchronization.
DNS matters in practice too
Kerberos relies heavily on names.
SPNs are service names.
Domain Controllers are discovered through DNS.
Using an IP where an application expects a hostname may push authentication toward NTLM or break the flow entirely.
When Kerberos fails strangely, I check resolution, FQDNs, and SPNs before reaching for exotic explanations.
The PAC carries authorization data
Windows Kerberos tickets can contain the PAC, the Privilege Attribute Certificate.
It carries information used during authorization, including group data associated with the user.
That helps explain why ticket forgery techniques can be so powerful.
Forging only a username would not be enough.
The useful part is producing material the environment accepts together with authorization information.
Golden Tickets, Silver Tickets, and Diamond Tickets go deeper into this area.
A better way to study Kerberos attacks
I group attacks by the stage they abuse.
AS-REP Roasting targets initial authentication without pre-auth.
Kerberoasting targets service tickets and keys tied to SPN accounts.
Pass-the-Ticket reuses tickets that are already valid.
Golden Tickets attack trust in TGTs.
Silver Tickets attack trust at a specific service.
Delegation abuse uses legitimate mechanisms created for services to act on behalf of users.
Once the protocol flow is clear, those names stop looking like unrelated tricks.
What to defend first
Remove unnecessary accounts that lack pre-authentication.
Use long managed passwords for service accounts.
Prefer gMSA where it fits.
Reduce RC4 and legacy encryption where compatibility allows it.
Protect krbtgt.
Review delegation.
Monitor unusual ticket activity.
Keep DNS and time healthy.
Kerberos has a lot of detail, but its core fits into two ideas: a TGT to talk to the KDC, and a service ticket to talk to the service.
References
Microsoft Learn, Kerberos authentication overview in Windows Server.
MIT Kerberos Documentation, Encryption types.
MIT Kerberos Documentation, Ticket management.