Detecting Kerberoasting and AS-REP Roasting via TGS-REQ Analysis and Ticket Extraction

Why This Matters

Kerberoasting was the primary lateral movement technique used in the 2019 Wipro breach. Attackers compromised one privileged service account via phishing, then used it to request Kerberos service tickets for dozens of additional service accounts — all over legitimate Kerberos protocol traffic. Because TGS-REQ requests are indistinguishable from normal authentication traffic without baseline analysis, the activity went undetected for weeks. Defenders who can recognise anomalous Kerberos patterns in PCAP and extract ticket hashes for offline analysis can both reconstruct attacker activity and validate whether cracking was feasible.

Core Concept

Kerberoasting targets the TGS (Ticket Granting Service) exchange. An authenticated domain user requests a TGS ticket for any service principal name (SPN) registered in Active Directory. The KDC encrypts the ticket's service portion with the service account's NTLM hash. An attacker with any valid domain account can request tickets for service accounts and attempt offline dictionary attacks against the encrypted blob.

AS-REP Roasting targets accounts with Kerberos pre-authentication disabled. Normally, a KDC requires the client to prove knowledge of their password before issuing an AS-REP. When pre-auth is disabled, the KDC issues an AS-REP to anyone who asks, and the response's encrypted timestamp blob is encrypted with the account's NTLM hash — again attackable offline.

PCAP indicators: - Kerberoasting: multiple TGS-REQ messages from one client to different SPNs within a short window (legitimate users request 1–5 service tickets per day; Kerberoasting generates dozens in minutes). - AS-REP Roasting: AS-REQ messages without the PA-ENC-TIMESTAMP (padata type 2) pre-authentication field. - Encryption type: RC4-HMAC (etype 23) requests are the classic Kerberoasting indicator — tools request RC4 because it is faster to crack than AES. Modern defences use AES-only SPNs.

Technical Deep-Dive

# Show all Kerberos traffic
tshark -r capture.pcap -Y "kerberos" 
  -T fields 
  -e frame.number 
  -e frame.time_relative 
  -e ip.src 
  -e ip.dst 
  -e kerberos.msg_type 
  -e kerberos.sname.name_string 
  -e kerberos.etype 
  -E header=y -E separator=","

# Filter TGS-REQ messages (msg_type 12) and show requested SPNs
tshark -r capture.pcap 
  -Y "kerberos.msg_type == 12" 
  -T fields 
  -e ip.src 
  -e kerberos.sname.name_string 
  -e kerberos.etype

# Count TGS-REQ per source IP within the capture — high count = Kerberoasting
tshark -r capture.pcap -Y "kerberos.msg_type == 12" 
  -T fields -e ip.src 
  | sort | uniq -c | sort -rn

# Detect AS-REP Roasting: AS-REQ (msg_type 10) without PA-ENC-TIMESTAMP (padata type 2)
# These have no pre-auth; look for AS-REQ messages where padata type 2 is absent
tshark -r capture.pcap 
  -Y "kerberos.msg_type == 10 && !kerberos.padata.type == 2" 
  -T fields -e ip.src -e kerberos.cname.name_string

# Extract AS-REP encrypted blob for offline cracking (msg_type 11)
tshark -r capture.pcap -Y "kerberos.msg_type == 11" 
  -T fields -e kerberos.cipher | head -5

from impacket.krb5 import asn1 as krb5_asn1
from pyasn1.codec.der import decoder as asn1_decoder
import binascii

# impacket GetUserSPNs.py output format conversion for hashcat mode 13100
# In a CTF: extract the encrypted part from Wireshark "kerberos.ticket.cipher" field
# Format: $krb5tgs$23$*user$realm$SPN*$<hash_first_16_hex>$<remaining_hex>

def format_tgs_hash(cipher_hex: str, username: str, realm: str, spn: str) -> str:
    """
    Convert raw TGS-REP cipher hex to hashcat 13100 format.
    The cipher field from Wireshark is the encrypted ticket + enc-part combined.
    """
    cipher_bytes = bytes.fromhex(cipher_hex.replace(":", ""))
    # First 16 bytes are the checksum; remainder is the encrypted blob
    checksum = cipher_bytes[:16].hex()
    encrypted = cipher_bytes[16:].hex()
    return (
        f"$krb5tgs$23$*{username}${realm}${spn}*"
        f"${checksum}${encrypted}"
    )

