Overview
Kerberos v5 (RFC 4120) is the authentication protocol behind Active Directory and many Unix realms, spoken over TCP and UDP port 88. From a PCAP/PCAPNG you can follow the ticketing exchange without ever seeing a password: the analyzer decodes each message and shows who authenticated to what, which encryption types were offered, and which ticket the KDC issued. Kerberos never sends passwords, and ticket bodies are encrypted—but the cleartext envelope (message types, principals, realms, encryption types, and error codes) is enough to troubleshoot logons and spot attacks such as Kerberoasting, AS-REP roasting, password spraying, and user enumeration.
- What you’ll see: message types (AS-REQ/AS-REP, TGS-REQ/TGS-REP, AP-REQ/AP-REP, KRB-ERROR), client and service principals (SPNs), realms, offered encryption types, issued-ticket cipher, and KRB-ERROR codes
- Best for: Active Directory authentication troubleshooting, SOC triage, incident response, weak-cipher exposure review
- Works with: TCP/UDP 88 to domain controllers/KDCs; correlates with LDAP, SMB2, and TLS in the same capture
What to look for
- Kerberoasting: a TGS-REP that issues a service ticket encrypted with RC4-HMAC (etype 23)—crackable offline against the service account’s NTLM hash,
- Weak ciphers offered: RC4 (etypes 23/24) or single-DES (etypes 1/3) in a request → encryption downgrade; AES (17/18) is the strong choice,
- Password spraying / brute force: bursts of error 18 (KDC_ERR_PREAUTH_FAILED) across many accounts,
- AS-REP roasting exposure: accounts that never trigger error 19 (KDC_ERR_PREAUTH_REQUIRED), i.e. pre-auth is not enforced,
- User enumeration: many error 6 (KDC_ERR_C_PRINCIPAL_UNKNOWN) responses from a single source,
- Cipher mismatch: error 14 (KDC_ERR_ETYPE_NOSUPP)—a misconfiguration or a probe for weak-cipher support,
- Clock skew: error 37 (KRB_AP_ERR_TKT_EXPIRED), usually a time-synchronisation problem between client, KDC, and service.
Capture tips
- Capture both UDP and TCP 88 to the domain controllers/KDCs; large tickets can push exchanges onto TCP.
- Include the related directory traffic (LDAP, SMB2, TLS) so authentication can be correlated with what followed.
- Capture close to the KDC to see requests from many clients, or close to a client to isolate one account’s logon.
- Reproduce the failing logon during the window so the relevant KRB-ERROR is present in the trace.
- Use a focused time window that reproduces the issue and stays within the 10 MB demo limit.
Example walkthrough
- Browse to Kerberos.
- Follow the AS-REQ / AS-REP exchange: confirm the client principal, realm, and that pre-authentication is required (error 19 then success).
- Inspect TGS-REQ / TGS-REP: note the requested service principal (SPN) and the encryption type of the issued ticket.
- Flag any RC4 service ticket (etype 23) as a Kerberoasting indicator; check requests offering RC4/DES as downgrade.
- Scan KRB-ERROR codes for bursts of 18 (spraying), many 6 (enumeration), or 37 (clock skew).
- Open the parsed Kerberos view for msg type, principals, encryption types, error codes, and issued-ticket details; export evidence for the ticket.
Kerberos FAQ
Watch for a TGS-REP that issues a service ticket encrypted with RC4-HMAC (etype 23). That ticket is encrypted with the service account’s NTLM hash and can be cracked offline. The analyzer decodes the issued ticket’s service principal and encryption type and flags RC4 service tickets automatically.
Error 18 (KDC_ERR_PREAUTH_FAILED) is a failed logon; bursts across accounts suggest password spraying or brute force. Error 19 (KDC_ERR_PREAUTH_REQUIRED) is a normal reply, but an account that never requires it is exposed to AS-REP roasting. Error 6 (KDC_ERR_C_PRINCIPAL_UNKNOWN) from one source is a hallmark of username enumeration.
RC4-HMAC (etype 23) and single-DES (etypes 1 and 3) are legacy ciphers. Offering them enables encryption downgrade and makes service tickets easier to crack offline. AES (etypes 17 and 18) are the strong choices; modern realms should require them.
No. Kerberos never sends passwords, and ticket bodies are encrypted with keys the capture does not contain. The analysis works from the cleartext envelope: message types, client and service principals, realms, offered and issued encryption types, and error codes.