A service account's baseline shows Sunday-night logons only, and last night it authenticated to eighty hosts at 03:00 — how do you reach a verdict?

## Decompose before you react The worst move is to treat "the account broke its baseline" as one fact. It is at least four, and each has a different explanation and a different failure mode: 1. **The hour moved** — the baseline said Sunday 22:00–23:00; this was Wednesday 03:10–03:48. 2. **The population roughly doubled** — from around forty hosts to eighty. 3. **The logon type set changed** — the baseline held type 5 (Service) on two management servers and type 3 (Network) on the fleet; last night added type 10 (RemoteInteractive) on three hosts. 4. **The source addresses** — most events sourced from the two management servers; the interactive ones from a different address entirely. A single explanation that covers points 1 and 2 does not automatically cover points 3 and 4, and the commonest analytical error here is letting a plausible story close the whole set. ## What each record actually proves A Windows Security **4624** is a *successful logon*: it proves a credential for that account was accepted by that host. It does not prove a person was present, and it does not prove a process ran. The logon type is where the meaning lives — type **3** is a network logon, which is what remote execution over SMB or WinRM produces and what a fan-out patch run looks like; type **5** is a service logon; type **2** is an interactive console logon and type **10** is RemoteInteractive, the signature of an actual remote-desktop session. Eighty type-3 logons are consistent with a machine doing a job. Three type-10 sessions mean somebody had a desktop, and that somebody needs a name. ## Hunt for the disconfirming evidence A verdict is built by trying to break the benign explanation, not by collecting support for it: - **Change records.** Was there an approved change moving the patch window? Does its date, time and scope match what you observed, or is it merely nearby? - **The tool's own logs.** The deployment or patch platform records which hosts it targeted, at what times, with what result. If its job covers the same eighty hosts within the same thirty-eight minutes, the type-3 logons are explained by a system, not by an assertion. - **The source.** Are all eighty sourced from the two management servers you already baselined? One event sourced from a workstation, a jump host, or an address outside the management range is worth more than the other seventy-nine combined. - **The edges of the window.** Does the activity stop when the job log stops? Activity continuing after the job ends is the classic tell that something rode in alongside it. - **The scope.** Are all eighty hosts in the patch tool's scope, or did the account touch anything it has no business touching — a domain controller, a finance server, a jump host? - **The account itself.** Was its password or key changed recently, is it a member of anything new, and did anything else authenticate as it from elsewhere in the same period? ## Talking to the owner The platform engineer will very likely explain it in one sentence: the maintenance window moved to Wednesday, the fleet grew when a business unit was onboarded, and they logged into three machines by remote desktop to watch the first run of the new schedule. That explanation is exactly what you want — and it is a hypothesis, not a verdict. It is checkable in minutes: the change record, the job log, and their own account's authentication trail during the same minutes. Ask for it in a way that gets the change history rather than a defence, because the person who can explain what your baseline missed is the same person you need to hear from *before* the next window moves. And be honest about what an explanation from an owner is worth on its own. An adversary with the account's credential also produces confident owners, because the owner is describing what they *intended*, not what the estate recorded. ## The verdict and its name If the change record, the job log, the source addresses and the interactive sessions all reconcile, the correct outcome is a **benign true positive**: the activity was real, it genuinely deviated, and it was authorised. That is not a failed hunt and not a false positive — nothing was wrong with the observation, only with the baseline's assumptions. ## The output is a re-cut baseline A hunt lead that closes benign still has to produce something, or the same eighty hosts cost you the same afternoon next month. Re-cut the baseline with the new window and new host count, and record what you learned about its assumptions: the patch schedule is now Wednesday 03:00, scope is eighty hosts and growing, and interactive logons by this account are still *not* baselined — they remain a finding, and a named engineer is the only thing that explains one. Write down what invalidates the new baseline: the window moving again, another onboarding wave, or the tool changing its execution method. Then close the loop with the platform team so the next change arrives as a notification rather than as a 03:00 anomaly. ## What would have flipped this Name these explicitly, because they are what separates a verdict from a rationalisation: a type-3 logon sourced from outside the management pair; a type-10 session no engineer will claim; activity continuing after the job log ends; hosts outside the patch scope; or the same account authenticating from a second source in parallel. Any one of those, and the benign explanation covers most of the events while leaving the interesting ones uncovered — which is exactly how a real intrusion hides inside a legitimate change.