Writing the Attack Narrative in a Pentest Report

An attack narrative is the part of a pentest report that tells, in order, how separate findings were combined to reach an outcome: where the testers started, each step they took, the finding each step relied on, and what it gave them. Findings tell a client what is wrong. The narrative shows what those weaknesses add up to, and where a single fix would have broken the chain.

When a report needs one

A narrative earns its place whenever findings were chained to reach something worse than any one of them. That is the usual shape of an internal infrastructure test, an assumed breach or a red team engagement, and it happens on web applications more often than reports admit: an information leak that makes an access control flaw exploitable is a different risk from either on its own.

It does not belong where findings are independent. Forcing a story onto five unrelated issues suggests a connection that is not there, and a careful reader will notice. When nothing chained, the findings are the story.

Put it after the executive summary and before the detailed findings, so the reader moves from the outcome, to how it was reached, to each weakness in turn. In a long report the full version can sit in an appendix with a short one up front.

The shape of a good narrative

Open with two sentences: where the testers started and what they reached. Then give each step in order, and for each step say four things: what was done, the weakness it relied on, what it gave, and the evidence for it. A table keeps the steps comparable:

Step	What we did	Relied on	What it gave us
1	Registered a free trial account	Open sign-up, which is by design	A signed-in user in an organisation of our own
2	Changed the organisation number in a report request	No ownership check on the reports API (finding 1)	Every other organisation’s reports
3	Read an API key in an exported report’s details	Secrets written into exports (finding 3)	A key for the integration API
4	Called administrative functions with that key	Integration keys not limited in scope (finding 2)	The power to change any user’s role in any organisation

Then close with the outcome in plain terms: any member of the public could take administrative control of any customer’s organisation. That sentence is what the executive summary quotes, and the table is what makes it believable.

Notice that step one relied on no finding at all. Narratives often start from something the client chose deliberately, and saying so is fairer than inventing a weakness to start from.

The right level of detail

A narrative is written for people who will decide what to fix, not as a record of every command typed. Give enough for a technical reader to follow each step and find the finding behind it, and keep the requests, responses and tool output in each finding’s evidence, where they can be checked properly. Pentest evidence that survives peer review covers what that evidence needs.

Two details are worth adding that most narratives leave out. Give the time of each step and the address it came from, because the client’s detection team will want to know which steps they saw and which they missed; that turns the narrative into a test of their monitoring as well. And say how long the whole chain took, since a route that took two days and one that took two weeks are different risks.

Rate the findings, narrate the chain

Each finding in the chain keeps the rating it deserves on its own evidence. Raising every link to critical because the chain was serious destroys the ratings’ meaning, and the next report that uses them honestly looks soft by comparison. CVSS was designed to rate vulnerabilities one at a time, so each finding’s score should describe the weakness in front of it; CVSS scoring mistakes in pentest reports covers scoring each one well.

The combination is what the narrative and the executive summary carry. The finding says the reports API lacks an ownership check, rated on its own merits; the narrative says that check was the door to every customer’s organisation.

Show where the chain breaks

The most useful paragraph in a narrative is the one that says which fixes would have stopped it. Go through the steps and say, for each, whether fixing that finding alone would have ended the route. Usually one or two fixes break the whole chain, and those are what the client should do first, whatever their individual ratings say.

In the example above, the ownership check at step two ends everything after it, and limiting the integration keys at step four contains the damage even if a key leaks some other way. Saying so gives the client an order to work in, and gives the remediation in each finding a reason. Writing remediation a developer will actually action covers the rest.

Report the routes that failed

Most testers try several routes before one works. The ones that failed are worth a short paragraph: the defences that stopped them are things the client is doing right, and knowing what held tells them what not to undo in the next change. It also shows the scope of the work honestly, which matters when somebody later asks why a particular attack was not tried; proving what you tested when a client asks covers that conversation.

Write it from notes kept at the time

A narrative written from memory on the last day misses steps and gets times wrong. Keep a running log as you test: the time, the source, what you did and what came back, with a reference to the screenshot or output that shows it. The narrative is then assembled from the log rather than remembered, and every step already points at its evidence.