TR1.1 The Order of Volatility

RFC 3227: what endures and what doesn't

RFC 3227, published by the IETF in 2002, established the principle that governs every collection decision you'll make in this module: collect the most volatile evidence first because it has the shortest lifespan. The RFC's specific hierarchy lists registers and cache, then routing and ARP tables, then memory, then temporary filesystems, then disk, then remote logging, then archival media.

Three principles from RFC 3227 remain non-negotiable. First, proceed from most volatile to least volatile — never skip a tier to start at a more convenient one. Second, don't shut down systems before collecting evidence. The attacker may have modified startup scripts, and the shutdown itself destroys memory, network state, and running process context. Third, use trusted tools, not binaries from the potentially compromised system. Your memory acquisition tool comes from a forensic USB, not from the endpoint's Program Files directory.

What RFC 3227 couldn't anticipate is where evidence lives in 2026. A modern incident involves cloud API logs that expire on vendor-controlled retention schedules. Container layers that vanish on restart — not just host reboot. Distributed authentication state in Microsoft's infrastructure that the responder doesn't control. OAuth tokens that rotate hourly. The evidence categories have expanded, even though the ordering principle hasn't changed.

Figure TR1.1 — The updated order of volatility for 2026 environments. Triage focuses on Tiers 1–3. Tiers 4–5 are the investigation team's domain. The triage responder who captures Tier 1 within the first 15 minutes preserves data that cannot be recovered by any other means.

Tier 1 — seconds to minutes

Tier 1 is evidence that is actively changing right now. Every second of delay reduces its fidelity.

Active network connections are the highest-priority Tier 1 artifact for triage. A TCP session to a command-and-control server reveals the attacker's infrastructure — IP address, port, protocol — which feeds every subsequent phase of the response. On Windows, Get-NetTCPConnection captures the current connection table. On Linux, ss -tlnp shows listening and established sockets with the owning process. These connections vanish the moment the process terminates, the session times out, or the system is network-isolated for containment.

