Guided lab: six service tickets in four seconds
A burst of Kerberos service ticket requests from one workstation, every one of them legitimate as far as the domain controller is concerned. Find what makes the cluster abnormal, separate it from a legacy application, and say what the log cannot tell you.
- ATT&CK
- T1558.003
The call
2026-09-04. A weekly hunt across the domain controllers at Wrenfield Veterinary Group turns up a cluster on WREN-DC-03 that nobody alerted on, because nothing in it failed. Every request succeeded, which is the point.
Artifact 1: the cluster
Event 4769, Security log on WREN-DC-03. Machine accounts and krbtgt removed.
Time Account Name Service Name Client Address Ticket Enc Ticket Options Failure
15:03:11 j.marchetti@WRENFIELD svc-sql ::ffff:10.13.5.119 0x17 0x40810000 0x0
15:03:11 j.marchetti@WRENFIELD svc-backup ::ffff:10.13.5.119 0x17 0x40810000 0x0
15:03:12 j.marchetti@WRENFIELD svc-scan ::ffff:10.13.5.119 0x17 0x40810000 0x0
15:03:13 j.marchetti@WRENFIELD svc-deploy ::ffff:10.13.5.119 0x17 0x40810000 0x0
15:03:14 j.marchetti@WRENFIELD svc-print ::ffff:10.13.5.119 0x17 0x40810000 0x0
15:03:14 j.marchetti@WRENFIELD svc-web ::ffff:10.13.5.119 0x17 0x40810000 0x0
And the same account's requests for the rest of that day, for comparison:
Time Account Name Service Name Client Address Ticket Enc Ticket Options Failure
08:52:40 j.marchetti@WRENFIELD WREN-FS-02$ ::ffff:10.13.5.119 0x12 0x40810000 0x0
08:52:41 j.marchetti@WRENFIELD WREN-DC-03$ ::ffff:10.13.5.119 0x12 0x40810000 0x0
13:17:05 j.marchetti@WRENFIELD WREN-FS-02$ ::ffff:10.13.5.119 0x12 0x40810000 0x0
Q1
Nothing here failed and the account is a real employee's. List every property of the 15:03:00 cluster that differs from the account's normal behaviour.
Stuck? Where to look
Compare the two blocks column by column, and then look at the clock.
Show the answer
Three things, and it is the combination that matters.
The service names. Normally this account asks for tickets to computers, the names ending in a dollar sign: a file server, a domain controller. The cluster asks for six user-backed service accounts, which an ordinary workstation has no reason to talk to, least of all the backup and deployment services.
The encryption type. 0x12 is AES256, the default in a modern domain.
0x17 is RC4-HMAC. Every request in the cluster is RC4 and nothing else this
account did all day is.
The rate. Six distinct services in four seconds is a script walking a list, not a person opening an application.
Q2
Why would an operator go out of their way to get RC4 tickets, when the domain hands out AES by default?
Stuck? Where to look
Ask what key a service ticket is encrypted with, and who knows that key.
Show me the method
Read the description of the technique. The ticket is useful to the operator offline, after they have left the network.
Show the answer
Part of a service ticket is encrypted with a key derived from the service account's password. Any authenticated user may request a ticket for any service, so any user can obtain a blob encrypted with that key and take it away to guess passwords against, offline, with no lockout and no further log.
With RC4 the key is the account's NT hash, unsalted and fast to test. AES keys are salted and run through thousands of iterations, which makes each guess far more expensive. So tooling asks for RC4, and a domain that still permits it obliges.
That is why the technique targets accounts a person set a password on. A machine account's password is 120 random characters and rotates itself; nobody is cracking that.
Q3
Wrenfield Veterinary Group has an old document management system that only speaks RC4, and it
produces 0x17 tickets all day. Write the condition that alerts on the cluster
above without alerting on that application.
Stuck? Where to look
The legacy application is one client asking for one service, repeatedly. Count something the attack has many of and the application has one of.
Show the answer
Count distinct service names per requesting account per short window, among RC4 requests for user-backed services:
- ticket encryption type
0x17 - service name does not end in a dollar sign and is not krbtgt
- more than three distinct service names from one account within one minute
The legacy system scores one. The cluster scores six. A threshold of three leaves room for an administrator who genuinely touches a couple of services.
A quieter operator requests one ticket an hour and defeats the rate. That is why the second half of the defence is structural: a honey service account with an SPN that nothing legitimate ever requests, where a single 4769 is the alert.
Q4
What can event 4769 never tell you about this incident, and where would the answer show up if it shows up at all?
Stuck? Where to look
Everything that matters happens after the operator has the tickets, and none of it happens on your network.
Show the answer
It cannot tell you whether any password was cracked. The cracking is offline. The domain controller's involvement ended at 15:03:14.
Success shows up later, as the use of a service account: event 4624 for svc-sql or svc-backup from a host that account has never logged on from, or an interactive logon by an account that should only ever run as a service. Build that baseline now, because on the day it matters you will want to know what normal looked like.
Until then, assume the weakest of the six passwords has fallen. Rotate all six to long random values, and treat how j.marchetti's session on FIN-WS-002 came to be running the request as the actual intrusion to investigate.
What to do with it
Observed: one account requested RC4 service tickets for six user-backed services in four seconds from FIN-WS-002. Assessed, with high confidence: Kerberoasting. Unknown: whether any ticket was cracked.
Move service accounts to group managed service accounts where the application supports it, which gives them long rotating passwords nobody chose. Where it does not, set passwords of 25 characters or more, enable AES on the accounts and remove RC4 from their supported encryption types. Then find out who was at FIN-WS-002's keyboard, or what was.
Argue underneath
The honey account is one alert with no false positives. The rate rule needs tuning forever. Is there any argument for building the rate rule first?
Sources
The scenario above is invented. These are what its real half rests on.
Discussion
GuidelinesSign in to comment. Corrections and additions are the point: this is a working document.