TR0.1 The 60-Minute Window

The race between evidence decay and attacker progress

An incident is a race between two clocks. The first clock measures evidence decay — volatile data disappearing from memory, network connections closing, log buffers overwriting older entries, session tokens expiring. The second clock measures attacker progress — moving from initial access to persistence, from persistence to lateral movement, from lateral movement to their objective.

The triage responder's job is to act before both clocks run out. Classify the alert — is this real? Preserve volatile evidence — before it disappears. Execute initial containment — before the attacker reaches their objective. Every minute of delay degrades the responder's ability to do all three.

Figure TR0.1 — Evidence quality degrades while attacker progress accelerates. Triage within 15 minutes preserves volatile evidence and catches the attacker at initial access. Triage after 4 hours hands the investigation team a degraded evidence set and an entrenched attacker.

At NE, the CHAIN-HARVEST timeline makes this concrete. The AiTM phishing alert fired at 08:14. By 08:47 — 33 minutes later — the attacker created inbox rules forwarding financial emails. By 09:22, a new MFA method was registered. By 13:08, the attacker had read 47 emails from the CFO's mailbox and sent the BEC wire transfer request. If triage had completed in 15 minutes, containment would have started before persistence. If triage took 4 hours, containment started after the fraud instruction was already sent.

What disappears in the first 60 minutes

Three categories of evidence degrade during delayed triage, each on a different timeline.

Volatile system evidence decays in minutes to hours. Memory contents, running processes, active network connections, logged-in sessions, loaded kernel modules, running containers. This evidence exists only while the system is running in its current state. A reboot destroys all of it. On a Windows endpoint compromised via CHAIN-ENDPOINT, the Cobalt Strike beacon running as a suspicious rundll32.exe exists in memory and the process list.

Triage within 15 minutes finds the beacon, identifies the suspicious DLL, and captures a memory dump containing the C2 server address. Triage after 4 hours risks finding that the beacon has migrated to a different process — or that the user rebooted, destroying all volatile evidence.

On a Linux server, the attacker's active session appears in w and last, their running processes in ps, and their network connections in ss -tnp. Wait until the next day, and the attacker may have installed an LD_PRELOAD rootkit that hides their processes, connections, and files from native commands. The evidence hasn't disappeared — it's been actively concealed.

Log evidence rotates in hours to days. Event logs, audit trails, firewall logs, authentication records. These persist on disk or in cloud storage but have finite retention. Windows Security event logs rotate based on maximum size — the default 20 MB on a busy server may hold only 24–48 hours of events. An attacker who clears event logs (Event ID 1102 on Windows, truncating auth.log on Linux) eliminates this evidence entirely.

Triage within 15 minutes captures the logs before the attacker clears them. Triage after 4 hours may find cleared logs and an investigation that depends on whether Sentinel ingested the events before they were wiped.

Environmental state changes in minutes. The current configuration of the environment — enabled accounts, conditional access policies, firewall rules, running services. The attacker actively modifies this state to support their operations: creating accounts, disabling controls, adding rules. If you capture the state at 08:14 (before modification), the investigation team has a clean comparison point. If you capture it at 12:00 (after the attacker has created a backdoor account and registered new MFA), distinguishing attacker changes from legitimate IT changes becomes significantly harder.

Cloud evidence has its own volatility timeline

In cloud environments, volatile evidence takes a different form than on endpoints. An attacker's active session token in Entra ID is valid for 60–90 minutes (access token) to 90 days (refresh token). The active session — with its IP address, device fingerprint, and conditional access evaluation result — exists in the real-time sign-in logs. Triage within 15 minutes lets you see the attacker's active session alongside the legitimate user's session and revoke the attacker's token specifically.

Wait 24 hours, and the access token has expired. The refresh token may have been used to generate new tokens from a different IP, creating a chain of authentication events the investigation team must untangle.

Mailbox audit logs in M365 capture actions taken on a mailbox — emails read, items deleted, forwarding rules created. These logs are retained for 90 days by default in E5 licensing, but the critical detail is the delay between the action and the log's availability for query. Mailbox audit events can take 30–60 minutes to appear in the Unified Audit Log.

A triage responder who queries the UAL at 08:20 looking for j.morrison's mailbox activity may not yet see the inbox rule the attacker created at 08:47. Knowing this ingestion delay is part of triage — you query, note the timestamp of your query, and schedule a follow-up query after the lag window.

The first 15 minutes of cloud triage should capture three snapshots: the current sign-in sessions for the affected account, the recent audit log entries for the affected mailbox or resource, and the current conditional access policy evaluations. These snapshots form the baseline the investigation builds from.

