Incident Response and Forensics

"A pentest asks 'can someone get in?' beforehand. Incident response asks 'someone got in — now what?' afterward. Both matter, but only one of them happens on the worst day of your week."

From Prevention to Response

Everything earlier in Part 3 has been about reducing the odds and impact of an attack: modeling threats, closing common attack vectors, scanning for weaknesses, testing defenses. Incident response (IR) is what happens when, despite all of that, something bad occurs anyway — a compromised host, exfiltrated data, an unexplained outage that turns out to be malicious. No amount of prevention makes IR unnecessary; it just lowers how often you need it.

The Incident Response Lifecycle

The widely taught NIST model breaks incident response into four phases:

Notice the cycle closes back on itself — a good post-incident review directly strengthens preparation for the next one, which is why mature organizations treat every incident, however small, as an opportunity to improve rather than just an emergency to survive.

Network Evidence: What to Look At

For network-facing incidents specifically, a few categories of evidence recur constantly:

• Packet captures — a full or filtered capture (Chapter 5.5) around the suspected timeframe can show exactly what was sent and received, which is often the only unambiguous record of what actually happened on the wire.
• NetFlow/connection logs — even without full packet content, records of who talked to whom, when, and how much data moved, can reveal a data-exfiltration pattern or an unexpected internal-to-external connection.
• Application and system logs — authentication attempts, error logs, and access logs often show the earliest signs of an intrusion, well before it becomes an obvious outage.
• DNS query logs — malware frequently reaches out to a command-and-control domain before doing anything else; DNS logs can catch this even when the payload itself is encrypted.

Chain of Custody

If an incident might lead to legal action, employee discipline, or regulatory reporting, evidence handling matters as much as evidence discovery. Chain of custody means being able to show, unbroken, who collected each piece of evidence, when, how it was stored, and that it wasn't altered along the way. In practice this means: hashing captured files immediately (so any later modification is detectable), logging who accessed evidence and when, and preferring read-only copies over working directly against a live, mutable system.

A Small Go Example: Flagging Suspicious Log Lines

Real IR tooling ranges from SIEM platforms (covered in a later chapter) to purpose-built forensic suites, but the underlying pattern-matching idea is simple enough to sketch directly — a tiny triage tool that flags log lines matching known suspicious patterns, so a human reviewer can focus attention where it's most likely to matter:

package main

import (
	"bufio"
	"fmt"
	"os"
	"strings"
)

// suspiciousPatterns is a deliberately small, illustrative list; a real
// triage tool would draw from a much larger, maintained rule set.
var suspiciousPatterns = []string{
	"Failed password",
	"authentication failure",
	"unexpected EOF",
	"root login",
}

func triage(path string) error {
	f, err := os.Open(path)
	if err != nil {
		return fmt.Errorf("open log: %w", err)
	}
	defer f.Close()

	scanner := bufio.NewScanner(f)
	lineNum := 0
	for scanner.Scan() {
		lineNum++
		line := scanner.Text()
		for _, pattern := range suspiciousPatterns {
			if strings.Contains(line, pattern) {
				fmt.Printf("line %d: matched %q: %s\n",
					lineNum, pattern, line)
			}
		}
	}
	return scanner.Err()
}

func main() {
	if len(os.Args) != 2 {
		fmt.Fprintln(os.Stderr, "usage: triage <logfile>")
		os.Exit(1)
	}
	if err := triage(os.Args[1]); err != nil {
		fmt.Fprintln(os.Stderr, "error:", err)
		os.Exit(1)
	}
}

This is intentionally simple — a real detection pipeline would use structured logs, correlate across multiple sources, and score rather than just match substrings — but the core loop (read, match against known-bad patterns, surface for review) is the same shape underlying much more sophisticated tooling.

Forensics vs. Response

Incident response is about restoring safe, normal operation as quickly as reasonably possible. Forensics is about understanding, in as much verified detail as possible, exactly what happened — sometimes after the fact, sometimes in parallel with response. The two goals can pull in different directions: response wants to isolate and rebuild a compromised host immediately; forensics wants to preserve it exactly as-is for analysis. A mature IR plan decides in advance how to balance that tension rather than improvising it live, mid-incident.

Frequently Asked Questions

If I find a compromised host, shouldn't I just unplug it right away? Not necessarily, and this is exactly the tension the previous section describes — pulling power immediately can destroy volatile evidence like running processes and network connections that only exist in memory, while leaving it running risks the attacker noticing and covering their tracks further. A mature IR plan decides this tradeoff in advance (isolate at the network level first, capture memory before power-off, or whatever fits the organization) rather than someone guessing under pressure during the actual incident.

Why bother hashing evidence files if nobody's touched them? Hashing immediately after collection isn't about distrust of the collector — it's about being able to prove, later, that nothing changed after that point, which is the entire substance of chain of custody. Without a hash taken at collection time, there's no way to demonstrate to a court, a regulator, or even your own legal team that the file you're presenting is identical to what was actually on the compromised system.

Can the log triage tool from this chapter replace a real SIEM? No, and it isn't trying to — it's a deliberately small illustration of the core pattern-matching idea (read a line, check it against known-bad patterns, surface it for a human) that scales up into much more sophisticated tooling. A real detection pipeline correlates structured logs across many sources and scores findings rather than just matching substrings in a single file, but the underlying loop is genuinely the same shape.

How does incident response relate to the penetration testing from the last chapter? They're mirror images pointed at the same risk from opposite directions — a pentest asks "could someone get in" under controlled, authorized conditions, while IR answers "someone got in, now what" for real. A well-run pentest report often becomes preparation-phase input for IR: knowing in advance which paths an attacker is likely to take makes detection and containment faster when a real incident eventually happens.