4.3.2. Forensic Analysis and Lessons Learned

💡 First Principle: Post-incident forensics and lessons learned are investments in the next incident — they transform reactive response into proactive improvement, turning each incident into a data point that makes the organization harder to attack next time.

Forensic Analysis

Deep technical investigation after containment to answer: exactly how did the attacker get in? What did they do? What data was accessed or exfiltrated? What tools did they use? How long were they present?

Forensic analysis uses preserved evidence: memory dumps, disk images, log archives, network captures. Tools: Autopsy (disk analysis), Volatility (memory analysis), Wireshark (PCAP analysis), log analysis platforms.

Key forensic artifacts:

• Windows: Event logs (Security, System, Application), prefetch files (evidence of program execution), registry hives, browser history, $MFT (file system journal), Windows.edb (search index)
• Linux: auth.log, syslog, bash_history, /proc filesystem, cron job logs, lastlog
• Web server: access and error logs (Apache access.log / error.log, nginx equivalents) record every request, so injection strings, path traversal, scanner user agents and bursts of 401/404/500 responses show which web attack vectors were attempted and when
• Network: PCAP files, NetFlow records, proxy logs, DNS query logs, SIEM correlation

Timeline pitfalls. Timestomping rewrites a file's timestamps so malware looks older than it is (MITRE ATT&CK T1070.006), and a PE header's compile timestamp is just a field the author sets, so an old compile date says nothing about when the file reached this system. The $MFT records when the file was written to this volume; because its $STANDARD_INFORMATION times can be edited too, cross-check them against the harder-to-alter $FILE_NAME times, prefetch and log entries.

Root Cause Analysis (RCA)

RCA determines the underlying cause — not just what happened, but why. The "5 Whys" technique: ask "why" repeatedly until reaching a root cause that, if addressed, prevents recurrence.

Example:

1. Why was the server compromised? → Exploited unpatched vulnerability
2. Why was the vulnerability unpatched? → Patch management process missed it
3. Why did patch management miss it? → Server wasn't in the asset inventory
4. Why wasn't it in inventory? → Deployed by a developer as a temporary test server that became permanent
5. Root cause: No process for scanning for unregistered systems and bringing them into the asset management program.

The fix addresses the root cause (implement continuous asset discovery) rather than just the symptom (patch the server).

Lessons Learned

Documented in a formal post-incident report (also called After Action Report or Post-Mortem), lessons learned should be completed within days of incident closure while details are fresh. Key elements:

Lessons learned only create value when recommendations are implemented. The post-incident report should include assigned owners, deadlines, and a follow-up review date.

Write each finding as a specific change with an owner, not a slogan: "improve SIEM detection" or "respond faster" changes nothing, while "write and test a detection rule for this technique by a set date" does. When the finding is a decision delay (for example, containment waited hours for full scoping), the fix is a decision rule in the IR playbook stating the criteria at which containment starts in parallel with scoping; more or faster analysts working the same sequence leave the delay in place. When a board asks whether an incident was preventable, answer from the findings by naming the specific controls that would have prevented or limited it (for example timely patching, MFA on admin accounts, behavioral detection).

⚠️ Exam Trap: Root cause analysis and lessons learned are post-incident activities — performed after the incident is fully contained and remediated, not during active response. During active response, the priority is stopping damage. Post-incident is when you analyze how and why.

Corrective Action Development

Quality management separates two responses to a failure. A correction fixes the instance, such as resetting the phished user's password. A corrective action eliminates the cause so the failure does not recur, such as requiring phishing-resistant MFA on every VPN login. Root cause analysis connects the two: a corrective action aimed at a symptom changes nothing.

A well-developed corrective action has:

1. A stated link to the root cause it removes
2. A named owner and a deadline
3. Measurable completion criteria
4. A verification step that proves it works, for example reproducing the attack technique in a lab and confirming the new detection fires

A closed ticket, or several quiet weeks, does not verify a corrective action. The first records completion; the second is absence of evidence.

Choosing an RCA Technique

The two combine well: brainstorm on the fishbone, then drill the likeliest branch with the 5 Whys.

⚠️ Exam Trap: A named person's mistake ("the analyst missed the alert") is a symptom, not a root cause. Ask why the process let it happen.

Evidence retention after closure. When prosecution is possible, NIST advises keeping evidence until all legal actions are complete, which can take years, under a retention policy agreed with legal.

Reflection Question: An organization's IR team responds to a phishing-based intrusion. The attacker used a stolen VPN credential (the user clicked a phishing link that harvested their VPN credentials with an MFA bypass via adversary-in-the-middle proxy). Root cause analysis finds the organization's MFA used push notifications, which were susceptible to MFA fatigue. The recommendation is "implement phishing-resistant MFA (FIDO2)." Six months later, the same attack vector succeeds again. What failed in the lessons learned process, and what governance mechanism would have prevented this?