// First triage query: all sign-ins for the affected account in the past 2 hours
// Run this IMMEDIATELY — before revoking tokens
SigninLogs
| where TimeGenerated > ago(2h)
| where UserPrincipalName == "j.morrison@northgate-eng.co.uk"
| project TimeGenerated, IPAddress, Location,
    AppDisplayName, DeviceDetail,
    ConditionalAccessStatus, RiskLevelDuringSignIn,
    AuthenticationRequirement
| sort by TimeGenerated desc

This query is the first thing you run when a credential compromise alert fires. The output shows every active session — legitimate and attacker-controlled — with the IP, device, and risk level for each. You'll see the legitimate sign-in from j.morrison's known device and the attacker's sign-in from an unfamiliar IP. That side-by-side comparison is the triage evidence that drives the escalation decision. Run it before revoking tokens, because revocation ends the attacker's session and removes it from the active session view.

Measuring your triage latency

The gap between alert creation and first analyst action is your triage latency — the metric that determines whether you're operating within the 60-minute window or outside it. Most organizations don't measure this. They know roughly how long the queue sits, but they don't have a number.

If your environment uses Sentinel, you can measure triage latency directly from the SecurityIncident table. The CreatedTime records when the incident was created from the alert. The FirstModifiedTime records when an analyst first touched it — changed status, added a comment, assigned it. The gap between those two timestamps is your triage latency.

// Triage latency: time from incident creation to first analyst action
SecurityIncident
| where CreatedTime > ago(30d)
| where isnotempty(FirstModifiedTime)
| extend TriageLatencyMin = datetime_diff(
    'minute', FirstModifiedTime, CreatedTime)
| summarize
    MedianLatency = percentile(TriageLatencyMin, 50),
    P90Latency = percentile(TriageLatencyMin, 90),
    MaxLatency = max(TriageLatencyMin),
    TotalIncidents = count()
    by Severity
| sort by Severity asc

Severity  MedianLatency  P90Latency  MaxLatency  TotalIncidents
────────  ─────────────  ──────────  ──────────  ──────────────
High      23             187         1,440       42
Medium    67             312         2,880       156
Low       245            720         4,320       89

NE's output tells a clear story. High-severity incidents get touched in a median of 23 minutes — inside the viable window, but outside the best window. The P90 is 187 minutes — over 3 hours, well past the point where volatile evidence has degraded and the attacker has established persistence. Medium-severity incidents sit in the queue for over an hour at the median, and low-severity incidents wait over 4 hours.

The j.morrison AiTM alert was classified as medium severity by the template rule. At NE's median triage latency for medium alerts, that incident sat untouched for 67 minutes — and the attacker had already created persistence at minute 33.

The number you get from this query is the single most important metric in your triage operation. If your median high-severity latency exceeds 15 minutes, your triage process is too slow for the evidence window. If your P90 exceeds 60 minutes, your worst-case triage is outside the viable window entirely. The rest of this module teaches the methodology that brings those numbers down.

The containment window calculation

The containment window is the time between alert creation and the moment the attacker achieves their objective. This window is not the same for every attack chain. CHAIN-HARVEST (AiTM → BEC) gives you approximately 5 hours from phishing email to wire transfer fraud. CHAIN-MESH (spray → ransomware) gives you approximately 2.5 hours from credential compromise to encryption. CHAIN-FACTORY (USB → data theft) gives you 45 minutes from USB insertion to data exfiltration.

The triage methodology in this module targets a 15-minute triage decision. That target isn't arbitrary — it's the intersection of evidence preservation (volatile evidence is most intact in the first 15 minutes) and containment opportunity (15-minute triage leaves the maximum remaining window for investigation and response before the attacker reaches their objective). A 15-minute triage window provides 4 hours 45 minutes of containment time against CHAIN-HARVEST. A 60-minute triage window provides only 4 hours.

A 4-hour triage window provides 1 hour — assuming the attacker follows the expected timeline, which they may not.

The practical implication is that triage speed determines which response actions are available. At 15 minutes, you can revoke the compromised session token before the attacker establishes persistence — the inbox rule, the MFA registration, the mailbox delegation. At 60 minutes, you can revoke the token, but persistence mechanisms are already in place and require additional investigation to identify and remove.

At 4 hours, the attacker has likely achieved their objective and the response shifts from prevention to damage assessment and recovery. The response cost curve is not linear — it's exponential. The cost of containment at 15 minutes is revoking one token. The cost of containment at 4 hours is a full incident response engagement.

The attacker doesn't wait for your triage to finish. Every minute you spend deciding whether the alert is real is a minute the attacker spends moving deeper. The 60-minute window isn't a guideline. It's the physics of incident response — evidence decays, attackers advance, and the gap between detection and response determines the outcome.