What is 'patient zero' in an intrusion, and why is the alerting host rarely it?

## What the term means **Patient zero** is the first asset in your estate that the intruder actually controlled: the start of the chain of compromise, not the start of your investigation. The epidemiology metaphor holds in exactly the part that matters. The case that gets noticed first is usually a downstream case, and finding the index case is separate work with its own evidence. 'Asset' is deliberately broad here: - a **host** — a laptop, a server, a build runner; - an **account or credential** — a service account, a client certificate, an API token. If the first thing the intruder controlled was a credential used from their own infrastructure, no machine of yours is patient zero and the identity is; - **something you do not own**, such as a contractor's laptop. Then the useful internal statement becomes *what did they first reach inside our boundary*, recorded alongside the external origin so the two are not conflated. ## Why the alerting host is usually not it Detections are written against behaviour that is both observable and unusual: an odd parent-child process pair, credential access, an unexpected outbound connection, an anomalous administrative action. Nearly all of that is **post-exploitation** behaviour. Initial access frequently looks like a well-formed authenticated session — a VPN session established with a valid client certificate, a token used from a plausible network, a build job started by a service account that starts build jobs every day. Nothing in those records is anomalous on its face, so no rule fires, and the first alert arrives only once the intruder does something a rule was written for. The practical consequence: the alerting host tells you where a rule fired. It carries no information about ordering. Treating it as the start of the intrusion is the single most common scoping error in this work, because everything downstream — reset scope, eradication list, what you tell anyone — inherits that wrong anchor. ## Two directions from the alert From the alerting entity you work in both directions at once: - **Backwards**, toward first foothold: how did this account or host come to be under adversary control, and from where? Each answer produces a new entity and a new earlier date, until you reach either the entry point or the edge of your evidence. - **Forwards**, toward spread: every host, account, credential and system this entity touched while under control, each with a date. The output is one dated picture, not a narrative: per entity, the earliest and latest observed adversarial activity, how it was reached, what it reached next, and the record that proves each cell. ## Getting the direction of each claim right Records support narrower claims than people read into them. A successful VPN authentication proves a **credential was accepted** by the concentrator, not that the named contractor was present or that their laptop was healthy. A build job log proves a **job ran** and what its steps emitted, not that the engineer named on the commit triggered it. An EDR alert proves a **detection fired**, not that something malicious happened. Patient zero is an assertion built from those narrow claims, so it is only as strong as the weakest link you did not qualify. Equally: **earliest observed** is not **earliest actual**. Your evidence gives an upper bound on when the intrusion started. It gives no lower bound at all unless you can argue coverage — that a source capable of showing earlier activity existed, was healthy and was searched. ## Why it matters operationally Three things hang off identifying the entry point: 1. **Eradication.** The entry path is what re-admits them. Remove implants on the hosts you know about and leave the accepted certificate valid, and you have cleaned up after an intruder who can walk back in the same way. 2. **Credential and secret scope.** Whatever was readable at the foothold — tokens on that laptop, secrets a build job could read — is the reset list. Anchoring on the wrong first asset gives you the wrong list. 3. **What you can say.** The start date shapes every statement made about the intrusion, and it is the claim most likely to be tested later. ## When it is never established Sometimes it is not found. Telemetry did not exist at the entry point, or existed and has aged out. That is a legitimate result, and the honest report says *earliest activity attributed to this intrusion is X, initial access is not established, and here is why* — rather than promoting the earliest thing you happened to see into a start date it cannot carry.