Your out-of-hours provider closed a 4769 RC4 service-ticket burst unaided. What authority should it have had?

## What the records actually say A Windows domain controller logs event ID **4769** when a Kerberos service ticket is requested. The record carries the requesting account, the service principal name (SPN) the ticket is for, the client address, a failure code, and the ticket encryption type. `0x17` is RC4-HMAC; `0x12` is AES256. Kerberoasting works by requesting service tickets for accounts that have an SPN, preferring RC4 because that ticket is encrypted with a key derived from the service account's password and can be attacked offline. So a burst of 4769 records for many different SPNs, from one workstation, at 04:00, with encryption type `0x17` in an estate that has otherwise moved to AES, is a strong behavioural signal. Be precise about what it proves. It proves **tickets were requested and the domain controller issued them**. It does not prove a password was cracked — that happens offline, produces no event, and may never succeed. It does not prove any service was authenticated to. It does not even prove the requesting user was present at the keyboard: an accepted credential means a credential was accepted. This matters because the provider's escalation and your morning verdict must not overstate it. ## Why the provider structurally cannot close this The co-management arrangement means the provider's console receives your identity and directory telemetry, and its overnight tier-1 sees the raw 4769 records while your in-house analyst sees only whatever case the provider exports. The benign explanations for this pattern are all **estate facts**, not telemetry facts: - an authorised security assessment is running this week - a service-account inventory or password-audit script runs on a schedule - a legacy application enumerates SPNs at start-up - a vulnerability scanner was pointed at the domain last night - that workstation belongs to an engineer who is deliberately testing None of these can be seen in the ticket log. They live in a change calendar, an engagement notice, an asset register, or in a colleague's head. So a provider deciding "no action required" from the ticket log alone is not exercising judgment; it is guessing on the balance of how often such bursts have turned out benign for its other clients — a base rate from someone else's estate. That is the defect the contract has to fix. ## The authority clause worth writing Split by **the consequence of being wrong**, and grant three things separately: **1. Conclusions they may reach unaided.** Enumerate them by detection, not by severity. A rule the provider can fully evaluate from telemetry it holds — an alert that fires on a known-noisy internal scanner it also monitors — can be closed. A rule whose benign explanation lives in your change calendar cannot, no matter how low its severity. The test is not "is this important" but "is the deciding evidence inside their console". **2. A hold-and-hand-over disposition.** This is the clause most contracts lack. It is neither a close nor a wake-the-client escalation: the provider packages the evidence, records what it checked, states what it could not determine and why, and hands the case to the daylight analyst as an *open* case. Without this disposition the provider is forced into a binary of closing or waking someone, and it will drift toward closing. **3. Actions they may take alone.** Separate from conclusions. Isolating a host, disabling an account or revoking sessions may be worth granting for a small named set of behaviours where four hours of waiting costs more than being wrong — but every one of them is visible to an adversary and can be tripped deliberately to cause an outage on your behalf. Name a client contact who can be woken and the threshold at which they must be, and make the provider's default "collect and preserve", because the artefacts on a live host are the thing you cannot get back at 09:00. ## Two clauses people forget **Evidence access.** If the provider's console is the only place the raw records exist, and its retention is 30 days against your 12-month obligation, you cannot re-investigate later and you cannot support a claim you may need to defend. Require export of raw telemetry into your own store, not just the case summary. **Escalation content.** Specify what an exported case must contain — hypothesis, lookups run with results including the clean ones, what could not be determined, actions taken with timestamps — or you will receive a severity and a sentence. ## The morning answer With one in-house analyst who arrives at 09:00, the honest position is that you run 24x7 detection with next-day judgment on context-dependent cases, and you have deliberately accepted the resulting delay. That is a defensible posture as long as it is written, the exceptions where waiting is not acceptable are named, and the person accountable for the risk knows they signed it. What is not defensible is a provider quietly making those calls because nobody wrote down that it may not.