TR0.3 Three Environments, One Methodology

The Triage Trinity

Every triage — regardless of environment — follows three phases in a fixed sequence: classify, preserve, contain.

Figure TR0.3 — The Triage Trinity applied to three environments. The methodology is identical. The tools, evidence sources, and containment actions differ per environment.

Phase 1 — Classify. Determine whether the alert represents a true incident, a false positive, a benign true positive, or an indeterminate finding. The tools differ per environment — KQL queries in the cloud, process analysis on Windows, log review on Linux — but the decision framework from Section 0.2 applies identically. The triage scorecard asks the same 8 questions whether the alert originates from Entra ID, Defender for Endpoint, or a Linux auth.log parser.

Phase 2 — Preserve. Capture volatile evidence before it degrades. The volatility hierarchy from TR1 governs priority: memory first, then processes and network state, then logs. The collection tools differ — Graph PowerShell exports cloud sign-in data, KAPE collects Windows volatile artifacts, LiME captures Linux memory — but the priority logic is identical.

Phase 3 — Contain. Execute the minimum action required to stop the attacker's progress while preserving evidence for the investigation team. Containment actions are environment-specific: session revocation in the cloud, device network isolation on Windows, iptables block on Linux. Each action has a blast radius — legitimate users and services that break when containment is applied — covered in depth in TR8.

The sequence is fixed. Containment before classification risks unnecessary actions on a false positive — disabling a legitimate user's account at 02:00 or isolating a production server from the network. Containment before preservation may destroy the evidence the investigation needs — rebooting a server to "fix" it destroys memory and running process state. Classification before preservation is acceptable only when classification is confident and quick (under 5 minutes). Otherwise, begin preservation in parallel with classification for probable true positives.

When an incident crosses environments — which modern attacks routinely do — the responder must execute the Triage Trinity in each affected environment. The cloud triage identifies the initial access. The Windows triage identifies the endpoint compromise. The Linux triage identifies the server-side impact. These can run in parallel: cloud log snapshots, Windows memory dump, and Linux log collection happening simultaneously if the responder has access to all three environments.

At NE, Rachel's triage of the CHAIN-HARVEST extended attack executed cloud triage first (the alert fired on the cloud event), identified the endpoint entity from the sign-in logs, ran the Windows triage on the identified workstation, then checked the Linux systems from the endpoint's connection list. Total triage across all three environments: 25 minutes. Total containment: 8 minutes. Handoff to IR: 38 minutes from initial alert — well within the 60-minute window.

Same questions, different data sources

The triage scorecard asks 8 questions. The data source for each answer changes per environment, but the question is identical.

"Is there evidence of compromise beyond the initial alert?" In the cloud, this means querying SigninLogs for additional anomalous sign-ins and AuditLogs for configuration changes. On Windows, this means checking for suspicious processes, unexpected network connections, and new scheduled tasks. On Linux, this means reviewing auth.log for additional access attempts, crontab for new entries, and /tmp and /dev/shm for dropped files.

// Given a compromised user, find all environments they touched
// Cloud sign-ins + endpoint activity + any Linux logins via Syslog
let targetUser = "j.morrison@northgate-eng.co.uk";
let lookback = ago(4h);
union
    (SigninLogs
     | where TimeGenerated > lookback
     | where UserPrincipalName == targetUser
     | project TimeGenerated, Environment="Cloud",
         Source=AppDisplayName, Entity=IPAddress),
    (DeviceLogonEvents
     | where Timestamp > lookback
     | where AccountUpn == targetUser
     | project TimeGenerated=Timestamp, Environment="Endpoint",
         Source=DeviceName, Entity=RemoteIP),
    (Syslog
     | where TimeGenerated > lookback
     | where SyslogMessage contains "j.morrison"
     | where Facility == "auth"
     | project TimeGenerated, Environment="Linux",
         Source=HostName, Entity=extract("from ([\\d\\.]+)", 1, SyslogMessage))
| sort by TimeGenerated asc

This query answers the cross-environment question in a single execution. The output is a timeline of every environment the compromised user touched — cloud sign-ins, endpoint logons, and Linux authentication events — sorted chronologically. If the cloud compromise at 08:14 is followed by an endpoint logon at 08:22 and a Linux auth event at 08:35, you've just identified a cross-environment attack chain in one query.

Single-environment triage would have found only the cloud entry and declared containment after revoking the cloud session — while the attacker maintained access on the endpoint and the Linux server.

"Is the scope beyond a single entity?" In the cloud: did the same IP authenticate as other users? Did the compromised OAuth application access other tenants? On Windows: did the attacker's process connect to other devices via RDP, WMI, or SMB? On Linux: did the compromised account SSH to other servers? Same question, different evidence sources. The scorecard keeps the analyst focused on the investigation logic while environment-specific toolkits provide the technical implementation.

The entity correlation point is where cross-environment triage reveals its value. When the KQL cross-environment query returns events across two or more environments — cloud sign-in from a Tor IP at 08:14, endpoint logon from the same user at 08:22, Linux SSH event at 08:35 — you've identified the attack chain in a single query.

Each subsequent environment adds context that the previous one lacked: the cloud log shows the authentication method (token replay), the endpoint log shows the process tree (beacon spawning command shells), and the Linux log shows the target (database server with customer PII). A single-environment triage would have found one piece of this story and missed the rest.

