A foothold artefact predates your intrusion timeline by six months: how do you test it before moving patient zero back?
answer
- proximity in time is not linkage
- list the competing explanations first
- look for a shared unique artefact
- reconcile against sanctioned activity
- corrections must follow the date everywhere it went
basics
~20 sTreat it as a hypothesis, not a finding. Test for positive linkage — shared unique artefacts, credentials, infrastructure — check continuity across the gap, and reconcile it against records of authorised activity before re-dating anything.
solid answer
~50 sBeing the earliest suspicious thing you found is not evidence of anything. List the competing explanations first: the same intruder six months earlier, a different and unrelated intrusion, authorised testing or an administrator doing something that looks terrible, or a re-used tool that is not attributable to anyone. Then test by positive linkage rather than proximity — the same client-certificate serial, the same operator-created account, the same distinctive command sequence, ideally with some activity bridging the gap — because a shared tool family or technique links nothing. Reconcile against records of sanctioned assessment activity and the change record for that window. In the case that bit us, the artefact belonged to an authorised assessment, so patient zero moved forward rather than back, and the correction had to be propagated everywhere the earlier date had already travelled.
go deeper
Know that an older suspicious artefact is a hypothesis, and that using the same tool or technique does not make it the same intrusion.
Be ready to list the competing explanations for an earlier artefact and name the specific evidence that would separate them.
Show the linkage test you apply, the continuity check across the gap, the reconciliation against authorised activity, and how you propagate a corrected date.
Own the claim language across the organisation so that re-dating is a correction to a bounded statement rather than a public retraction.
## The bias this question is testing Scoping has a strong pull toward *the earliest suspicious thing I found must be the start*. It feels rigorous — you went further back than anyone else — and it is the most expensive mistake available at this stage, because a wrong anchor propagates into reset scope, eradication lists, and statements you may later have to withdraw. So treat an earlier artefact as a **hypothesis with competitors**, and write the competitors down before you start: 1. the same intruder, six months earlier, dormant or slow in between; 2. a **different, unrelated** intrusion that happens to touch the same host; 3. **authorised activity** — an internal red team, a contracted assessment, an administrator or an automation doing something that looks exactly like tradecraft; 4. an artefact that is simply **not attributable** — a commodity tool, a leftover from an old build, something that arrived by a route nobody can reconstruct. ## Linkage, not proximity What would actually justify moving patient zero back is **shared unique artefacts**: - the same **client-certificate serial** or the same stolen credential; - the same **operator-created account**, with the same naming quirk; - the same **tooling by hash**, not by name; - the same distinctive **command sequence** or the same specific infrastructure; - **continuity** across the gap: any activity at all bridging the six months. What does **not** justify it: the same technique, the same commodity tool family, the same host, or the fact that both events look bad. Technique overlap is the weakest form of evidence in this domain, because widely-used behaviours are widely used. A dormant operator is possible, but silence over six months is a claim that has to be argued from something, not assumed because it makes your story tidier. ## The check that most often removes it Reconcile against **authorised activity**. Sanctioned assessments produce artefacts indistinguishable from an intrusion by design: footholds, tooling, created accounts, credential access. Any estate that tests itself will have this material sitting in the past, and if you have not reconciled the window against the record of sanctioned activity and the change record, you are one step from attributing your own testing programme to an adversary. When that check lands — as in this case, where the artefact belonged to an authorised assessment — patient zero is re-dated **forward**, back to the earliest activity you can actually attribute. That is a real result and it strengthens the report. ## Both errors cost, in different currencies - **Moving it back wrongly**: an over-broad credential reset, an inflated claim about dwell that you cannot support, and a start date quoted onward that you may have to retract. Retractions do more damage to a report's credibility than an honest unknown ever does. - **Failing to move it back when the linkage was real**: the entry path stays open and you eradicate around an intruder who is still holding the way in. So the test is symmetric. You are not looking for reasons to keep your existing date; you are looking for evidence that separates the hypotheses. ## Propagating a correction A re-dating is not done when you change the table. Dates travel fast — into the reset scope, the eradication list, briefing notes, statements to counsel, anything already issued. Keep a list of where the date went, and when it changes, walk it. Record the correction with its reasoning and its evidence rather than quietly overwriting, because the fact that an earlier artefact was considered and excluded is itself a finding somebody will ask about. And note the assessment finding separately: a sanctioned exercise reached that host by some path, and it is worth knowing whether that path was still open to the actual intruder. ## Write claims that survive correction The wording you choose in the first draft decides whether a later change is a correction or a retraction. Assert **'earliest activity attributed to this intrusion is 4 March, per these records'**, not **'the intrusion began on 4 March'**. The first is a bounded claim about evidence and moves gracefully when the evidence moves. The second is a claim about the world, and every revision of it looks like the investigation was wrong rather than the evidence being incomplete.
- What linkage would actually justify moving patient zero back six months?Shared unique artefacts rather than shared behaviour: the same certificate serial or stolen credential, the same operator-created account, the same tooling by hash, the same distinctive command sequence or specific infrastructure — ideally with some activity bridging the gap. A common technique or a commodity tool family links nothing on its own.
- The earlier artefact turns out to be from an authorised assessment. What still has to happen?Re-date the earliest attributed activity forward, then walk the correction everywhere the old date went: reset scope, eradication list, briefings, anything issued. Record the reasoning rather than overwriting silently. And keep the assessment observation as a finding in its own right — that path existed, and it is worth knowing whether it was still open.
- How do you phrase the original claim so a correction like this is survivable?State what was observed and attributed, with a date and a citation: 'earliest activity attributed to this intrusion is 4 March'. That is a claim about evidence and it moves when the evidence moves. 'The intrusion began on 4 March' is a claim about the world, and changing it reads as a retraction rather than a refinement.
saying these in an interview costs you the question
- Adopts the earliest suspicious artefact as patient zero without linkage
- Treats a shared technique or tool family as proof of one actor
- Assumes six months of silence is normal dormancy without arguing it
- Never reconciles the window against authorised assessment activity
- Corrects the date internally but leaves it standing in issued material