Kerberos Attack Lab
An Active Directory compromise rarely looks dramatic in the logs — it is a burst of RC4 service tickets, a TGT the domain controller never issued, or a single quiet write to a computer object. Work a queue of real-world scenarios and make three calls on each: which attack it is — Kerberoasting, AS-REP roasting, a golden or silver ticket, unconstrained / constrained / resource-based delegation abuse, overpass-the-hash or pass-the-ticket — the detection signal that gives it away, and the one mitigation that actually closes it. Some scenarios are normal Kerberos dressed up to look hostile: flag those and the false alarm costs you. Clear the queue clean.
The real job. More noise, a tighter clock.
Kerberos triage queue
For each scenario, make three calls: the attack (or no attack), the detection signal, and the best mitigation.
#1
svc-sql gets roasted
env: corp.local · member of a DBA on-call rotation
Within two minutes, the workstation of a low-privileged contractor pulls Kerberos service tickets for a dozen SPN-bearing accounts, every one requested as RC4. The contractor opens no apps that would need them. Hours later, svc-sql authenticates from an unusual host.
Telemetry
- ·4769 × 12 from one user in ~90s — svc-sql, svc-iis, svc-backup, svc-crm …
- ·Ticket encryption type: 0x17 (RC4-HMAC) on every request
- ·No corresponding service access follows the ticket grants
- ·svc-sql password last set 2019; 14-char human-chosen
#2
The account that needs no pre-auth
env: corp.local · legacy identity left in the Users OU
An attacker with only a domain user list, no credentials, requests authentication data for every account and gets a usable response for one of them — an old service identity whose "Do not require Kerberos pre-authentication" box was ticked years ago for a broken appliance.
Telemetry
- ·4768 AS-REQ for svc-legacy succeeds with Pre-Authentication Type: 0
- ·No wrong-password lockout — the AS-REP is returned before any secret is proven
- ·Requests sweep the whole user list; only svc-legacy answers
- ·userAccountControl on svc-legacy includes DONT_REQ_PREAUTH
#3
A ticket from nowhere
env: corp.local · post-compromise, DC logs under review
A workstation accesses the file server, the PKI host and the Exchange back-end as "Administrator", yet the DCs have no record of issuing that user a TGT. The service tickets simply exist, and one carries a validity window of ten years.
Telemetry
- ·4769 service tickets present with NO preceding 4768 for the user
- ·Ticket lifetime: 10 years (policy max is 10 hours)
- ·PAC shows membership in groups the account was never added to
- ·Account RID in the ticket does not match the directory
#4
Access the DC never saw
env: corp.local · CIFS access to the finance file server
Someone reads finance shares on FS01 as a privileged user all afternoon. FS01 logs the access cleanly, but no domain controller anywhere issued a service ticket for FS01 to that user during the window. The attacker had already dumped the FS01 computer account’s hash.
Telemetry
- ·Service access on FS01 with NO matching 4769 on any DC
- ·Tickets accepted locally by FS01 only; KDC bypassed entirely
- ·FS01$ machine-account hash was dumped in an earlier host compromise
- ·PAC not validated against the KDC (common silver-ticket tell)
#5
One ticket, three desks
env: corp.local · helpdesk TGT flagged by UEBA
A helpdesk admin’s TGT, issued once at 08:59 from their own laptop, is then presented to request service tickets from two other workstations in different subnets within the hour — one of them a kiosk the admin has never logged into.
Telemetry
- ·Identical TGT (same session key / start time) seen from 3 source hosts
- ·Source IPs span two subnets; one host has no prior logon by this admin
- ·No 4768 re-issue — the same ticket is simply replayed elsewhere
- ·LSASS on the admin’s laptop was accessed by a non-standard tool minutes earlier
#6
A TGT born from a hash
env: corp.local · just after an endpoint was popped
Minutes after a workstation is compromised and the local secrets dumped, that host requests a brand-new TGT for a domain admin — but no one typed a password, and the request forces RC4 even though the domain prefers AES.
Telemetry
- ·4768 AS-REQ using a key, not an interactive logon (no 4624 type 2)
- ·Requested etype downgraded to 0x17 (RC4) though AES is available
- ·The RC4 key equals the account’s NTLM hash (the pass-the-key tell)
- ·Immediately followed by TGS requests for high-value services
#7
The service that could do AES, but didn’t
env: corp.local · modern DCs, AES enabled fleet-wide
The same roasting pattern as svc-sql, but here the targeted account svc-crm fully supports AES and the domain negotiates AES by default. The attacker’s tool explicitly requests RC4 to get a weaker, faster-to-crack ticket.
Telemetry
- ·4769 for svc-crm with requested etype 0x17 (RC4) — client-forced
- ·svc-crm’s msDS-SupportedEncryptionTypes includes AES128/AES256
- ·Normal CRM traffic for this account uses AES (0x12); this request does not
- ·Single source host pulling the ticket, no app launch
#8
The web server that collects TGTs
env: corp.local · WEB01 trusted for unconstrained delegation
WEB01 was configured for unconstrained delegation years ago. After an attacker coerces a domain controller to authenticate to WEB01 (a printer-bug style trigger), WEB01’s memory now holds the DC’s own TGT, ready to be replayed anywhere.
Telemetry
- ·WEB01 userAccountControl has TRUSTED_FOR_DELEGATION set
- ·Forwardable TGTs for other principals — including DC01$ — cached in WEB01 LSASS
- ·Coerced authentication from DC01 to WEB01 immediately prior
- ·WEB01 then presents DC01$’s TGT to request tickets
#9
A quiet change to a computer object
env: corp.local · APP02 computer object modified
A low-privileged user who happens to hold write access over the APP02 computer object sets a delegation attribute on it, then uses S4U to obtain a service ticket to APP02 as the domain admin — without ever knowing the admin’s password.
Telemetry
- ·5136 — msDS-AllowedToActOnBehalfOfOtherIdentity on APP02$ written
- ·Writing principal is a standard user with GenericWrite over APP02$
- ·S4U2Self + S4U2Proxy immediately follow, impersonating Administrator to APP02
- ·No password change on the admin account
#10
The account wearing twenty hats
env: corp.local · svc-mono, a decade of bolted-on SPNs
svc-mono is roasted like the others, but the striking thing in review is the account itself: it carries twenty-two SPNs accumulated over a decade, most for services long decommissioned. Every one of them is a crackable target tied to this single human-set password.
Telemetry
- ·4769 harvest against svc-mono, RC4 requested
- ·svc-mono has 22 registered SPNs; 15 map to retired hosts/services
- ·One shared password protects all 22 attack surfaces
- ·Account is a normal user object, not a managed service account
#11
Payroll run, 2 a.m.
env: corp.local · svc-payroll scheduled batch
An alert fires on svc-payroll requesting a cluster of service tickets overnight. On inspection it is the nightly payroll batch: the same three SPNs it has used every night for two years, all AES, from its own application server, right on schedule.
Telemetry
- ·4769 × 3 for the SPNs svc-payroll legitimately consumes (SQL, SMB, HTTP)
- ·Encryption type 0x12 (AES256) throughout — no RC4 anywhere
- ·Source host is svc-payroll’s own app server, as every prior night
- ·Volume and timing match a two-year baseline exactly
Catch rate vs. false alarms
Three calls per scenario, then grade. So far 0/33 points, 0/10 attacks named, 0 false alarm(s).
How it is scored
One point each for the right attack, detection signal and mitigation — three per scenario.
A false alarm (calling normal Kerberos an attack) takes an extra hygiene bite — a queue that cries wolf is as useless as one that misses.
Harder tiers add subtler scenarios and deliberate traps (golden vs. silver, RC4-downgrade roasting, clustered-gMSA activity that only looks like theft).
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based Active Directory / Kerberos attack lab: work a queue of ~15 realistic detection scenarios and, for each, name the attack, the signal that gives it away, and the single best hardening control.
- Attacks covered: Kerberoasting, AS-REP roasting, golden ticket, silver ticket, unconstrained / constrained / resource-based (RBCD) delegation abuse, overpass-the-hash (pass-the-key), and pass-the-ticket — plus benign scenarios that only look malicious.
- Detection is grounded in what the KDC actually logs — 4768 AS-REQ, 4769 TGS-REQ, 5136 directory changes, RC4 (0x17) vs. AES (0x12) encryption types, pre-auth flags and S4U2Proxy — not vibes.
- Mitigations are the real AD toolbox: group-managed service accounts (gMSA), AES-only (disable RC4/DES), strong SPN-account passwords, protect krbtgt + rotate twice, the Protected Users group, removing unnecessary SPNs, and requiring pre-authentication.
- You are graded on catch rate across all three axes, with a false-alarm penalty for calling normal Kerberos an attack, and after grading every scenario shows why the right call is right.
Frequently asked questions
What is the Kerberos Attack Lab?
A free, in-browser exercise where you triage a queue of Active Directory attack scenarios. Each scenario gives you the operator context and a snapshot of the telemetry a domain controller would log, and asks for three calls: which attack it is (or that it is normal activity), the detection signal that identifies it, and the single best mitigation. You are scored on how many you call correctly across all three axes versus how many benign scenarios you wrongly flag.
Which attacks and mitigations does it cover?
The attacks are Kerberoasting, AS-REP roasting, golden tickets, silver tickets, unconstrained / constrained / resource-based constrained delegation (RBCD) abuse, overpass-the-hash (pass-the-key), and pass-the-ticket. The mitigations are drawn from the real AD hardening toolbox: group-managed service accounts (gMSA), AES encryption instead of RC4 (and disabling DES/RC4), strong SPN-account passwords, protecting and double-rotating krbtgt, the Protected Users group, removing unnecessary SPNs, and requiring Kerberos pre-authentication.
Does it run real Kerberos or touch a domain?
No. Nothing connects to a KDC, no network traffic is generated and no cryptography runs. The scenarios are authored, realistic decoded telemetry summaries bundled with the page, and every call is deterministic — it runs entirely in your browser with no account, no install, and nothing sent anywhere.
Who is it for?
AD and identity engineers, blue-team analysts triaging domain-controller logs, red teamers who want to sharpen the detection-and-mitigation side, and anyone prepping for a security interview who wants to feel the difference between a golden and a silver ticket, spot an RC4-downgrade Kerberoast, and know why the Protected Users group and a gMSA are the levers that actually close these techniques.