Why single-environment triage fails

Most analysts are trained in one environment. The cloud analyst writes KQL and reviews sign-in data. The Windows specialist runs PowerShell and collects event logs. The Linux admin checks auth.log and running processes. Each analyst is competent in their domain — and blind outside it.

Single-environment triage fails when the incident crosses boundaries, which modern attacks routinely do. CHAIN-MESH at NE started with a VPN login from a compromised credential, moved through Windows via RDP and NTLM lateral movement, and reached the Sheffield manufacturing server. An analyst who only triaged the VPN alert would see an anomalous login and potentially close it as a VPN misconfiguration. The lateral movement to the manufacturing server — where the ransomware was deployed — went undetected until encryption began.

The same pattern applies to CHAIN-HARVEST. If the analyst triaged only the cloud AiTM alert and revoked the cloud session, the incident would appear contained — cloud access removed, session terminated. But if the attacker had also dropped a payload on j.morrison's Windows endpoint (a common AiTM follow-up technique), cloud-only triage would have classified the cloud compromise correctly while missing the endpoint compromise entirely. The investigation team would have declared containment while the attacker maintained access through the endpoint backdoor.

The cross-environment capability gap creates a measurable handoff delay. In organizations with siloed teams, cloud triage passes to endpoint with a request — "can you check the user's workstation?" The endpoint team receives the request, adds it to their queue, and begins their own triage from zero, lacking the cloud context (which IP the attacker used, what data they accessed, what persistence they established). The typical handoff delay is 30–90 minutes — time the attacker uses to advance.

The Triage Trinity eliminates this by producing a structured triage report that includes what was found, what evidence was preserved, what containment was executed, and what remains unknown, so the receiving team builds on existing findings rather than starting over.

# Rapid volatile evidence collection — run BEFORE containment
# Captures the process, network, and session state the attacker is using
$OutPath = "C:\Triage\$(hostname)_$(Get-Date -f yyyyMMdd_HHmmss)"
New-Item -Path $OutPath -ItemType Directory -Force
# Running processes with parent, command line, user
Get-CimInstance Win32_Process |
    Select-Object ProcessId, ParentProcessId, Name,
        CommandLine, CreationDate,
        @{N='User';E={($_.GetOwner()).User}} |
    Export-Csv "$OutPath\processes.csv" -NoTypeInformation
# Active network connections with owning process
Get-NetTCPConnection -State Established,Listen |
    Select-Object LocalAddress, LocalPort, RemoteAddress,
        RemotePort, State, OwningProcess,
        @{N='ProcessName';E={(Get-Process -Id $_.OwningProcess).Name}} |
    Export-Csv "$OutPath\connections.csv" -NoTypeInformation
# Logged-on sessions
query user | Out-File "$OutPath\sessions.txt"

This script runs in under 60 seconds and captures the three most volatile evidence categories on a Windows endpoint: processes (who's running, with what command line, under which user), network connections (what's talking to what, and which process owns the connection), and logged-on sessions. Run this before device isolation — because isolation kills the attacker's network connections and changes the state you're trying to capture.

The output files are the baseline that the investigation team uses to reconstruct what the attacker was doing at the moment of triage.

Building your cross-environment capability

Rate yourself 1–5 on each environment: cloud KQL, Windows PowerShell, Linux native commands. The environment where you score lowest is where a cross-boundary incident will stall.

The cross-training investment to achieve triage-level competency in an unfamiliar environment is approximately 20 hours — 5 hours of content study plus 15 hours of lab practice. You don't need to be an expert in every environment. You need to be able to execute the Triage Trinity in every environment: classify (run the triage queries), preserve (capture the volatile evidence), and contain (execute the minimum containment action). Modules TR2, TR3, and TR4 build that competency environment by environment.

On a Linux server, the equivalent volatile snapshot uses native commands that every Linux system provides — no additional tools needed:

# Rapid Linux volatile evidence — run BEFORE containment
OUT="/tmp/triage_$(hostname)_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUT"
# Running processes with full command lines
ps auxwwf > "$OUT/processes.txt"
# Active network connections with owning process
ss -tnp > "$OUT/connections.txt"
# Current and recent logins
w > "$OUT/current_sessions.txt"
last -20 > "$OUT/recent_logins.txt"
# Recent auth events (last 200 lines)
tail -200 /var/log/auth.log > "$OUT/auth_recent.txt" 2>/dev/null
journalctl -u sshd --since "4 hours ago" > "$OUT/ssh_journal.txt" 2>/dev/null

Three environments, three different tool sets, same methodology. The cloud snapshot uses KQL. The Windows snapshot uses PowerShell. The Linux snapshot uses native bash commands. Each produces the same three evidence categories: who's running (processes), who's talking to what (connections), and who's logged in (sessions). The investigation team receives the same quality of evidence regardless of which environment the triage responder collected from.

The analyst proficiency self-assessment for this course: for each environment in your organization, answer four questions. Which tools can you access within 5 minutes of receiving an alert? Can you collect volatile evidence in that environment? Can you execute containment actions? Do you have pre-built triage commands ready to run, or do you write them from scratch each time? If any environment has gaps, that is where a cross-boundary incident will stall.

The triage scripts in TR9 provide the pre-built "go bag" that eliminates the "write from scratch" problem.