# Capture active network connections with owning process
Get-NetTCPConnection | Where-Object { $_.State -eq 'Established' } |
    Select-Object LocalAddress, LocalPort, RemoteAddress,
    RemotePort, OwningProcess,
    @{N='Process';E={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
    Format-Table -AutoSize

Here's what that output looks like at 06:47, two minutes after the analyst opens the alert. The attacker's reverse shell is still connected.

LocalAddress  LocalPort RemoteAddress   RemotePort OwningProcess Process
-----------   --------- -------------   ---------- ------------- -------
10.42.1.15    49832     185.220.101.34  443        7284          svchost
10.42.1.15    49871     20.190.159.2    443        4112          msedge
10.42.1.15    50114     40.126.32.140   443        1388          lsass
10.42.1.15    50312     192.168.1.1     445        4             System

Read the output before doing anything else. The first row is the one that matters: svchost holding a persistent HTTPS connection to 185.220.101.34 on port 443. Legitimate svchost instances connect to Microsoft update servers and Azure endpoints — not to an IP in a Tor exit node range. The owning process (PID 7284) gives you the handle to correlate against the process tree. The remote IP gives the investigation team its first indicator of compromise.

If the analyst had isolated the endpoint at 06:46 instead of 06:47, this row would not exist.

Live session tokens are the Tier 1 artifact that didn't exist when RFC 3227 was written. An attacker's active Entra ID access token is valid for approximately 60 minutes. The refresh token can persist for up to 90 days. The sign-in log entry that records the token's source IP, device, conditional access evaluation, and authentication method still exists in Entra — but only for 30 days on P1/P2 licensing without Diagnostic Settings forwarding to Log Analytics.

If the responder captures or exports the sign-in record during triage, the investigation has the session's full context. If they wait, the record ages toward its retention boundary.

The practical implication: at the moment the analyst opens the alert, multiple evidence types are decaying at different rates on the same system. The TCP connection will vanish in seconds if the attacker's process terminates. The process's command-line arguments survive until the process exits, but not across a reboot. The memory pages that contain the attacker's injected code persist until the operating system reclaims them — which could happen any time under memory pressure.

The analyst doesn't get to pick a single artifact and collect it perfectly. They need a capture sequence that preserves the most volatile artifacts first, even if each capture is imperfect.

Running process state completes Tier 1. The process ID, command line, parent process, loaded modules, and open handles tell the triage responder what the system is doing right now. A reverse shell process has a parent, a command line that reveals its mechanism, and a network connection that reveals its destination. All of this is destroyed the moment the process terminates — whether the attacker kills it, a scheduled reboot occurs, or the analyst isolates the system.

Tier 2 — minutes to hours

Tier 2 evidence requires dedicated tools to capture but survives longer than active connections and session state. Full physical memory is the most important Tier 2 artifact. A RAM dump captures every running process, every loaded DLL, every network connection, every encryption key in use, and every string the attacker typed into a command prompt. The memory dump survives reboot — on external storage — but the live memory it captures does not.

The process table and routing cache fall into Tier 2 because they change less frequently than individual connections but are still overwritten by normal system activity. Container runtime state is the Tier 2 artifact that catches organizations off guard — when a container restarts, its entire filesystem layer is destroyed and rebuilt from the image. Any malware, any modified configuration, any dropped tool that existed only in the container's writable layer is gone. This isn't a reboot; it's a complete replacement.

# Capture container runtime state before restart destroys it
docker inspect $(docker ps -q) > /evidence/container_state_$(date +%Y%m%dT%H%M%S).json
# Copy the writable layer diff — this is the attacker's modifications
docker diff $(docker ps -q --filter name=webapp) > /evidence/container_diff.txt
# Export full container filesystem for offline analysis
docker export $(docker ps -q --filter name=webapp) > /evidence/webapp_export.tar

Tier 3 — hours to days

Tier 3 contains evidence that persists on disk or in cloud storage but has a rotation or retention schedule that the responder must know. Windows Event Logs are the canonical Tier 3 artifact — Security.evtx has a maximum size (20 MB by default) and overwrites the oldest entries when full. On a busy domain controller generating thousands of authentication events per hour, a 20 MB log file can rotate past the evidence window in less than a day.

A file server with minimal audit policy might retain weeks of history in the same 20 MB. The rotation rate is workload-dependent, which means the responder can't assume a fixed evidence window without checking.

Prefetch files on Windows record the last 8 execution times for each application (or 1,024 total entries before the oldest are recycled). On a system with heavy application churn — a developer workstation, a shared terminal server — the prefetch evidence for a malicious binary executed two days ago may already be overwritten by legitimate application launches. On a single-purpose server that runs the same four services, prefetch evidence can survive for weeks.

Cloud audit streams — the Unified Audit Log in Microsoft 365 — retain entries for 90 days at standard licensing or 180 days with E5, after which they're purged automatically. Purview Audit Premium (E5) extends Exchange, SharePoint, OneDrive, and Entra activity records to one year. But the extension only applies if the license was active when the event was logged.

An organization that upgrades to E5 after discovering an incident does not retroactively gain access to events that were already purged under the previous retention window.

The triage action for Tier 3 is collection, not just awareness. A KAPE triage collection on Windows captures event logs, prefetch, registry hives, and browser artifacts in a single automated pass. On Linux, copying /var/log/ and the systemd journal entries for the relevant timeframe preserves the log evidence before rotation overwrites it.

The goal is to move Tier 3 evidence from its volatile location (the live system, the cloud retention window) to a durable location (the case folder, the evidence share) where it cannot be aged out.

Tiers 4 and 5 — the investigation team's domain

The triage responder's relationship with Tiers 4 and 5 is protective, not active. Disk forensic artifacts — the MFT, registry hives, browser databases, and filesystem timestamps — survive for days to weeks under normal system operation. Cloud sign-in logs persist for 30 days (Entra P1/P2) or longer in Sentinel. Archived SIEM data, backup tapes, and forensic images represent the least volatile tier, surviving weeks to years.

You don't actively collect Tier 4 during triage. You protect it. Isolating an endpoint (rather than reimaging it) preserves every disk artifact for the investigation team. Not powering off a server preserves the memory state while maintaining disk integrity. The preservation principle is simple: your triage actions should never destroy evidence in a lower tier. If you need to contain — and you will — capture everything in Tiers 1 through 3 first, then contain.

// Check how much sign-in history remains before retention expiry
SigninLogs
| summarize EarliestRecord = min(TimeGenerated),
            LatestRecord = max(TimeGenerated),
            DaysOfData = datetime_diff('day', max(TimeGenerated), min(TimeGenerated)),
            TotalRecords = count()
| extend DaysUntilOldestExpires = 30 - datetime_diff('day', now(), EarliestRecord)

Run this query against your Sentinel workspace. The DaysUntilOldestExpires column tells you how many days remain before the oldest sign-in record ages past native retention. If that number is single digits, you're already losing evidence. If your workspace has Diagnostic Settings configured to forward sign-in logs to Log Analytics with extended retention, the number may be higher — but most organizations discover the gap only after an incident, when the evidence they need has already expired.

The collection sequence is the decision

The five-tier model is not a taxonomy exercise. It's a decision framework you apply under pressure. When an incident is declared, you mentally map the affected systems to the volatility tiers, identify what's at risk of disappearing soonest, and start collecting from the top. Active connections first. Process state second. Memory dump third. Log snapshots fourth. Everything else is the investigation team's problem.

The decision gets harder when evidence types compete. An active C2 connection on an endpoint and a session token expiring in Entra both sit in Tier 1 — but you can't collect both simultaneously if you're the only responder. The answer depends on which artifact feeds more of the investigation. The C2 IP identifies attacker infrastructure. The sign-in record identifies the compromised identity and access method.

If the sign-in record will survive in Sentinel for another 25 days but the C2 connection will close in minutes, the network connection wins.