Kerberoasting with VirtuProbe: from an SPN to a hashcat-ready hash.

Two of the most reliable moves against an Active Directory domain — AS-REP Roasting and Kerberoasting — come down to asking the KDC a polite question and cracking the answer offline. Here's how to run both at the wire in VirtuProbe, why talking straight to the KDC beats a wrapper, and how to chain the whole thing off an LDAP lookup.

Kerberos pre-authentication is one of those protocol details that turns into an attack the moment an account is configured slightly wrong. Both of the techniques here exploit exactly that: they get the KDC to hand back something encrypted with a key derived from a user's or service account's password, then crack it offline where no lockout policy can see you.

VirtuProbe's Kerberos probe talks directly to a Key Distribution Center with a hand-rolled RFC 4120 implementation — no GSSAPI, no third-party Kerberos library between you and the wire. That matters more than it sounds, and I'll come back to why. First, the two attacks.

The setup

Add a Kerberos probe and point it at the domain controller. The connection settings are minimal:

• KDC Host — the domain controller's hostname or IP.
• Port — 88 by default.
• Realm — the Kerberos realm, uppercase (e.g. LAB.LOCAL).
• UDP — on by default; the probe falls back to TCP automatically when the KDC sets the truncation bit or returns an error.

AS-REP Roasting — no password required

AS-REP Roasting targets accounts that have Do not require Kerberos pre-authentication set (DONT_REQUIRE_PREAUTH). Normally the client proves it knows the password by encrypting a timestamp before the KDC will respond. Turn pre-auth off, and the KDC will happily send back an AS-REP whose encrypted part is derived from the account's password — to anyone who asks, no password needed.

Set the probe's Operation to AS-REP Roast and give it just a username. No password. If the account is vulnerable, the response comes back with the hash already formatted for hashcat mode 18200:

$krb5asrep$23$jdoe@LAB.LOCAL:a1b2c3...16hex...$rest...

The hash lands in a copy-ready card labelled with its hashcat mode. Copy it and crack offline:

hashcat -m 18200 hash.txt wordlist.txt

If the account requires pre-auth (the normal case), you get a clean FAIL instead — no hash, no harm. Which makes this a fast enumeration sweep: fire it across a username list and the hits are the misconfigured accounts.

Kerberoasting — service tickets for any SPN

Kerberoasting goes one step deeper. With any valid domain credentials, you obtain a TGT, then request a service ticket (TGS) for a target Service Principal Name. The service ticket's encrypted part is sealed with the service account's password hash — so cracking it gives you that account's password, often a high-privilege service identity.

Switch the Operation to Kerberoast and fill in:

• Username + Password — any account you can already authenticate as.
• SPN — the service to request, e.g. HTTP/web.lab.local or MSSQLSvc/db.lab.local:1433.

The probe authenticates, pulls the TGT, requests the service ticket, and returns the hash in hashcat mode 13100 format:

$krb5tgs$23$*svc_iis*LAB.LOCAL*HTTP/web.lab.local*$a1b2c3...16hex...$rest...

hashcat -m 13100 hash.txt wordlist.txt

Why hand-rolled matters here

The probe implements RFC 4120 (Kerberos V5) and RFC 4757 (RC4-HMAC-MD5) from scratch — hand-written ASN.1 DER, the full MD4 NT-hash → key-derivation → RC4 → HMAC-MD5 path, UDP with TCP fallback. There's no library sitting in the middle deciding what's well-formed.

That's the difference between a tool that uses Kerberos and one you can probe it with. The Exchanges panel shows every message pair — AS-REQ / AS-REP, TGS-REQ / TGS-REP — down to the raw DER hex, exactly as it went on the wire, un-normalised. When a KDC does something subtly non-standard, that raw view is the difference between "it didn't work" and "here's precisely why."

The part other tools can't do: chain it

Running one roast is useful. The real leverage is that a Kerberos step is just another probe — so it drops into a chain alongside every other protocol. A natural Active Directory flow:

1. LDAP — query the directory for accounts with an SPN set (the Kerberoastable ones) and for accounts with pre-auth disabled (the AS-REP-roastable ones).
2. Iterate — drive a Kerberos step over that list with an ITERATE loop; feed it from the LDAP result or a wordlist file, with jitter between requests and stop-on-first-success if you want it.
3. Extract — pull each result into the chain with KERBEROS_SUCCESS, KERBEROS_HASH and KERBEROS_ERROR_CODE, and collect the crackable hashes as evidence.

That's enumeration and roasting in a single runnable artefact you can replay on the next engagement — instead of three CLI tools, a text file, and a shell loop you rewrite every time. Every run is saved to history with the realm and username, and exports as structured JSON for the report.

Jakub Stonavský is the founder and maintainer of VirtuProbe Studio, based in Prague. More about the project →