Learn · Incident Response

Scoping and Timelines

Find everything an incident reached, and put its events in sequence: the two answers behind every decision to contain it.

Not yet read in this browserSign in to see where you have applied this.

Why it matters

Containing one host while the same intruder sits on two others is not containment. Before anyone isolates, resets or restores, someone has to say which hosts, which accounts and which data were involved, and how sure they are.

Sequence matters as much as extent. The earliest event tells you how they got in; the latest tells you whether it is still going on. Both come from the same events, read in sequence.

What analysts see

Scoping and timeline work starts from one confirmed indicator and spreads outward:

The same file, account or destination turning up on more than one host.
Sign-ins by an account to hosts outside its usual pattern.
Events from several sources (Windows, Sysmon, network) that each hold one piece of the sequence.
Timestamps that do not line up at first glance, because hosts and log sources record time differently.

None of these is the answer on its own. The answer is the list of what was affected, and the ordered sequence of what happened to it.

Core concept

Scope by pivoting. Take something you know is involved, such as a file, an account or a destination, and search for it everywhere. Every new host or account you find becomes the next thing to search for. Stop when a full round of pivots finds nothing new.

Order by event time, in one time zone. Put every event on one timeline in UTC, by when it happened (@timestamp), not when the SIEM received it (event.ingested). Then read off the first and the last occurrence of each thing you care about.

Keep the two lists separate. Affected means your hosts, accounts and data. The outside address the intruder talked to is part of the timeline, but it is not part of the affected set.

Annotated examples

Pivoting on a file

A suspicious program was found on one workstation. Where else is it?

KQL:: file.hash.sha256: "47671697028edd14b95bf03efb98477dbd607d3b5cbfad4d9f42f42d51f6fdf4" (note 1)
results:: 3 events
host.name (values):: "ws-117.corp.example", "ws-118.corp.example", "fs-02.corp.example" (note 2)
file.name:: "q3-invoice-viewer.exe" (note 3)
file.path:: "C:\ProgramData\q3-invoice-viewer.exe"

Note 1: Pivot on the file's SHA-256 digest: it identifies the content itself. Search for it everywhere, not just on the host where it was found.
Note 2: Two workstations and a file server now. The affected set just tripled.
Note 3: The same name and path on every host this time. A renamed copy would still match the SHA-256 digest; a search on the name alone would miss it.

One pivot turned "a workstation" into "two workstations and a file server". Each new host is the next thing to search for.

Pivoting on an account

An account signed in to one of those hosts remotely. Where else did it go?

KQL:: user.name: "t.ashdown" and event.code: "4624" and winlog.event_data.LogonType: "10" (note 1)
results:: 3 events
host.name (values):: "ws-117.corp.example", "ws-118.corp.example", "fs-02.corp.example" (note 2)

Note 1: Event 4624 records a successful sign-in; logon type 10 marks it as a remote interactive session.
Note 2: The same hosts as before. The account adds no new host, but it is now in the affected set itself, and it is the thread that joins the hosts.

Pivot on accounts as well as files: an account an intruder uses is affected even if every host it touched is already on your list.

A timeline across hosts

Everything found so far, in one list, ordered by event time in UTC:

2026-03-14T09:02:11Z:: ws-117 q3-invoice-viewer.exe written to disk (note 1)
2026-03-14T09:14:37Z:: ws-117 first connection to 198.51.100.77
2026-03-14T10:05:52Z:: ws-118 t.ashdown remote sign-in (4624, type 10) (note 2)
2026-03-14T10:48:03Z:: fs-02 t.ashdown remote sign-in (4624, type 10)
2026-03-14T11:52:40Z:: ws-117 last connection to 198.51.100.77 (note 3)

Note 1: The earliest event you have: the file arriving on ws-117. Your working answer to "how did it start", until you find something earlier.
Note 2: The spread: from ws-117 to the other hosts, using the account, within the next two hours.
Note 3: The latest event you have. If nothing comes after it, the activity may have stopped; if the window is recent, it may still be going on.

Read the timeline as a story: arrival, first contact, spread, last contact. Gaps in it are the next questions.

One host's clock

