Your EDR console keeps 7 days of events — how do you investigate an intrusion that began 45 days ago?

## Where the events actually are An EDR sensor is a recorder and a shipper. Raw events are not archived on the endpoint; the agent buffers briefly so an offline host does not lose everything, then streams to the vendor's platform. That has one consequence people are slow to internalise: **you cannot go back to the host to recover event history**. The box in front of you holds present state, not its own past. What you search instead is tiered, and the tiers behave differently: - **Hot, in-console:** the window analysts actually query interactively. In this estate, seven days. - **Vendor-side, longer:** thirty days here, reachable but not the same experience — retrieval by request or API, sometimes slower, sometimes coarser, sometimes a subset of event classes. - **On the host:** nothing. A reboot, a reimage or a rebuilt container takes nothing with it because nothing was there. A 45-day-old question is outside all three. That is the fact you build the investigation around, not the fact you argue with. ## Two different capabilities, and the distinction is the answer The sensor gives you **event history** and **live state**, and they have unrelated limits. Event history is everything the sensor recorded — executions, mapped objects, file writes, connections — and it is bounded by retention. Beyond the edge it does not thin out; it stops. Live state is what the host looks like right now: files present with their timestamps, processes running with their mapped objects, scheduled tasks and units, accounts. Most sensors expose this through a live query or live response capability. It is bounded only by whether the host still exists and whether the intruder tidied up — not by retention at all. So the 45-day question decomposes cleanly. The artefacts an intrusion created 45 days ago may still be on the disk. The **events** that created them are gone. Present state gives you objects to date and pivot on; the retained window gives you behaviour, but only for the last seven days of it. ## How you actually work it Go forwards, not backwards. Take what present state gives you — a file with a creation timestamp, a unit or cron entry, an account, a mapped object in a running process — and treat each as a dated anchor. Those anchors constrain *when* something happened even though no event describes it. Then search the retained window for the same process, the same paths and the same endpoints, which usually tells you whether the activity is still ongoing, which is the more urgent question anyway. Pivot across the fleet inside the window: if this is a campaign rather than one host, the other hosts may have been touched recently enough to be fully visible, and a host you can see completely is worth more than a host you can only half-see. ## Writing down what you do not know This is the part that separates a senior answer. Your timeline should read something like: ``` day -45 file /opt/app/.cache/libgs.so created (present-state timestamp; no event retained) day -7 start of retained EDR visibility day -6 daemon maps that object; four short-lived children; outbound connection day 0 hunt finds it ``` And then, explicitly: *earliest retained EDR event is day −7; the period before that has no telemetry retained; initial access vector is unknown from this source.* Two errors to refuse by name. First, **inferring the earliest link**: writing "initial access was a compromised deployment credential" because it is the likeliest story is fabrication wearing a timeline's clothes, and it is the claim that falls apart when someone asks what record supports it. Second, **reading the empty pre-window as clean**: the console showing nothing before day −7 is absence of retained records, not absence of activity, and those are opposite claims. If asked whether the host was clean in month one, the correct answer is that this source cannot say. A third, subtler one: do not report dwell time as seven days because that is where the events start. Any figure derived from the retention edge is a **floor** set by your visibility, not a measurement of the intrusion. Say "at least seven days; the true start is not established here." ## Corroboration, and its honest framing The intrusion did not only touch the endpoint, so other sources may reach further back than the sensor does, and asking for them is part of the answer. But be clear about what you are doing: you are looking for a *different* record that survives, not squeezing more out of one that does not exist. The EDR stream's contribution stops at its edge, and your report should say where that edge is, so that anyone reading it knows the difference between what you searched and what you could not. ## What good sounds like "Seven days hot, thirty in the platform, nothing on the host. The first exec is outside all of it. Present state gives me anchors with timestamps; the retained window tells me whether it is still live. My earliest recorded event is day −7 and I am reporting everything before that as unknown, not as clean."