What does a full Kerberos AS-REQ → AS-REP → TGS-REQ → TGS-REP → AP-REQ → AP-REP cycle look like on the wire?

The client first sends an AS-REQ to the KDC on UDP/88 with cname, sname=krbtgt/REALM, a PA-ENC-TIMESTAMP padata blob encrypted under its long-term key, and an etype list. The KDC validates the timestamp and replies with AS-REP containing the TGT (encrypted to krbtgt's key) and a session key (encrypted to the user's key). The client then sends TGS-REQ with PA-TGS-REQ (the TGT used as an authenticator) and sname set to the target service (e.g. host/server.dom). The KDC issues a TGS-REP with the service ticket and a per-service session key. Finally the client opens an application-layer connection (SMB, HTTP, LDAP, etc.) and presents AP-REQ containing the service ticket plus a fresh authenticator; the server replies with AP-REP only if the client requested mutual authentication. After that, the application protocol takes over.

What does KDC_ERR_PREAUTH_REQUIRED look like on the wire, and how is it different from KDC_ERR_ETYPE_NOSUPP?

KDC_ERR_PREAUTH_REQUIRED (code 25) is the normal Windows/MIT response when a client sends an AS-REQ with no PA-ENC-TIMESTAMP. The KRB-ERROR e-data carries a METHOD-DATA list of required pa-types (PA-ENC-TIMESTAMP=2 and usually PA-ETYPE-INFO2=19), and the client immediately retries AS-REQ with an encrypted timestamp. KDC_ERR_ETYPE_NOSUPP (code 14) is different — the KDC understood the request but none of the etypes offered by the client match what the account or krbtgt allow. The e-data lists the etypes the KDC will accept. PREAUTH_REQUIRED is about authentication state; ETYPE_NOSUPP is about cipher negotiation.

How do you tell normal Kerberos pre-auth negotiation from an AS-REP-roasting attempt?

In a normal pre-auth dance the client's first AS-REQ has no PA-ENC-TIMESTAMP, the KDC returns KDC_ERR_PREAUTH_REQUIRED, and the client retries with an encrypted-timestamp padata blob before getting an AS-REP. In an AS-REP-roasting attempt the attacker also sends AS-REQ with no PA-ENC-TIMESTAMP, but the KDC returns an AS-REP directly because the targeted account has the DONT_REQUIRE_PREAUTH UserAccountControl flag set. Other tells: the attacker often sweeps many usernames from one source, never sends a follow-up TGS-REQ, and prefers etype 23 (RC4-HMAC) in the etype list because it is cheapest to crack with hashcat mode 18200. The smoking gun is AS-REP returned to a client that never proved knowledge of the user's key.

Why is a TGS-REP encrypted with RC4-HMAC a Kerberoasting indicator?

The enc-part of the service ticket inside a TGS-REP is encrypted under the long-term key of the service account. If that key is an RC4-HMAC (etype 23, ARCFOUR-HMAC-MD5) key, the ciphertext can be cracked offline at hashcat mode 13100, which is dramatically faster than AES (etype 17/18). Modern Active Directory should set msDS-SupportedEncryptionTypes on every service account to AES-only (0x18) so the KDC issues etype 17 or 18 tickets only. A TGS-REP with ticket etype 23 means the service account still permits RC4 — exactly what a Kerberoaster looks for. The attacker requests a service ticket they are entitled to, dumps it from memory, and cracks it offline at their leisure.

What is the practical fix for RC4-HMAC tickets and a krbtgt that still allows RC4?

Set msDS-SupportedEncryptionTypes to AES128+AES256 only (decimal 24, hex 0x18) on every service account, including computer accounts, MSAs/gMSAs, and the krbtgt account itself. After changing krbtgt, rotate the krbtgt password twice with a delay between rotations so existing AES-only TGTs continue to validate during the transition. Then audit Event ID 4769 (TGS issued) for any remaining etype 23 entries and chase down the accounts. Once the directory is AES-only and krbtgt is rotated, the wire signature of every TGS-REP changes from etype 23 to etype 17 or 18 and the Kerberoasting indicator disappears.

How does VisualEther render a Kerberos pcap as a sequence diagram?

