TR0.1 The 60-Minute Window

Figure TR0.1 — The 60-minute window. Evidence quality degrades while attacker progress accelerates. Triage within 15 minutes preserves the most 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.

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 (data exfiltration, ransomware deployment, business email compromise).

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), and execute initial containment (before the attacker reaches their objective). Every minute of delay degrades the responder’s ability to do all three.

At Northgate Engineering, the CHAIN-HARVEST attack illustrates this perfectly. The AiTM phishing alert fired at 08:14 on February 27. The attacker had already captured j.morrison’s session token. At 08:47 — 33 minutes later — the attacker created an inbox rule forwarding financial emails. At 09:22, the attacker registered a new MFA method. By 13:08, the attacker had read 47 emails from the CEO’s mailbox and sent the BEC wire transfer request. The entire attack — from initial access to financial fraud — took less than 5 hours.

If Rachel’s triage at 08:14 had taken 4 hours instead of 15 minutes, the investigation would have started AFTER the BEC email was sent. The containment question would have shifted from “prevent the fraud” to “recover from the fraud.” The evidence question would have shifted from “which active sessions does the attacker control?” to “which sessions DID the attacker control before the tokens expired?”

What disappears in the first 60 minutes

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

Category 1 — Volatile system evidence (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. Even without a reboot, process memory is overwritten as applications allocate and free memory. Network connections close as sessions time out. The attacker’s initial process — the PowerShell stager, the reverse shell, the web shell — may terminate after establishing persistence, removing itself from the running process list entirely.

On a Windows endpoint compromised via CHAIN-ENDPOINT, the Cobalt Strike beacon process (rundll32.exe loading msedge_update.dll) exists in memory and the process list. If the analyst triages within 15 minutes, they find the beacon in tasklist, identify the suspicious DLL, and capture a memory dump containing the beacon configuration (including the C2 server address). If the analyst waits 4 hours, the beacon may have migrated to a different process or the system may have been rebooted by the user, destroying all volatile evidence.

On a Linux server compromised via SSH brute force, the attacker’s active session appears in w, last, and ss. Their running cryptominer appears in ps. Their network connection to the mining pool appears in ss -tnp. If the analyst triages within 15 minutes, all of this is visible with native commands. If the analyst waits until the next day, the attacker may have installed an LD_PRELOAD rootkit (as demonstrated in the LX7 persistence module) that hides their processes from ps, their connections from ss, and their files from ls. The evidence has not disappeared — it has been actively hidden.

In the cloud, volatile evidence takes a different form. An attacker’s active session token in Entra ID is valid for 1 hour (access token) to 90 days (refresh token). The active session — with its IP address, device fingerprint, and conditional access evaluation result — exists in real-time sign-in logs. If the analyst triages immediately, they can see the attacker’s active session alongside the legitimate user’s session and revoke the attacker’s session specifically. If the analyst waits 24 hours, the access token has expired and the refresh token may have been used to generate new tokens from a different IP, creating a confusing chain of authentication events that the investigation team must untangle.

Category 2 — Log evidence (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 is 20 MB, which on a busy server may hold only 24-48 hours of events. Linux auth.log rotates weekly by default but may rotate daily on high-traffic systems. Sentinel retains logs for 30-90 days depending on configuration, but the ingestion pipeline has a delay — events that occurred 5 minutes ago may not be queryable for another 5-10 minutes.

The critical risk: an attacker who clears event logs (Event ID 1102 on Windows, truncating auth.log on Linux) eliminates the log evidence entirely. Triage within 15 minutes captures the logs before the attacker can clear them. Triage after 4 hours may find cleared logs — and the investigation team must rely on Sentinel’s copy (if the events were ingested before clearing) or forensic recovery from disk (which requires a full forensic image, not a triage action).

Category 3 — Environmental state (minutes). The current state of the environment: which accounts are enabled, which conditional access policies are active, which firewall rules are in place, which services are running. The attacker actively modifies environmental state to support their operations: creating new accounts, disabling security controls, adding firewall rules, installing services. Each modification changes the baseline that the investigation team will use to determine “what changed.”

If the analyst captures the environmental state at 08:14 — before the attacker modifies it — the investigation team has a clean comparison point. If the analyst captures it at 12:00 — after the attacker has created a backdoor account, registered a new MFA method, and created inbox rules — the investigation team cannot easily distinguish the attacker’s changes from legitimate changes made during the same period by IT administrators.

The attacker’s timeline is faster than your triage

Modern attack chains complete in hours, not days. CrowdStrike’s annual threat reports consistently show breakout time — the time from initial compromise to lateral movement — decreasing year over year. For the fastest adversaries, breakout time is measured in minutes, not hours. Mandiant’s reporting shows median dwell time (initial compromise to detection) has decreased to approximately 10 days, but this is a MEDIAN — many organisations discover breaches months after initial compromise.

The triage responder operates in the gap between detection and investigation. The detection system fires the alert. The investigation team begins their work. Between those two events, the triage responder must determine whether the alert represents a real incident, preserve the evidence the investigation team will need, and execute containment that stops the attacker’s clock.

If the triage takes 15 minutes and the attacker’s breakout time is 60 minutes, containment happens before lateral movement. The incident is confined to the initially compromised system.

If the triage takes 4 hours and the attacker’s breakout time is 60 minutes, containment happens 3 hours AFTER lateral movement. The incident has spread to multiple systems, the scope is unknown, and the investigation must cover every system the attacker may have reached.

The NE example: 33 minutes from access to persistence

The CHAIN-HARVEST timeline at NE demonstrates the speed of modern attacks. At 08:11, j.morrison’s credentials were successfully sprayed. By 08:14, the attacker was replaying the captured session token from a Tor exit node. By 08:47 — 33 minutes after initial access — the attacker had created the inbox rule that would hide their BEC preparation from the legitimate user.

Rachel’s triage at NE took 12 minutes. She identified the anomalous sign-in (Romanian IP for a Bristol-based user), confirmed it was not a VPN session, and revoked j.morrison’s sessions. This containment — executed before the 33-minute mark — prevented the attacker from using the session token to access additional resources. The inbox rule was already created, but the attacker could not execute the BEC phase because their session was terminated.

If Rachel’s triage had taken 45 minutes, the attacker would have completed the MFA registration (09:22) before containment. Revoking the session token would not have been sufficient — the attacker would have been able to re-authenticate using the fraudulently registered MFA method. The containment action would have needed to include MFA method removal, not just session revocation. A 30-minute delay in triage changed the required containment from one action (session revocation) to three actions (session revocation + MFA method removal + password reset).

Measuring triage speed

Three metrics quantify triage effectiveness, and each measures a different aspect of the 60-minute window.

Time to triage (TTT). The interval between alert generation and the triage responder’s classification decision (true positive, false positive, or benign true positive). Industry benchmarks for top-performing SOCs show 10-15 minutes for high-severity alerts. The triage scorecard introduced in TR0.6 provides the structured methodology to achieve this consistently.

Time to first containment. The interval between alert generation and the first containment action (session revocation, network isolation, account disable). This metric matters because containment stops the attacker’s clock. Every minute between detection and first containment is a minute the attacker uses to progress toward their objective.

Evidence preservation completeness. The percentage of volatile evidence categories that were captured before degradation. A triage that captures memory, processes, and network state within 15 minutes scores higher than one that captures only network state after 2 hours. This metric is assessed retrospectively during the investigation — did the triage responder preserve the evidence the investigation team needed?

These metrics are not theoretical. They are the operational measurements that determine whether the investigation team receives a clean handoff (complete evidence, contained attacker, clear severity classification) or a contaminated handoff (degraded evidence, active attacker, uncertain scope).

The 60-minute commitment

This course teaches a structured triage methodology that completes within 60 minutes for any alert, across any environment. The first 15 minutes produce the classification decision (is this real?). The next 15 minutes produce the evidence preservation actions (capture the volatile data). The final 30 minutes produce the containment decision and execution (stop the attacker) plus the triage report (hand off to the investigation team).

Not every alert requires 60 minutes. Many alerts resolve in 5 minutes: the analyst runs the triage scorecard, determines it is a known false positive pattern, documents the reason, and closes it. The 60-minute framework is the maximum — the structured approach that handles the worst case, where the alert is genuine, the evidence is volatile, and the containment decision requires cross-environment coordination.

Framework mapping: where triage sits in NIST, SANS PICERL, and Microsoft IR

The 60-minute triage window maps to a specific phase in each of the three major incident response frameworks:

NIST SP 800-61r3 (Computer Security Incident Handling Guide). Triage falls within the Detection and Analysis phase (Phase 2). NIST defines this phase as: determining whether an incident has occurred, gathering information to identify the scope and magnitude, and prioritising the response. The triage scorecard from TR0.6 implements the “determine whether an incident has occurred” requirement. The preservation actions from TR1 implement the “gather information” requirement. The containment actions from TR2-TR4 bridge into NIST Phase 3 (Containment, Eradication, and Recovery).

SANS PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned). Triage spans the Identification (I) and early Containment (C) phases. PICERL’s Identification phase maps to the triage responder’s classification decision: is this alert a TP, FP, BTP, or indeterminate? The early Containment phase maps to the immediate containment actions executed after classification. The triage-to-investigation handoff marks the transition from early containment to the deeper Eradication phase.

Microsoft Incident Response Reference Guide. Microsoft’s IR process uses Detection → Triage → Investigation → Containment → Remediation → Recovery. Triage is explicitly named as a distinct phase between Detection and Investigation. Microsoft defines the triage phase as: “Assess the severity of the alert, determine whether the alert warrants further investigation, and if so, identify the scope of the incident.” This aligns directly with the classify-preserve-contain methodology taught in this course.

The framework alignment matters for two reasons: (1) regulatory compliance — demonstrating that your triage process follows established frameworks (NIST, SANS) strengthens the regulatory defence during breach notifications under GDPR Article 33 or NIS2 Article 23, and (2) professional credibility — the triage report that references the framework phase (“This incident was triaged per NIST SP 800-61r3 Phase 2”) communicates professional maturity to the investigation team, legal counsel, and executive stakeholders.

Measuring the triage window: MTTR and the SOC metrics that matter

The 60-minute triage window maps directly to the SOC metric that matters most: Mean Time to Respond (MTTR). MTTR measures the elapsed time from alert detection to containment or resolution. Industry benchmarks for 2026 set the target at 2-4 hours for all alert severities averaged together, but the triage-specific portion of MTTR should be under 15 minutes for the classification decision and under 30 minutes for initial containment. The SOC that achieves 15-minute triage classification + 30-minute initial containment operates within a 45-minute MTTR for the triage phase — well within the 60-minute window this subsection teaches.

Approximately 67% of organisations now track MTTR as a primary SOC performance indicator. The metric matters because it directly correlates with financial impact: IBM’s 2025 Cost of a Data Breach Report found that organisations with MTTD (Mean Time to Detect) below 200 days save an average of $1.1 million per incident compared to those with longer detection times. The triage phase is the bridge between detection (MTTD) and response (MTTR) — a faster triage classification enables a faster containment decision, which reduces the attacker’s dwell time and limits the blast radius.

At NE, Rachel tracks three triage-specific metrics per analyst per shift: classification time (alert open to scorecard complete — target: 12 minutes for FPs, 18 minutes for probable TPs), containment time (scorecard complete to containment actions executed — target: 7 minutes), and handoff time (containment complete to IR case created with preserved evidence — target: 5 minutes). The combined target: 30 minutes from alert to complete handoff for a confirmed TP. This metric is logged in the Sentinel incident comments and reviewed monthly.

The capacity planning implication: SOC capacity equals analysts multiplied by available triage hours per day multiplied by working days per month. Expected workload equals MTTR multiplied by monthly alert volume multiplied by a 1.15 buffer for surge handling. If your expected workload exceeds your capacity, the queue grows and MTTR degrades — alerts wait longer for triage, the attacker operates longer, and the blast radius expands. The triage scorecard and the structured query packs from TR2 and TR3 are designed to reduce per-alert triage time, which directly increases SOC capacity without adding headcount.

The triage window across the Mandiant timeline

Mandiant’s M-Trends 2026 report provides the attacker timeline that the 60-minute window must beat. The median dwell time across all incidents is approximately 10 days — but this includes incidents discovered months after initial access. For targeted attacks where the SOC detects the initial alert in real time, the timeline compresses dramatically: initial access to operator handoff in 22 seconds (the access broker passes the credential to the ransomware operator), operator to lateral movement in 1-6 hours (the operator enumerates the environment, dumps credentials, and identifies targets), and lateral movement to objective in 2-48 hours (encryption, exfiltration, or persistence establishment).

The 60-minute triage window sits in the gap between initial access and objective completion. If the SOC detects the initial access alert within minutes (the MTTD for a Sentinel analytics rule firing on a suspicious sign-in), and the triage responder classifies and contains within 30-45 minutes, the containment occurs BEFORE the attacker completes lateral movement — interrupting the kill chain at the most effective point. An hour later, and the attacker may have already moved to additional systems, making containment more complex and the investigation scope larger.

The 60-minute window is not arbitrary. It is the operational window that, when met, catches the majority of targeted attacks before the attacker achieves their primary objective. Every minute beyond 60 reduces the probability that containment will prevent the attacker from completing their mission.

Troubleshooting

“Our alerts are always low-confidence — how do I triage something uncertain?” Low-confidence alerts are exactly what the triage scorecard is designed for. The scorecard asks 8 specific questions that transform uncertainty into a classification. You do not need to be certain that an alert is a true positive to begin evidence preservation — the scorecard’s “preservation trigger” fires on probable threats, not just confirmed ones. Preserve first, confirm during investigation.

“We do not have the tools to collect volatile evidence during triage.” Module 9 (Triage Automation and Tooling) covers this, but the immediate answer: you have native tools in every environment. PowerShell on Windows (tasklist, Get-NetTCPConnection, Get-Process). Native commands on Linux (ps, ss, cat /proc/PID/). KQL in Sentinel for cloud evidence. The dedicated tools (KAPE, LiME, Velociraptor) improve efficiency and forensic integrity, but native tools are always available and sufficient for triage-level evidence collection.

“Our managed SOC partner handles triage — why do I need this skill?” Because the managed SOC triages based on THEIR playbooks, not YOUR environment knowledge. The MSSP knows the alert fired. They do not know that the affected user is the CFO, that the source IP is your VPN provider’s exit node, or that the application in question is your payroll system. Your environmental context is what transforms a generic alert triage into an accurate severity classification. Module 10 covers MSSP coordination specifically.