decoder.tools

LDAP / Kerberos Ticket Decoder

Decode Kerberos tickets and authentication messages, and the LDAP structures used around them.

Security, PKI & CryptoFree
INPUT

Or drop a file here: a .kirbi ticket or raw Kerberos message

OUTPUT

The result appears here as you type.

Decoding runs in your browser. What you paste is not sent to a server.

A Kerberos ticket decoder parses the ASN.1 structures of Kerberos v5 messages, such as a ticket, an AP-REQ from an Authorization: Negotiate header or a cached ticket file, and shows the fields that aren't encrypted: realm, service principal, encryption type and ticket flags.

Example

An AP-REQ decodes to the service it targets and how strongly the ticket is encrypted:

Kerberos AP-REQ

Ticket:
  Realm:   EXAMPLE.COM
  Service: HTTP/web.example.com
  Encryption: 18 — aes256-cts-hmac-sha1-96

An encryption type of 23 (rc4-hmac) is weak and enables Kerberoasting — worth flagging in a review.

What you can and can't read

Kerberos (RFC 4120) messages are DER-encoded ASN.1. A ticket has a readable outer part and an encrypted inner part:

Readable without keysEncrypted with the service key
Realm (EXAMPLE.COM)Client principal
Service principal name (HTTP/web.example.com)Session key
Encryption type (etype)Auth time, start, end and renew-until times
Key version number (kvno)Authorization data (on Windows, the PAC with group SIDs)

So without the service's keytab you can see which service a ticket is for and how strongly it's encrypted, but not who the user is or when the ticket expires.

On the web, browsers send Kerberos inside SPNEGO: Authorization: Negotiate YII…. The Base64 decodes to a GSS-API token wrapping an AP-REQ.

How to use the Kerberos decoder

  1. Paste a Base64 or hex Kerberos message — a ticket, an AP-REQ, or the token from an Authorization: Negotiate header.
  2. Read the realm, service principal and encryption type. The client identity and session key are encrypted with the service key and can't be read.
  3. A Negotiate token that wraps NTLM is detected and sent to the NTLM decoder instead.

On a host, klist lists your cached tickets and their encryption types:

Command line
# List tickets in your cache, with encryption types
klist -e

# On Windows
klist

Wireshark dissects Kerberos traffic and, given a keytab, can decrypt ticket contents.

Encryption types

etypeNameStatus
18aes256-cts-hmac-sha1-96Recommended
17aes128-cts-hmac-sha1-96Acceptable
23rc4-hmacWeak. Enables Kerberoasting. Disable it
3des-cbc-md5Broken. Disabled by default

Frequently asked questions

What is Kerberoasting?

An attack where any domain user requests service tickets for accounts with SPNs, then cracks the RC4- or AES-encrypted part offline to recover the service account's password. Long random service account passwords and AES-only encryption defend against it.

Why does a Negotiate header sometimes contain NTLM?

SPNEGO falls back to NTLM when Kerberos isn't possible, for example when connecting by IP address instead of hostname. A token starting with TlRMTVNT is NTLM. Use the NTLM decoder.

Where does LDAP fit in?

In Active Directory, LDAP stores the accounts and SPNs that Kerberos tickets are issued for, and LDAP binds are often authenticated with Kerberos (SASL/GSSAPI). Both protocols use ASN.1 BER encoding.

Last reviewed · found a mistake? contact@decoder.tools · view as markdown