VisualEther uses its MCP integration with Claude to run explore against the Kerberos pcap with an explore.fxt.xml template that pulls Kerberos-specific fields (msg-type, cname, sname, etype, padata types, error codes, kvno) from the tshark dissector. The output is a sequence diagram with one row per Kerberos message, parameters expanded as a per-message table, and colour styling by message kind (AS-REQ amethyst, AS-REP/TGS-REP forest-green, KRB-ERROR magenta). The extract_sessions tool then groups frames into kerberos-udp sessions keyed by client + service so per-user AS/TGS dialogues can be viewed individually with outcome labels like success::as-rep, success::tgs-rep or failure::error.

Kerberos pcap Analysis: AS-REQ/REP, TGS-REQ/REP, AP-REQ/REP + AS-REP Roasting & Kerberoasting Detection

01UserInitial request

Analyze krb-816.pcapng. Walk me through one full AS-REQ → AS-REP → TGS-REQ → TGS-REP → AP-REQ → AP-REP cycle. Then tell me: if this user got a KDC_ERR_PREAUTH_REQUIRED on the first AS-REQ, what does the trace look like, and how can I tell whether that’s normal pre-auth negotiation or evidence of an AS-REP-roasting attempt? If the trace contains a TGS-REP encrypted with RC4 instead of AES, flag it — that’s a Kerberoasting indicator.

02ClaudeTrace walkthrough & roasting analysis

Rendered the pcap with visualether explore and per-session with extract_sessions. 32 frames, all UDP/88, two users (des, u5) authenticating from 10.1.12.2 (XP1_Client) to KDC 10.5.3.1 in realm DENYDC.COM. No AP-REQ/AP-REP in the capture — it is KDC-only traffic, so I walk the AS/TGS exchange end-to-end and then describe the AP leg from what the issued tickets imply.

1. One full cycle — user `des`, target `host/xp1.denydc.com`

#	Frame	Direction	Message	Key fields
1	1	client → KDC	AS-REQ	cname=`des`, sname=`krbtgt/DENYDC`, PA-ENC-TIMESTAMP etype 23 (RC4-HMAC), etype list advertises RC4 + DES variants
2	2	KDC → client	KRB-ERROR `KDC_ERR_ETYPE_NOSUPP` (14)	e-data lists etypes the KDC will accept: DES-CBC-MD5 (3) + DES-CBC-CRC (1) for `krbtgt/DENYDC.COM` — account is DES-only
3	3	client → KDC	AS-REQ retry	same cname, PA-ENC-TIMESTAMP now etype 3 (DES-CBC-MD5)
4	4	KDC → client	AS-REP ok	TGT for `krbtgt/DENYDC.COM`, ticket etype 23 (RC4), enc-part etype 3 (DES)
5	5	client → KDC	TGS-REQ	PA-TGS-REQ (the TGT as authenticator), sname=`host/xp1.denydc.com`
6	6	KDC → client	TGS-REP ok	service ticket etype 23 (RC4), enc-part etype 3 (DES)
–	–	client → host	AP-REQ	(not captured) — would be SMB / HTTP / LDAP carrying the frame-6 ticket in an AP-REQ wrapper, plus a fresh Authenticator encrypted with the per-service session key
–	–	host → client	AP-REP	(only if mutual-auth requested) — otherwise the application protocol just returns “OK”

So this capture does start with a KDC error on the first AS-REQ — but it’s KDC_ERR_ETYPE_NOSUPP, not KDC_ERR_PREAUTH_REQUIRED. The client already sent PA-ENC-TIMESTAMP on the very first try (this is Windows XP default behaviour); the retry only changes the timestamp’s encryption type, not the authentication flow.

2. What `KDC_ERR_PREAUTH_REQUIRED` actually looks like

The textbook Windows / MIT pattern when a client does not pre-emptively send PA-ENC-TIMESTAMP:

1. AS-REQ   cname=alice  sname=krbtgt   padata = (none, or just PA-PAC-REQUEST)
2. KRB-ERROR KDC_ERR_PREAUTH_REQUIRED (25)
            e-data = METHOD-DATA listing required pa-types
                     (pA-ENC-TIMESTAMP=2, pA-ETYPE-INFO2=19, …)