# Example (values would come from tshark field extraction)
# print(format_tgs_hash("aabbcc...", "svc_sql", "CORP.LOCAL", "MSSQLSvc/db.corp.local:1433"))

# For AS-REP hashes (hashcat mode 18200):
def format_asrep_hash(cipher_hex: str, username: str, realm: str) -> str:
    cipher_bytes = bytes.fromhex(cipher_hex.replace(":", ""))
    checksum = cipher_bytes[:16].hex()
    encrypted = cipher_bytes[16:].hex()
    return f"$krb5asrep$23${username}@{realm}:{checksum}${encrypted}"

Analytical Methodology

1. Apply display filter kerberos in Wireshark to isolate all Kerberos traffic. Note the total message count and the capture duration — a healthy domain controller sees dozens of Kerberos exchanges per hour; Kerberoasting generates dozens in under a minute from a single client.
2. Filter TGS-REQ messages (kerberos.msg_type == 12). For each, note the requesting client IP, the target SPN (kerberos.sname.name_string), and the requested encryption type (kerberos.etype). RC4-HMAC (etype 23) requests are the classic Kerberoasting signature.
3. Group TGS-REQs by source IP. An IP requesting tickets for 10+ distinct SPNs within 5 minutes is almost certainly Kerberoasting. Legitimate users request service tickets lazily, only when they connect to a service.
4. For AS-REP Roasting, filter AS-REQ messages (kerberos.msg_type == 10). Inspect the padata section: a missing PA-ENC-TIMESTAMP (padata type 2) indicates pre-authentication was not sent — this is either a misconfigured account or deliberate AS-REP Roasting.
5. Extract the encrypted ticket blob from TGS-REP (kerberos.msg_type == 13) using the kerberos.ticket.cipher field in tshark. Convert to hashcat format 13100 (TGS) or 18200 (AS-REP) for offline cracking assessment.
6. Identify the targeted SPNs: common high-value targets are MSSQLSvc (SQL Server), HTTP (IIS/web apps), cifs (file shares), and custom application service accounts. Document the SPN list as it reveals which services the attacker sought to compromise.
7. Cross-reference the attacking client IP with authentication logs (Windows Security Event 4769 for TGS requests) to identify the user account used to initiate the roasting and trace back to the initial compromise.

Common Analytical Errors

• Expecting Kerberoasting to look "malicious": TGS-REQ messages for legitimate SPNs are indistinguishable from normal Kerberos traffic at the packet level. Only volumetric analysis (many SPNs in a short time) and encryption type (RC4 preference) reveal the attack.
• Missing AES-based Kerberoasting: Modern Kerberoasting tools (Rubeus with /rc4opsec suppressed) request AES-256 tickets (etype 18) to avoid etype-23 detection rules. Do not exclusively filter on etype 23.
• Confusing TGT and service ticket exchanges: The AS-REQ/AS-REP exchange issues a TGT; the TGS-REQ/TGS-REP exchange issues a service ticket. Only TGS-REP tickets encrypted with service account credentials are crackable in Kerberoasting. The TGT is encrypted with the krbtgt account hash and is not targeted.
• Overlooking the encrypted authenticator in TGS-REQ: The TGS-REQ contains an encrypted authenticator (wrapped in the AP-REQ within the padata). This is encrypted with the client's TGT session key and does not represent the crackable material — only the cipher field in the TGS-REP ticket matters.
• Skipping SPN analysis: The specific SPNs targeted tell you which service accounts the attacker wanted to compromise. Failing to document these prevents defenders from rotating the correct passwords after the incident.

NICE Framework Alignment

Further Reading

• "Kerberoasting Without Mimikatz" — Will Schroeder (@harmj0y), harmj0y.net blog (2016) — the definitive technical explanation
• The Hacker Playbook 3 — Peter Kim, Chapter 8: Active Directory Attacks (No Starch Press)
• Microsoft Security Blog: "Detecting Kerberoasting Activity" — defender-oriented detection guidance