What is 'patient zero' in an intrusion, and why is the alerting host rarely it?
answer
- first controlled, not first noticed
- detections fire on later, noisier stages
- work backwards and forwards from the alert
- can be an account, not a machine
- earliest observed is not earliest actual
basics
~20 sPatient zero is the first asset in your estate the intruder actually controlled. The host that alerted is only where a rule happened to fire, usually later in the chain, once the intruder moved and grew noisier.
solid answer
~40 sPatient zero is the first host, account or credential the intruder controlled inside your boundary; the alerting host is simply where a detection fired. Detections mostly cover post-exploitation behaviour, while initial access often looks like a normal authenticated session, so the first alert is typically several steps downstream. A concrete shape: an alert fires on a CI runner spawning an unexpected child process, and working backwards shows the entry was a VPN session days earlier authenticated with a client certificate lifted from a contractor laptop. The runner is where you noticed; the certificate and the laptop are where it started. Until you have identified the entry point you cannot bound credential-reset scope or argue that eradication closed the way back in.
go deeper
Be ready to define patient zero in one sentence and say plainly why the host that alerted is usually not it. Knowing that it can be an account rather than a machine already puts you ahead.
Explain the mechanism: detections cover post-exploitation behaviour, while initial access often arrives as a normal authenticated session that no rule fires on.
Show that you work an investigation in both directions from the alert, and connect the entry point to concrete containment, eradication and credential-reset scope.
Own what the organisation asserts when the entry point is never established, and insist that reports separate observed activity from inferred activity.
## 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.
- Can patient zero be an identity rather than a host?Yes. If the first thing the intruder controlled was a service account, a client certificate or an API token used from their own infrastructure, then no machine of yours is patient zero. You record the identity as the index case, the first internal asset it reached, and the external origin separately, so nobody later reads the first host as the entry point.
- Why bother finding the entry point if you have already contained every host you know about?Because the entry path is what re-admits them, and the secrets readable at the foothold set your reset scope. Containment on known hosts stops current damage; it does not revoke an accepted certificate, a refresh token or a service-account key that was taken earlier. Eradication that skips the entry point invites re-entry through the same door.
- The earliest thing you can see is lateral movement, not initial access. What do you write down?Write the earliest observed activity with its date and the record that shows it, and state explicitly that initial access is not established, with the reason: no telemetry covered that surface, or the window has aged out, or it has not yet been found. Keep the two as separate claims so neither is read as the other.
saying these in an interview costs you the question
- Says the first alert marks the start of the intrusion
- Assumes patient zero is always a workstation, never an account
- Reads a successful authentication as proof the named user was present
- Calls eradication complete without identifying the entry path
- Uses earliest evidence and earliest compromise interchangeably