Detection Voyagers Lab: The Kerberoast Odyssey

Andrew VanVleet

Technical Architect - Threat Management | Author

Andrew VanVleet is a seasoned threat analyst with a passion for uncovering intrusions and decoding APT campaigns. He brings deep expertise in threat hunting, malware analysis, and incident response, with a track record of delivering end-to-end insights—from first detection to executive reporting.

Step 1: Know Your Adversary – Understand the Core Technique

Start with a crystal-clear grasp of the attack itself.

What is Kerberoasting?

If an attacker has a valid Ticket Granting Ticket (TGT), they can request a Ticket Granting Service (TGS) for any SPN (Service Principal Name). These TGS tickets are encrypted with the service account's NTLM hash — making them a goldmine for offline cracking.

Why it's powerful: No need for elevated access. No lateral movement. Just passive collection and cracking.

Step 2: Enumerate the Procedures – Build the Map

A technique is just the label. What matters are the procedures – the distinct ways an attacker can execute that technique. This is where DDM shines.

Andrew’s Kerberoasting DDM identifies four key attacker paths:

Enumerating SPNs via LDAP
- Tools: Rubeus, Impacket, SetSPN.exe
- Logs: LDAP queries, TGS requests
Enumerating SPNs via ADWS (Active Directory Web Services)
- Tools: PowerShell’s Get-ADUser, DirectorySearcher
- Logs: WSMAN, ADWS queries
Sniffing TGS Tickets off the Network
- Requires privileged network access (e.g., relay attacks)
- Detection: Unusual packet captures, lateral movement
Harvesting TGS Tickets from Endpoints
- Techniques: Memory scraping, LSASS access
- Tools: Mimikatz, Rubeus (via sekurlsa), custom dumpers
- Logs: Sysmon (proc access), ETW traces

Bonus Thought: Think like a red teamer. Ask, "Is there another path to the same result?" That's how new procedures are born.

Step 3: Explore the Enumeration Landscape

Andrew pushes detection engineers to investigate non-obvious methods, like:

.NET DirectorySearcher
ADWS PowerShell cmdlets (Get-ADUser -Properties ServicePrincipalName)
Client-side filtering, as seen in Impacket’s “stealth” mode, where all users are pulled and SPNs filtered post-query.

🔎 Detection Insight: Telemetry changes based on where the filtering happens (server-side vs client-side). This nuance matters when building logic.

Step 4: Log Telemetry – Fuel for the Mesh

Procedure	Detection Method
Key Logs / Telemetry	Key logging tools, user telemetry collection
LDAP Enumeration	LDAP bind & search, Event ID 4769
ADWS	PowerShell logging, WSMAN, ADWS calls
Ticket Sniffing	Network TAPs, PCAPs, suspicious network tools
Ticket Harvesting	Proc/thread access, LSASS read, memory dumps, ETW

🛰️ Don’t chase noise. Build a modular telemetry layer where each log source maps to a procedure path.

Step 5: Build the Detection Data Model (DDM)

Now the real engineering begins: draw out the DDM.

Each node = a procedure
Each edge = a logical or temporal link
Annotate with:
- Tool examples
- Required permissions
- Associated logs
- Known evasion tricks

Andrew’s DDM lays it out like a map. It’s not just what’s detectable — it’s what paths exist, and which you can detect.

“Our strategy is to deploy the best possible mesh and document our known gaps.” – Andrew VanVleet

Step 6: Design the Detection Strategy

With your DDM in place, define how each node is defended or left open:

Tag known gaps (e.g., ADWS enumeration lacks solid logging).
Define your coverage mesh — which procedures can you reliably catch?
Use detections + contextual flags for partial visibility.

🎯 Example: You may not detect an attacker pulling SPNs via ADWS directly, but you can catch the TGS request (Event ID 4769) that follows.

Step 7: Harden the Environment Based on DDM Learnings

DDMs aren’t just for the SOC. They’re for security architects too.

Based on your detection analysis, advocate for:

Disabling RC4 to prevent crackable ticket encryption.
Strong SPN account passwords to resist brute-force attempts.
Service account segmentation, so roasting doesn't yield crown jewels.

📢 Detection becomes a conversation starter, not just an alert generator.

Step 8: Document. Share. Iterate.

This is where Andrew's philosophy shines:

Record every procedure, tool, log source, and detection outcome.
Share DDMs across blue and red teams.
Refresh quarterly to capture tooling shifts and new procedures.

“Detection isn’t just about rules. It’s about understanding the attacker’s decision tree — and breaking branches before they can reach you.” – AVV, probably

Bonus Resources

📖 DDM vs MITRE Blind Spots – Andrew’s Blog

Final Thoughts: Why This Matters

This isn't just a Kerberoasting workshop — it's the standard blueprint for how detection engineering is done in 2025, AVV leads the way all day. With the DDM method, you're not just reacting — you're anticipating attacker behavior, visualizing coverage, and hardening against entire classes of threat activity.