Writing the attack narrative

Objective 5.2 in this course covers documentation — CompTIA describes it as creating attack narratives and providing remediation recommendations. This lesson takes the narrative; lesson 41 takes remediation.

Why this matters

The attack narrative is what makes a report more than a list of findings. It is the story of how the individual weaknesses combined into a real compromise — and it is usually the part a client actually acts on, because it is the part that shows what their vulnerabilities mean together.

Domain 1 and Domain 5 bookend PenTest+ on communication for this reason: the engagement produces a shell, and the narrative is what turns that into something the client can understand and fund a fix for.

The lesson

The story from first access to objective, in order

The narrative is chronological: it walks from the initial foothold to the final objective, in the order it happened, so a reader can follow the path an attacker took.

• Start where the attacker started — the initial access, and what made it possible.
• Each step leads to the next. This finding gave that access, which yielded that credential, which reached that host. The route logged in lessons 37 and 38 is the spine of this.
• End at the objective — the data, the domain control, the business impact that the whole path was building towards.

Written in order, it reads as a story with cause and effect, which is what makes it comprehensible to a non-specialist. A reader who cannot follow your findings individually can follow "they got in here, and that let them reach there, and from there they could take everything."

Tying each step to evidence a client can verify

A narrative is only as trustworthy as the evidence under it, and lesson 6's standard applies to every step.

• Each step references its finding, so the narrative is a path through the detailed findings rather than a separate claim. The reader can drill from the story into the evidence for any hop.
• The evidence is captured, timestamped, and reproducible (lessons 6, 18) — the same artefacts that support the individual findings, assembled into sequence.
• The timeline is exact, drawn from the activity log (lesson 8), so the client can reconcile the narrative with their own telemetry.

The reason this matters: a narrative that cannot be verified reads as a story you told rather than a path you demonstrated, and lesson 18's warning applies — one step a client can disprove undermines the whole chain. The narrative is powerful precisely because every step is backed, so build it only from steps you proved.

Showing the chain, so a single low finding's real impact lands

This is the narrative's most valuable service, and the argument for why it exists at all.

Findings are scored individually (lesson 6), and scored individually they mislead:

• Two mediums that chain to full compromise are reported as two mediums by a findings list, and as a critical by the narrative that connects them. The scanner cannot see the chain (lesson 15); the narrative is where a human supplies it.
• A low-rated finding can be the linchpin. An information disclosure that seems trivial alone may be the step that made the whole path possible — and the narrative is what shows the client why they cannot safely ignore it.
• The chain is the real risk. The client's actual exposure is not the highest individual finding; it is the worst path through all of them, and only the narrative expresses that.

So the narrative does what no findings table can: it demonstrates that the risk of a set of vulnerabilities is a property of how they combine, and it justifies fixing something that looked minor by showing what it enabled. This is the whole reason a penetration test is worth more than a scan.

Where the client's detection did and did not fire

The narrative carries the defender's half that every Domain 4 and 5 lesson has been building, and it belongs woven into the story rather than bolted on.

• At each step, note what the client's monitoring saw — an alert that fired, a log that recorded it, or silence.
• Silence is a finding. A step that produced no detection is a gap, and placing it in the narrative shows where in a real attack the client would have been blind.
• Detections that fired are worth stating positively — they are working controls, and a client deciding where to invest needs to know what already works as much as what does not.

This turns the narrative into a dual-purpose document: the attack path, and a map of the client's detection coverage along it. A client reading it learns not just how they were compromised but at which points they might have caught it — which is often the more actionable half.

Writing it so it can be re-run by someone else

The test of a good narrative, and it is the same test as a good finding.

• Reproducible end to end. Someone with the report and the environment should be able to follow the narrative and observe the same path — which is what lets the client confirm the fix worked by finding the path now blocked.
• Complete in its steps. No hop is hand-waved; each is a real, evidenced action. A narrative with a gap ("and then we had domain admin") is one the client cannot verify or trust.
• Self-contained. It stands on the evidence it references, not on the reader having watched you work.
• Honest about assumptions. Where a step relied on a condition — a user clicking, a particular configuration — say so, because the client's fix may be to remove that condition.

The re-run standard connects the whole report: a narrative that can be re-run is one the client can use to verify remediation (lesson 41), which is the point of the report and the thing that makes the engagement worth repeating.

What to take into the exam

• The attack narrative is the chronological story from first access to objective, each step leading to the next, ending at the business impact.
• Every step references verifiable, timestamped, reproducible evidence; an unverifiable step undermines the chain.
• The narrative supplies what a findings list cannot — the chain — so two mediums that combine to a compromise are shown as the critical they really are, and a low-rated linchpin is justified.
• It records where the client's detection did and did not fire, doubling as a coverage map, and it is written to be re-run so remediation can be verified.