Browse CTFs New CTF Sign in

Post-Incident Report Writing: Closing the Loop

incident_response Difficulty 1–2 50 min certifiable

Theory

Prerequisites

  • CIR-K001: The PICERL Lifecycle
  • CIR-K010: Stakeholder Communication

Why This Lesson Matters

The post-incident report is the permanent record of what happened, what you did, and what needs to change. It is read by management to make investment decisions, by lawyers to assess liability, by regulators as evidence of due diligence, and by the security team next time a similar incident occurs. A vague or incomplete report means the same incident happens again. A well-written report prevents the next one.

1. Report Purpose and Audiences

The same report serves multiple audiences. Structure it so each can find what they need:

Post-Incident Report
├── Executive Summary (1 page)      → CISO, Board, Legal
├── Technical Timeline (detailed)   → Security team, future analysts
├── Root Cause Analysis             → Engineering, management
├── Lessons Learned & Actions       → All — this is the most important section
└── Evidence Inventory              → Legal, forensics team

2. Section by Section

2.1 Executive Summary

One page, maximum. Written last, but appears first.

EXECUTIVE SUMMARY

On June 8, 2026, an external attacker compromised two internal servers
(WS-042 and SRV-001) via an SSH brute-force attack against a user account
with a weak password. The attacker accessed the finance database before
being detected and contained within 65 minutes of first suspicious activity.

No confirmed data exfiltration was detected. Forensic analysis is ongoing
to confirm this with high confidence.

The attacker leveraged a combination of weak authentication policy (no
account lockout, no MFA on VPN) and an unpatched SSH version. Both issues
have been remediated. No systems remain compromised as of this report.

Root cause: Weak password policy + no account lockout on external-facing SSH.
Business impact: 4 hours of SRV-001 downtime; finance database inaccessible.
Regulatory outcome: No notification obligation identified (no confirmed exfiltration).

2.2 Technical Timeline

A forensic timeline in UTC. Every event must cite its evidence source.

DATE        TIME (UTC)  EVENT                                     SOURCE
────────────────────────────────────────────────────────────────────────────────
2026-06-08  14:30:02    Brute force begins (47 attempts)         auth.log:line 8442
2026-06-08  14:30:48    Successful SSH login as alice             auth.log:line 8489
2026-06-08  14:30:49    Sudo to root                             auth.log:line 8490
2026-06-08  14:31:02    PowerShell download cradle executed       Sysmon:EventID 1
2026-06-08  14:31:15    C2 connection established (185.220.101.5) Sysmon:EventID 3
2026-06-08  14:31:33    Lateral movement to SRV-001 (PtH)        security.evtx:4624
2026-06-08  14:32:41    Service persistence installed             security.evtx:7045
2026-06-08  14:33:02    Web shell deployed (/uploads/sh3ll.php)  access.log:line 2301
2026-06-08  15:15:00    Incident detected by SIEM correlation     SIEM alert #4821
2026-06-08  15:31:05    Containment: 185.220.101.5 blocked        FW change log
2026-06-08  15:32:20    Containment: WS-042 isolated (VLAN 999)  Switch config log
2026-06-08  15:33:15    Containment: SRV-001 isolated             Switch config log
2026-06-08  17:45:00    Eradication complete (persistence removed) IR ticket notes
2026-06-08  19:30:00    Recovery: SRV-001 restored from backup    IR ticket notes
2026-06-08  20:15:00    Service restored to production           Change management

2.3 Root Cause Analysis

Answer: why did this happen? Use the 5-Whys technique.

Immediate cause:    Attacker successfully brute-forced the alice account.

Why?               The alice account had a weak password (8 chars, dictionary word).

Why was a weak password allowed?
                   The password policy did not enforce minimum complexity on SSH accounts.

Why?               The SSH configuration was managed manually, outside the organisation's
                   password policy GPO which only applies to Windows.

Why?               Linux server SSH configuration was never included in the security
                   baseline review process.

Root cause:        Incomplete security baseline coverage — Linux SSH servers were excluded
                   from the standard hardening and policy enforcement process.

Contributing factor: No account lockout after N failed SSH attempts.
Contributing factor: No MFA on the VPN gateway that provided SSH access.

2.4 Lessons Learned & Action Items

This section drives real improvement. Every lesson must have an owner and a due date.

LESSONS LEARNED

1. No account lockout on SSH
   Action: Configure fail2ban on all external-facing SSH hosts
   Owner: SysAdmin team
   Due: 2026-06-15 (7 days)
   Success metric: fail2ban active on 100% of external SSH hosts