ws-118's sign-in first appeared an hour late. Its log source recorded local time:

time as logged:: "2026-03-14T11:05:52" (note 1)
event.timezone:: "+01:00" (note 2)
@timestamp (UTC):: "2026-03-14T10:05:52Z" (note 3)

Note 1: No zone on the raw time. Read as UTC, this sign-in would land after the fs-02 one and reverse the order of the spread.
Note 2: The source's offset from UTC, where the collector recorded it.
Note 3: Converted to UTC, it takes its real place in the sequence.

Before you trust an order, confirm every source is in the same time zone.

First and last contact

Every connection to the outside address from the timeline:

KQL:: destination.ip: "198.51.100.77" (note 1)
results:: 212 events
host.name (top value):: "ws-117.corp.example" (note 2)
first @timestamp:: "2026-03-14T09:14:37Z"
last @timestamp:: "2026-03-14T11:52:40Z" (note 3)

Note 1: This address is the intruder's, so it belongs on the timeline, not in the affected set.
Note 2: Every connection came from ws-117: the other hosts were reached through the account, not by talking out themselves.
Note 3: Sort the results by @timestamp and read both ends. The first and last occurrence bound how long it went on.

First and last are the two numbers people ask for first: how long it went on, and whether it has stopped.

How to investigate

1.
Start from one confirmed indicator.
A file, an account or a destination you are sure is involved, not a guess.
```
file.hash.sha256: "47671697028edd14b95bf03efb98477dbd607d3b5cbfad4d9f42f42d51f6fdf4"
```
2.
Pivot, and add what you find.
Search for the indicator everywhere. Add every new host and account to the affected list, and each one becomes the next search.
```
user.name: "t.ashdown" and event.code: "4624"
```
3.
Stop when a round finds nothing new.
A full round of pivots on everything in your list that adds no host or account is your stopping point; say so in your notes.
4.
Build the timeline in UTC.
Every event from every source on one list, by @timestamp. Convert any source that logged local time before you place it.
5.
Read off first and last.
For each thing you care about, note its first and last occurrence. The earliest event overall is your working answer to how it started.
```
destination.ip: "198.51.100.77"
```

Common mistakes

Mistake: Stopping at the first host.
InsteadPivot until a full round finds nothing new. The first host is where you noticed it, not necessarily where it started or ended.
Mistake: Mixing time zones.
InsteadPut everything in UTC before ordering it. One source in local time can reverse the order of two events.
Mistake: Ordering by when the SIEM received events.
InsteadUse @timestamp, when it happened. event.ingested records arrival, which can lag by minutes or hours.
Mistake: Counting the intruder's infrastructure as affected.
InsteadOutside addresses and domains go on the timeline. The affected set is your hosts, accounts and data.
Mistake: Pivoting on something every host has.
InsteadA value that appears everywhere, such as a standard system file, finds everything and tells you nothing. Pivot on what is specific to this activity.

Field references

Field	What it tells you	Seen in
@timestamp	When the event happened, in UTC. What a timeline is ordered by.	Every event
event.ingested	When the SIEM received the event. Not for ordering.	Every event
event.timezone	The source's offset from UTC, where it was recorded.	Varies by source
file.hash.sha256	The SHA-256 digest of a file's content: the same for every copy, whatever it is called.	Sysmon
file.name, file.path	A file's name, and its full path on disk.	Sysmon
user.name	The account involved.	Windows Security, Sysmon
winlog.event_data.LogonType	How a sign-in happened; 10 is a remote interactive session.	Windows Security (4624)
host.name	The machine that recorded the event.	Every host-based event
destination.ip	Where a connection went.	Network, Sysmon

Apply it in a Case

Pick a case, and once you have one confirmed indicator, write down every host and account you can reach from it by pivoting. Then put their events in order and note the first and last.

Browse every case on the Range →

References

Incident Response Recommendations and Considerations for Cybersecurity Risk Management (SP 800-61 Rev. 3) · NIST
Event 4624: An account was successfully logged on · Microsoft
ECS event fields · Elastic
Timeline · Elastic Security

Next: Operation SilverfishYour first case on the Incident Investigation path.