3. AS-REQ   cname=alice  padata = PA-ENC-TIMESTAMP {encrypted under user's long-term key}
4. AS-REP   TGT issued

That is the healthy pre-auth dance. The KDC says “prove you know the password”, the client encrypts the current time with the user’s key, the KDC validates and returns a TGT.

3. Normal pre-auth vs. AS-REP-roasting

Signal	Normal pre-auth negotiation	AS-REP-roasting attempt
First AS-REQ padata	Empty / PA-PAC-REQUEST only	Empty / no PA-ENC-TIMESTAMP
KDC reply to first AS-REQ	`KDC_ERR_PREAUTH_REQUIRED`	`AS-REP` returned directly — the account has `DONT_REQUIRE_PREAUTH` set. This is the smoking gun.
Follow-up AS-REQ	Yes, with PA-ENC-TIMESTAMP	None — attacker already has the encrypted blob
Client behaviour after AS-REP	TGS-REQ for a service the user actually wants	No TGS-REQ; move on to the next username
Username distribution	One stable user from a known workstation	Many usernames, sweep pattern, frequently a UserEnum dictionary
etype preference	Whatever the OS configured (often AES first)	RC4-HMAC (23) preferred — cracks fastest with hashcat mode 18200
Source	Domain-joined host with prior DNS/DHCP footprint	Unexpected IP, no Netlogon traffic, no prior LDAP binds

Concretely in Wireshark: kerberos.msg_type == 30 && kerberos.error_code == 25 matches the legitimate negotiation. For roasting suspicion: kerberos.msg_type == 11 (AS-REP) where the preceding AS-REQ for that cname had no padata type 2, especially from one source iterating cnames. Those AS-REPs hand the attacker a ciphertext encrypted under the user’s long-term key — offline-crackable at hashcat mode 18200.

In this capture: every AS-REQ already carries PA-ENC-TIMESTAMP on the first try, and every AS-REP follows a successful pre-auth. No AS-REP-roasting pattern present.

4. 🚩 Kerberoasting indicator — flagged

You asked to flag any TGS-REP encrypted with RC4. Every TGS-REP in this trace uses eTYPE-ARCFOUR-HMAC-MD5 (etype 23) for the ticket itself. That is RC4. Twelve hits:

Frame	Service	Ticket etype	enc-part etype
6	`host/xp1.denydc.com`	23 (RC4)	3 (DES)
8	`cifs/VPC-W2K3ENT`	23 (RC4)	23 (RC4)
10	`LDAP/vpc-w2k3ent.denyDC.com`	23 (RC4)	3 (DES)
12	`krbtgt/DENYDC.COM` (renew)	23 (RC4)	3 (DES)
14	`cifs/VPC-W2K3ENT`	23 (RC4)	3 (DES)
16	`ldap/vpc-w2k3ent.denyDC.com/denyDC.com`	23 (RC4)	3 (DES)
18	`cifs/vpc-w2k3ent.denydc.com`	23 (RC4)	3 (DES)
22	`host/xp1.denydc.com`	23 (RC4)	23 (RC4)
26	`LDAP/vpc-w2k3ent.denyDC.com`	23 (RC4)	23 (RC4)
28	`krbtgt/DENYDC.COM` (renew)	23 (RC4)	23 (RC4)
30	`ldap/vpc-w2k3ent.denyDC.com/denyDC.com`	23 (RC4)	23 (RC4)
32	`cifs/vpc-w2k3ent.denydc.com`	23 (RC4)	23 (RC4)

5. Caveat on severity — legacy environment, not active attack

The ticket etype is chosen by the service account’s msDS-SupportedEncryptionTypes, not by the user. RC4 here means VPC-W2K3ENT’s machine/service accounts and krbtgt itself still permit RC4-HMAC — classic legacy AD posture (and consistent with the trace’s 2005-08-16 timestamp and Windows Server 2003 era). It is exactly the condition a real Kerberoaster exploits: the enc-part of any of those tickets is offline-crackable with hashcat mode 13100. In a modern domain, a single etype-23 service ticket on the wire is a finding worth chasing.

6. What to fix in a modern environment

Set msDS-SupportedEncryptionTypes to AES-only (decimal 24, hex 0x18) on every service account, including computer accounts, MSAs / gMSAs and the krbtgt account.
Rotate the krbtgt password twice with a delay between rotations so AES-only TGTs continue to validate during the transition.
Audit Event ID 4769 (TGS issued) for any remaining etype-23 rows and chase the owning service accounts.
Re-run this capture: frames 6 / 8 / 10 / … should show ticket etype 17 (AES128) or 18 (AES256), and the indicator disappears.

03UserField-level detail

Show me the exact Wireshark filters and frame-by-frame fields a blue-team analyst would key on for each of these patterns — pre-auth, AS-REP-roasting, Kerberoasting — so this can be operationalised.

04ClaudeDetection cheat-sheet

Three patterns, three filters, three fields to read off:

A. Healthy pre-auth negotiation

Display filter: kerberos.msg_type == 30 && kerberos.error_code == 25
What to read: the next packet on the same 5-tuple should be kerberos.msg_type == 10 (AS-REQ) with a kerberos.padata_type == 2 (PA-ENC-TIMESTAMP) field present. If the retry arrives within a few hundred milliseconds and is followed by AS-REP (msg_type 11), the negotiation is normal.
SIEM equivalent (Windows): Event ID 4768 (TGT requested) with Pre-Authentication Type = 2. Absence of 4771 (pre-auth failure) on the same user is the “all clear”.

B. AS-REP-roasting sweep

Display filter: kerberos.msg_type == 11 && !kerberos.padata_type on the preceding AS-REQ (use tshark -Y with a two-pass filter, or pivot via kerberos.CNameString).
What to read: AS-REPs where the matching AS-REQ has no PA-ENC-TIMESTAMP. Pull the kerberos.CNameString values and look for many distinct users from one source IP within seconds. Look at the kerberos.etype list inside the AS-REQ — attackers typically put 23 first.
SIEM equivalent: Event ID 4768 with Pre-Authentication Type = 0. AD auditing will log one of these per roasted user.
Account hardening: remove DONT_REQUIRE_PREAUTH (UserAccountControl bit 0x400000) from every user account that does not legitimately need it (vanishingly few should).

C. Kerberoasting indicator

Display filter: kerberos.msg_type == 13 && kerberos.ticket.etype == 23 (TGS-REP whose ticket is RC4-HMAC).
What to read: kerberos.SNameString — the service principal name whose long-term key encrypts the ticket. Service accounts with SPNs that show up here repeatedly are the offline-cracking targets. Cross-reference against msDS-SupportedEncryptionTypes in AD; if it is not 0x18 (AES-only), that account is the exposure.
Volume tell: a single user requesting service tickets for many SPNs in a short window, especially SPNs they have no business touching, is the active-attack signature. The trace here is volume-normal — one user, services they actually use — but every issued ticket is still RC4, so the environment is the vulnerability.
SIEM equivalent: Event ID 4769 (TGS issued) with Ticket Encryption Type = 0x17 (= RC4-HMAC). Alert on any 0x17 in 4769 once the directory is supposed to be AES-only.

D. Combined view in this pcap

Pattern	Hits in `krb-816.pcapng`	Interpretation
KDC_ERR_PREAUTH_REQUIRED (25)	0	Client pre-emptively sends PA-ENC-TIMESTAMP — healthy
KDC_ERR_ETYPE_NOSUPP (14)	1	Cipher renegotiation only — `des`’s key is DES-only; benign in 2005, would be a finding today
AS-REP with no preceding PA-ENC-TIMESTAMP	0	No AS-REP-roasting signature
TGS-REP ticket etype 23 (RC4)	12 / 12	Kerberoasting exposure: every service ticket is offline-crackable at hashcat 13100

Method. One pcap rendered with VisualEther via its MCP integration with Claude — explore for the master Kerberos sequence diagram (32 frames keyed by msg-type, cname, sname, etype, padata) and extract_sessions for the per-user AS/TGS dialogues (3 success::as-rep, 12 success::tgs-rep, 1 failure::error). Field tables read directly from the rendered NDJSON; the detection cheat-sheet maps each wire pattern to its Wireshark filter, Event-ID equivalent and remediation knob.

1. One full cycle — user des, target host/xp1.denydc.com

2. What KDC_ERR_PREAUTH_REQUIRED actually looks like