Wireshark Kerberos Analysis: Debug Authentication Tickets (2026)

Kerberos authentication tickets are actually just encrypted data blobs, and their contents are surprisingly easy to inspect once you know how.

Let’s see what a Kerberos ticket looks like in Wireshark. Imagine a user alice@REALM.COM logging into a server service.realm.com.

First, the client (alice) asks the Key Distribution Center (KDC) for a Ticket Granting Ticket (TGT).

// Client requests TGT from KDC
// (This is a simplified representation of the network flow)
Client -> KDC: AS-REQ (Authentication Service Request)
KDC -> Client: AS-REP (Authentication Service Reply - contains TGT and session key)

Then, the client uses the TGT to request a service ticket for service.realm.com.

// Client requests service ticket from KDC
Client -> KDC: TGS-REQ (Ticket Granting Service Request)
KDC -> Client: TGS-REP (Ticket Granting Service Reply - contains service ticket and session key)

Finally, the client presents the service ticket to the service.

// Client presents service ticket to the service
Client -> Service: AP-REQ (Application Request - contains service ticket and authenticator)
Service -> Client: AP-REP (Application Reply - acknowledges successful authentication)

In Wireshark, you’ll see these packets. The key is to look at the KRB-AP-REQ and KRB-TGS-REP packets, specifically the ticket field within them.

To inspect the ticket itself, you need to follow these steps in Wireshark:

1. Filter for Kerberos traffic: Start by filtering your capture for kerberos. This will show you all Kerberos-related packets.
2. Locate a KRB-TGS-REP or KRB-AP-REQ packet: These are the packets that contain the tickets you want to examine. A KRB-TGS-REP is the reply from the KDC containing the service ticket, and a KRB-AP-REQ is the client sending that service ticket to the target service.
3. Expand the ticket field: In the Packet Details pane, find the Kerberos protocol. Expand it, and you’ll see a field called ticket.
4. Export the ticket: Right-click on the ticket field. You’ll see an option to "Export Selected Packet Bytes…" or similar. Choose this. Save the exported bytes to a file, for example, service_ticket.bin.

Now you have the raw ticket data. To decrypt and read it, you can use the klist command on a Linux/macOS system that has the appropriate Kerberos libraries installed, or use tools like tksnoop on Windows.

For example, on Linux, you might use klist -v:

klist -v service_ticket.bin

This command will attempt to decrypt the ticket using the client’s credentials (if run on the client) or the service’s key (if run on the service, though that’s less common for ticket inspection). It will output details like the principal names, the realm, the session key, and the ticket’s validity period.

The mental model here is that Kerberos tickets are not plain text. They are encrypted using symmetric keys. The TGT is encrypted with the KDC’s secret key, and the service ticket is encrypted with the service’s secret key. The client receives these encrypted blobs and passes them around. Only the intended recipient (the KDC for the TGT, the service for the service ticket) can decrypt them.

The AS-REP contains the TGT and an encrypted session key. The TGS-REP contains the service ticket and an encrypted session key. The AP-REQ contains the service ticket and an authenticator which is encrypted with the session key shared between the client and the KDC from the TGS-REP.

This whole process is designed to prove identity without sending plaintext passwords over the network. The client proves it knows the session key (by decrypting it with its own long-term key), and the KDC proves it issued the ticket. The service proves it’s the intended recipient by decrypting the ticket with its own key.

The most surprising thing about Kerberos tickets is how easily they can be inspected if you have the right context. When you export the ticket bytes, you’re getting the encrypted blob. The real magic happens when a tool like klist or tksnoop uses the decryption key (either the client’s key or the service’s key) to unwrap the data. Without the correct key, the exported bytes are just gibberish.

If you’re seeing repeated KRB-ERROR messages in Wireshark, it often means the client is presenting a ticket that the service cannot validate. This could be due to clock skew, an incorrect service principal name, or a problem with the ticket itself. Examining the KRB-ERROR message’s error-code field will give you a specific clue, such as KDC_ERR_NEVER_VALID (clock skew) or KDC_ERR_S_PRINCIPAL_UNKNOWN (service principal not found).

The next thing you’ll likely wrestle with is understanding the authenticator part of the AP-REQ and how it’s verified by the service.