2. Linux SSH not covered by password policy
   Action: Extend password policy audit to cover all Linux SSH configurations
   Owner: Security team + SysAdmin
   Due: 2026-07-08 (30 days)
   Success metric: Policy audit completed and gaps documented

3. No MFA on VPN
   Action: Deploy MFA for all VPN users (Microsoft Authenticator or TOTP)
   Owner: IT Infrastructure team
   Due: 2026-08-08 (60 days)
   Success metric: MFA active for 100% of VPN users

4. SIEM MTTD = 45 minutes (too long for a P1)
   Action: Review composite detection rule thresholds; add rule for >10 SSH failures
           from external IP within 60 seconds
   Owner: Security engineering
   Due: 2026-06-22 (14 days)
   Success metric: SSH brute force detected within 5 minutes in next tabletop

2.5 Evidence Inventory

EVIDENCE INVENTORY

Item ID  Description                        Hash (SHA-256)         Location
EX-001   WS-042 disk image (512 GB)         a3f9b2...             Evidence locker shelf 2
EX-002   SRV-001 disk image (1 TB)          b4c8d1...             Evidence locker shelf 2
EX-003   Memory dump, WS-042 (16 GB)        c5d9e2...             Evidence locker shelf 2
EX-004   auth.log (WS-042)                  d6e0f3...             IR shared drive /evidence/
EX-005   security.evtx (SRV-001)            e7f1a4...             IR shared drive /evidence/
EX-006   Malware binary: update.exe         f8g2b5...             Malware sandbox; quarantined

3. Writing Style Rules

Rule Example
Past tense throughout "The attacker installed a service" not "installs"
UTC timestamps always "14:30:48 UTC" not "2:30 PM"
Evidence citation for every factual claim "auth.log line 8489 shows..."
No speculation "Possibly the attacker may have..." → delete
No blame of individuals Blame policies and processes, not people
Precise language "The finance database" not "some data"

4. Common Mistakes

Mistake 1: "No evidence of exfiltration" stated without investigation. This claim requires active verification (checking DNS query volume, outbound transfer sizes, cloud storage logs). If you have not checked, write: "Exfiltration investigation ongoing."

Mistake 2: Omitting the evidence hash from the inventory. Without hashes, evidence provenance cannot be verified. Every exhibit needs a SHA-256.

Mistake 3: Action items without owners and due dates. "We should improve our monitoring" is not an action item. It is a wish. "Deploy SSH fail2ban on all external hosts by June 15 — Owner: SysAdmin team" is an action item.

Mistake 4: Writing for only one audience. The executive summary and the technical timeline serve different readers. Both must be present and clear.

5. Practice Exercises

  1. Convert this vague executive summary sentence into a precise, evidence-based one: "The attacker got in somehow and accessed some of our data before we stopped them."

  2. Write a Lessons Learned action item for this finding: "The SIEM had no rule for detecting new Windows services installed outside business hours."

  3. An evidence inventory lists a disk image but no hash. What is the risk? How do you remediate it?

6. Lab

Assessment mode: quiz

You are given a draft post-incident report with 6 deliberate errors. Identify and correct each one. Errors include: - Missing evidence citation - Local timezone instead of UTC - Speculation stated as fact - Action item without owner - Exfiltration conclusion without investigation - Executive summary contains technical jargon

7. Framework Alignment

Framework Role Competency Confidence
CCSSF-CIR Cyber Incident Responder Post-incident documentation High
CCSSF-ISSO ISSO / Generalist Governance documentation and audit evidence High
NICE 2.2.0 Incident Responder (PR-IRP-001) K0041 — Incident reporting and documentation High

8. Further Reading

  • NIST SP 800-61 Rev.2 — Appendix A has a sample incident handling log format
  • ENISA Good Practice Guide: Incident Management — Section 4 covers post-incident analysis in detail
  • "Incident Response & Computer Forensics" — Luttgens, Pepe, Mandia — Chapter 14 on reporting
  • The DFIR Report — https://thedfirreport.com — Public post-incident reports; study the structure and language

Learning Objectives

["Write a one-paragraph executive summary for a described incident that is accurate, jargon-free, does not speculate, and is honest about what is unknown", "Produce a technical timeline entry for three described events that includes the UTC timestamp, event description, ATT&CK technique ID, and evidence source citation", "Write three Lessons Learned action items from a described incident's root cause analysis, each with a specific remediation action, named owner, due date, and measurable success metric"]

Lesson Outline

Prerequisites → Why this matters → Report purpose and audiences → Section-by-section (executive summary, technical timeline, root cause 5-whys, lessons learned with action items, evidence inventory) → Writing style rules → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading