Which record do you write a Kerberos ticket-harvesting rule over — the domain controller's Windows Security 4769, endpoint process creation, or network flow?

## The decision is a choice among surfaces, not an audit of one record Assume for this argument that all three candidate surfaces are collected and arriving. The choice is still not free, because the surface you pick fixes two things about the rule permanently: **the population it spans** — whose behaviour it can ever see — and **its vocabulary** — the fields it can ever test, and the fields its alerts can ever carry. Thresholds, severities and tuning are all adjustable afterwards. These two are not. The behaviour is an adversary asking the KDC for service tickets belonging to service accounts, so their passwords can be attacked offline. Three surfaces could plausibly carry it, and they fail in different directions. ## Candidate A — the domain controller's ticket-issuance records Windows Security 4769 is written by a domain controller acting as the KDC when it issues a service ticket. It carries the requesting client principal, the service account the ticket was issued for, the client address, the ticket options, the encryption type and a failure code. **Population: complete.** Every service-ticket request in the domain goes through a domain controller, whatever asked for it — a managed workstation, an unmanaged laptop, a Linux host, or code running inside a process that started hours ago. There is no way to obtain the ticket while avoiding this surface. **Vocabulary: thin, and identity-shaped.** Account, service account, address, cipher. No process, no binary, no hash, no parent, no command line. Every rule you write here is therefore a statement about relationships between identities — which client asked, for which accounts, how many distinct ones inside a window — and every alert it produces names an account and an address and nothing more. **Base rate: enormous.** A domain controller writes these continuously, because every workstation requests tickets all day to reach file shares, print services and line-of-business applications. This surface hands you complete coverage and an expensive discrimination problem in the same breath. ## Candidate B — endpoint process telemetry Sysmon Event ID 1 (process creation) carries the image path, the full command line, the parent image, the user and file hashes; the native Windows 4688 carries the command line only where audit policy was configured to include it. **Vocabulary: the richest of the three.** Everything an analyst wants in an alert is already in the record, and a rule can condition on any of it. **Population: the narrowest, and narrow exactly where it hurts.** A rule here spans "Windows hosts running the agent, on which a new process started". Both halves leak. A request issued from a Linux host runs nothing on any monitored Windows endpoint; a request made in-process by code already running starts no new process, so no record exists to read. The rule is not merely less complete than the domain-controller one — it is blind by construction to the executions least likely to be routine. ## Candidate C — the network A NetFlow or IPFIX record carries a five-tuple, packet and byte counts and timestamps, and carries no payload at all. So it can establish that a client spoke to a domain controller on the Kerberos port and moved a few kilobytes — which every domain-joined machine does throughout the day. It cannot name the service account the ticket was asked for, because that lives inside the exchange the record does not contain. There is nothing here to condition on except volume. ## Making the choice Rank by population first, vocabulary second, and only then look at volume. That ordering picks the domain-controller record: a rule with rich fields over a population that excludes your adversary is worth less than a rule with thin fields over everyone. What you have bought is a rule whose conditions must be built out of identities and counts — which client account, asking for which kind of account, how many distinct ones — and whose alerts arrive without the context an analyst instinctively reaches for. ## Where the choice is actually felt **Enrichment moves out of the rule and into triage.** The alert names a client address and an account. Turning that into a host, a process and a person is work done after the rule fires: resolve the address, pull that host's records for the window, look at who was logged on. Where the host is monitored you get context; where it is not, you get nothing — and nothing is a triage outcome, not a broken rule. **A join across surfaces silently narrows the population to the intersection.** The tempting fix for the base rate is to require a second condition from another surface, but every such join re-imposes the narrower surface's blind spot on the wider one. The sharpest version of this mistake is requiring a matching successful-logon record on the service host: harvesting exists precisely to take the ticket away and never present it, so that condition suppresses the case you care about and keeps the ones you do not. ## How to answer it Name the candidates, give each one's population and vocabulary in a sentence, choose on population, then say out loud what your alerts cannot carry and where you recover it. Picking the endpoint because its fields are nicer, or bolting on a cross-surface join without noticing it has shrunk who the rule can see, is the failure the question is looking for.