TR0.10 The Triage Report Template

Figure TR0.10 — The 5-section triage report. Each section takes 2-3 minutes to complete. The total report production time is 15 minutes or less — the report should be written DURING the triage, not after.

The triage report template

TRIAGE REPORT

Incident Reference: INC-2026-0406-001 Alert Source: Sentinel Analytics Rule: “SSH brute force detected” Alert Time: 2026-04-06 15:10 UTC Triage Start: 2026-04-06 15:12 UTC Triage Complete: 2026-04-06 15:27 UTC Triage Duration: 15 minutes Triage Analyst: Rachel Osei, SOC Analyst

---

SECTION 1: CLASSIFICATION

Classification: CONFIRMED TRUE POSITIVE — Cross-environment compromise Justification: SSH brute force from 203.0.113.55 succeeded at 03:01:44 for the admin account. Post-authentication: attacker downloaded and executed payload via sudo, established C2 beacon to 45.155.205.99:443, created backdoor account with sudo access, deployed 4 persistence mechanisms. Cross-environment correlation confirms this is lateral movement from DESKTOP-NGE042 (compromised via CHAIN-DRIFT).

---

SECTION 2: SCOPE

Systems confirmed compromised: SRV-NGE-BRS-DB01 (Linux database server), DESKTOP-NGE042 (Windows endpoint — previously triaged) Accounts compromised: svc-dbadmin (service account), admin (local admin), backdoor (attacker-created) Environments affected: Linux + Windows + Cloud (cross-environment — see unified timeline in Section 3) Data at risk: Customer PII database (85,000 records). /etc/shadow (all local account hashes). CI/CD deploy key. Regulatory trigger: GDPR Article 33 — personal data exposure confirmed. DPO notified at 15:28 UTC.

---

SECTION 3: FINDINGS

Finding ID	Summary	ATT&CK
IF-2026-TR4-BF-001	SSH brute force success → payload download → execution	T1110.001 → T1105 → T1059
IF-2026-TR4-SUDO-001	sudo shadow dump → account creation → SSH key → C2	T1548.003 → T1136.001 → T1098.004
IF-2026-TR4-PROC-001	Python C2 beacon in /dev/shm → 45.155.205.99:443	T1059.006 + T1573.001
IF-2026-TR4-PERSIST-001	4 persistence mechanisms (cron, systemd, SSH key, .bashrc)	T1053.003 + T1543.002 + T1098.004 + T1546.004
IF-2026-TR4-CROSS-001	Cross-env: AiTM → Windows beacon → LSASS → SSH → Linux C2	8-technique chain

---

SECTION 4: CONTAINMENT

All containment actions executed between 15:20-15:25 UTC:

1. iptables block on 45.155.205.99 — verified: C2 connection transitioned to SYN-SENT ✅
2. svc-dbadmin disabled (passwd -l + usermod -e 1) — verified: account locked ✅
3. backdoor account deleted (userdel -r) ✅
4. SSH keys truncated for svc-dbadmin and admin ✅
5. Persistence removed: cron entry, system-health.service, .bashrc injection ✅
6. C2 beacon killed (PID 31337) ✅
7. 60-second verification: no respawn, no C2 reconnection, no active sessions ✅

Synchronized containment: Windows team isolated DESKTOP-NGE042 at 15:22. Cloud team revoked j.morrison sessions at 15:22.

---

SECTION 5: NEXT STEPS (for investigation team)

1. Analyse memory dump (AVML, 8 GiB, SHA256: a7c3e1b2…) with Volatility3 — determine C2 command history and data accessed
2. Check MySQL query log — determine if customer database was accessed/exfiltrated
3. Analyse /dev/shm/db_export.sql.gz — determine what data was staged (4.2 GB)
4. Check network logs for outbound transfers >1 GB from SRV-NGE-BRS-DB01 in the 15:12-15:25 window
5. Rotate ALL credentials: svc-dbadmin, admin, deploy key. Reset all /etc/shadow accounts (hashes compromised)
6. Fleet scan: check other Linux servers (10.1.2.0/24 segment) for svc-dbadmin SSH sessions
7. GDPR assessment: if database access confirmed, prepare Article 34 data subject notification

Writing the report DURING triage, not after. Each section should be populated as the triage progresses: classification written at minute 3 (when the TP decision is made), scope written at minute 8 (when cross-environment correlation completes), findings accumulated throughout, containment documented action-by-action. The final report is complete when containment verification passes — the analyst adds the Section 5 recommendations and hands off.

Dual-audience reporting

The triage report serves TWO audiences:

Technical audience (investigation team, SOC lead): needs the finding IDs, the exact commands executed, the evidence locations, the ATT&CK mapping, and the specific next-step recommendations. The full report above serves this audience.

Executive audience (CISO, DPO, legal): needs: what happened (in one sentence), how bad is it (scope + data at risk), what was done (containment summary), and what happens next (regulatory implications + investigation timeline). Produce a 4-line executive summary at the top of the report:

Executive Summary: A cross-environment attack compromised a Linux database server holding 85,000 customer records. The attack originated from a phishing-compromised cloud identity, traversed a Windows endpoint, and reached the Linux server via SSH lateral movement. All three environments have been contained. GDPR Article 33 notification to the ICO is recommended within 72 hours. The investigation team is analysing whether customer data was accessed or exfiltrated.

Report quality standards and common mistakes

The triage report serves as the foundation for the investigation. Common mistakes that degrade report quality and waste investigation team time:

Vague classification without evidence: “Classification: TP” without specifying WHICH finding confirmed the TP. The investigation team cannot validate the classification without seeing the evidence. Every classification must reference at least one IF-numbered finding.

Incomplete scope: listing the compromised system but not the blast radius. The triage report that says “SRV-NGE-BRS-DB01 compromised” without noting the 85,000 PII records, the 12 reachable Linux servers, and the CI/CD deploy key forces the investigation team to re-derive the scope — wasting 30-60 minutes they could spend on analysis.

Missing containment verification: documenting containment actions but not the verification results. “iptables block applied” is insufficient — the report must confirm the block is effective (“C2 connection transitioned from ESTAB to SYN-SENT, verified at 15:23”). Unverified containment may leave the attacker with active access while the investigation team believes containment is complete.

Timestamps without timezone: “Alert fired at 15:10” — is that UTC, BST, local server time? ALL timestamps in the triage report must specify UTC. If the original alert was in local time, convert to UTC in the report and note the conversion.

Narrative without structure: a free-text description of what happened without the 5-section structure. The investigation team receiving a paragraph of text must parse it to extract the classification, scope, findings, and containment status — work the structured template eliminates. Always use the 5-section format even if the FP classification results in a short report (“Section 1: FP. Section 2: N/A. Section 3: Alert triggered by legitimate admin activity from authorised IP. Section 4: No containment required. Section 5: Tune the analytics rule to exclude this admin IP.”).

Troubleshooting

“I do not have time to write a report during triage — I am too busy running commands.” The template is designed to be filled in DURING triage, not after. Classification (Section 1) takes 30 seconds to write when the decision is made. Scope (Section 2) takes 60 seconds when the cross-environment check completes. Findings (Section 3) are the IF-numbered findings already produced during triage. Containment (Section 4) is documented as each action executes. The report is COMPLETE when triage ends — no separate documentation phase needed.

“My organisation uses a different incident report format.” Adapt the 5 sections to your format. The content is universal: classification, scope, findings, containment, next steps. The section names and layout may differ, but the information requirements are the same regardless of the template.