The Backstory Report

The report is Backstory's answer: what happened, how far it reached, which indicators are worth acting on, and the evidence behind each of those claims. It is written to be read by a person and to be handed to another person, which is why it is a narrative with citations rather than a list of hits.

What is in the report?

Four views over one investigation, so you can read it at the altitude you need.

• Investigation Summary. The verdict, the severity, and the story: what this was, staged in the order it happened, with the handful of factors that drove the assessment. Then the affected machines, a connection map of what touched your environment, and the recommended actions in severity order.
• Findings Details. The same findings, expanded. Per file, per machine, per indicator, with the sightings, paths, and filenames underneath each one. This is the view to open when someone asks "how do you know".
• Intelligence. What the case looked like from the outside: the YARA rules involved and what they match, the network picture, and the related file clusters.
• MITRE Coverage. The techniques observed, each with the evidence for it and the specific files that exhibited it, plus the kill chain phases the case touched.

Switching tabs does not refetch anything. It is one report seen four ways.

How do I read a disposition?

Every indicator in the report carries a disposition instead of arriving as an undifferentiated list. There are three, and they are instructions, not scores.

• Block. Act on this. Backstory concluded it is part of the intrusion.
• Monitor. Watch this. There is real evidence, and not enough of it to justify blocking.
• Ignore. Explained. It came up in the investigation and Backstory concluded it is not part of the problem.

Each one carries its reason, and the reason is the first thing in the row. Read it before you act, because the reason is where the interesting exceptions live.

The most useful of those exceptions: when a hostname would otherwise be blocked but turns out to be in broad legitimate use, Backstory lowers it to Monitor and the row says so. That is deliberate. A block on a name half your fleet depends on costs more than the malware did, so the report tells you what it found and why it stopped short of recommending you break something.

Two more precedence rules worth knowing, because they explain results that would otherwise look inconsistent:

• Your own verdict wins. If your team has recorded an opinion on a file, that is the disposition, and no automated signal overrides it.
• A file's own clean assessment beats guilt by association. A file that resembles something malicious, or that shares infrastructure with something malicious, is not convicted on that alone when its own analysis says it is benign. The relationship stays visible in the report, because it is a real fact, but it does not become a verdict.

How are findings supported?

Every finding cites what it rests on, and every identifier in the text is a link back into the platform.

Hashes, hostnames, and IP addresses in the narrative and in the recommendations are linked to their own pages in Stairwell, so checking a claim is one click rather than a copy and paste. MITRE entries name the observed evidence and the specific files that exhibited the technique. Affected machines are listed with the files found on them and the paths they were found at. The staged narrative carries supporting facts as bullets under each stage rather than as prose you have to trust.

The recommended actions are built from the investigation's own record of each indicator, not written as prose alongside it. That is why the action list and the findings cannot drift apart: they are two renderings of the same recorded facts.

Because everything Backstory used is data you also have, verification is not a special workflow. Open the file in Stairwell, look at its prevalence and its sightings, and you are looking at the same evidence the report is.

What does the report say about what it could not establish?

It says it explicitly, which is the part to look for before you treat a report as complete.

The report carries a gaps section for the questions the investigation could not close. And where a file was seen on more machines than the investigation enumerated, the report carries the true count and a follow-up item, so a partial blast radius is never read as the whole one.

This is worth stating plainly: a report that says "these three questions are still open" is more useful than one that quietly rounds them off, and Backstory is built to say it.

What if I disagree with a finding?

Record your verdict and regenerate the report.

Set an opinion on the file, hostname, or address you disagree about, from the graph or from the report, then regenerate. The findings, the dispositions, and the recommendations are rebuilt around your call, and the report records that a human overrode a machine conclusion. The investigation stops being Backstory's opinion and becomes your team's, with the reasoning intact.

This is the intended workflow, not a workaround. Backstory does the legwork and the correlation; the judgment is yours, and the report is built to accept it.

What should I read next?

• Campaign Awareness, which explains the campaign headings you will see in the recommendations and the MITRE tables.
• Sharing a Backstory Report, for the link, the downloadable file, and the machine-readable form.
• Verdicts and Opinions, the two inputs that decide most dispositions.