Your purple team Kerberoasted the forest and nothing fired — which observable can a detection actually build on?

## The exercise A purple-team engineer harvested Kerberos service tickets for service accounts across the forest and reported that nothing fired. The productive question in the room is not whose fault the miss is. It is: **which record could ever have betrayed this, and which field inside it is the adversary forced to dirty?** ## Forced versus optional Work out what the behaviour cannot happen without. To attack a service account's password offline you need a ticket encrypted under that account's key. Only the KDC can issue one, and you must ask it for the specific service. Therefore, on every attempt, a domain controller writes a service-ticket record (Windows Security 4769) naming the target service account and whichever domain account asked. **That is the invariant.** Any domain user with a valid ticket-granting ticket can do the asking; there is no privileged step to catch. Now list what is *not* forced, because each is a detection people build and each is optional to evade: - **Encryption type.** Requesting RC4 (`0x17`) rather than accepting AES256 (`0x12`) makes the offline attack cheaper, so tooling historically asks for it. But it is a choice: an adversary can take the AES ticket and spend more compute. A rule on the encryption type detects a *preference*, not the behaviour. - **Volume and fan-out.** Enumerating every service principal name in the forest and requesting all of them in ninety seconds is convenient. Requesting one account per week from a normal user's workstation is equally effective and sits inside any baseline. - **The source host.** The request can come from any domain-joined machine — or from a non-Windows host on the network running an open-source toolkit, in which case no monitored Windows endpoint runs anything at all. - **A new process.** Even on Windows the request can be made in-process from a running application, so there is no process-creation record (native 4688 or Sysmon Event ID 1) and no new binary to hash. If the tooling is a script in an interpreter you have configured to log script text, you may get that instead — but that is a property of your endpoint configuration and of their tool choice, not of the technique. **Conclusion: everything on the endpoint is contingent; the domain controller's ticket record is not.** That is where the detection has to live, if one can live anywhere. ## The invariant alone is not a detection Having found the forced record, apply the separation test honestly. A domain controller writes these records continuously: every workstation requests service tickets to reach file shares, print services and applications. The presence of the record carries no information whatsoever, so the discriminator must be a relationship among its fields. Two are worth arguing about: 1. **What kind of object the ticket was for.** Ordinary traffic overwhelmingly asks for tickets on *computer* accounts — the host's own services. Ticket requests for service names that resolve to *user* objects carrying service principal names are a much smaller population, and those are precisely the accounts worth attacking, because their passwords are human-set and static. Comparing the requested service against a maintained list of SPN-bearing user accounts is the sharpest cut available inside the record. 2. **Fan-out per requester.** One client account requesting tickets for many *distinct* SPN-bearing user accounts within a short window is a shape that ordinary work rarely produces, because a given workstation talks to a handful of services repeatedly rather than to twenty different service accounts once each. ## Say the weaknesses out loud Both discriminators are defeatable and you should state how in the same breath, because a detection engineer who oversells coverage is the problem this exercise exists to expose. Fan-out logic misses a slow, single-target request entirely. The object-type cut depends on an accurate inventory of which user accounts carry service principal names, which drifts as the estate changes. And the encryption-type field, the one most rules reach for first, is worthless in a forest whose service accounts have never been re-keyed and therefore hold no AES key: there, RC4 is simply what the KDC issues, and the field's value is identical for the purple team and for every legitimate connection to those services. ## The shape of a good answer Name the invariant first, justify it from the protocol rather than from tooling, then list what the adversary is free to vary and show that each freedom kills a detection someone might propose. Finish with the discriminator you would actually build, its false-negative shape, and — if the estate's base rate leaves nothing that separates — the willingness to write that down rather than ship a rule that cannot match.