How to Read a CTI Report Like an Analyst (Not a Journalist)
Vendor threat reports mix marketing, narrative, and actionable intelligence. A repeatable method for extracting IOCs, TTPs, and detection opportunities while filtering the noise.
Two ways to read the same PDF
A 40-page vendor report drops: new actor name, dramatic codename, a diagram with arrows crossing three continents. The journalist's reading takes the narrative at face value, retains the actor name and the scary quote, and shares the link. The analyst's reading treats the report as a raw material: some facts, some interpretation, some marketing, all of it to be processed into three concrete outputs.
Those outputs are always the same: indicators to sweep for, techniques to map, detections to build. Everything in the report either feeds one of them or gets skipped. Here is the pass-by-pass method.
Pass 1: Frame it before you read it (2 minutes)
Answer four questions from the header, the intro, and the publisher alone:
- Who published this and why? An AV vendor writes about malware their product catches. An IR firm writes about intrusions they were hired for. A government CERT writes about what was reported to it. None of these see the whole landscape; each sees a biased slice shaped by their customer base and telemetry.
- When is the underlying activity from? A report published today about intrusions from eight months ago is history, not warning. Check activity dates, not the publication date.
- Is this first-hand or aggregated? "We responded to twelve intrusions" is primary evidence. "Reporting suggests" is someone summarizing someone else, with errors compounding at each hop.
- Does this plausibly intersect my organization? Sector, geography, initial access vector, targeted technology. If none intersect, file the report and move on. Relevance triage is where most CTI time is won.
Pass 2: Strip the indicators (10 minutes)
Go straight to the appendix or IOC table. Extract everything: hashes, IPs, domains, URLs, file paths, mutexes, certificate fingerprints. Reports defang inconsistently (hxxp://, [.], (.)) and bury indicators in prose, so run the text through an extractor rather than copying by hand; the free IOC extractor on mlab.sh pulls and refangs them from pasted text in one step.
Then triage what you extracted, because report IOCs are not equal:
| IOC context in report | Treat as |
|---|---|
| "Observed in intrusions" with dates | Sweep + alert material |
| "Associated infrastructure" no dates | Hunt material, verify before blocking |
| Shared/CDN IPs, common tool hashes | Context only, never block |
| Victim-specific paths and filenames | Retro-hunt patterns, not literals |
The immediate action is retrospective: sweep your logs for the historical window of the activity, not just forward-block. If the campaign ran in May and it is July, the question is "were we hit?" before "will we be?"
Pass 3: Map the behavior (30 minutes)
This is the pass journalists never make and the one that outlives every indicator. Walk the narrative chronologically and write down each adversary action as an ATT&CK technique ID: spearphishing attachment (T1566.001), scheduled task persistence (T1053.005), LSASS dumping (T1003.001), exfil over web services (T1567).
Good reports do this mapping for you. Verify it anyway; vendors sometimes tag a technique on thin evidence, and the difference matters for the next step. Distinguish the procedure (the exact command line the actor ran) from the technique (the general behavior): procedures make precise detections, techniques define your coverage question.
For each mapped technique, ask three questions:
- Would we log it? Do you even collect the telemetry where this behavior appears?
- Would we detect it? Is there an existing rule, and would it fire on this specific procedure?
- If not, is it worth building? A gap only matters if the technique is relevant to your threat model.
The gaps that survive question 3 become detection engineering backlog. Reports frequently include exact command lines, registry keys, and process chains; those translate almost mechanically into Sigma rules. The workbench at hunt.mlab.sh is built for exactly this loop: author the rule, validate it, convert it to your SIEM's query language, and log the technique against your MITRE coverage map so the report measurably moved your posture.
Pass 4: Cross-reference the actor
Vendor naming is chaos: the same group is APT28 to Mandiant, Fancy Bear to CrowdStrike, and Forest Blizzard to Microsoft. Before treating a "new" actor as new, resolve the aliases. The profiles on actors.mlab.sh cover 500+ named groups with their aliases, known techniques, and linked CVEs, which answers the questions the single report cannot:
- Is this actor already in our threat model under another name?
- Does the reported tradecraft match their history, or is the clustering shaky?
- Which CVEs do they exploit, and are we exposed to any of them?
That last pivot is often the most actionable output of the whole exercise: an actor-CVE link plus a check of your own estate turns abstract intel into a patching priority.
Assessing confidence and bias
Keep a skeptic's checklist running through every pass:
- Language signals evidence. "We observed" beats "we assess" beats "it is likely" beats "sources indicate". Confidence wording (high/moderate/low) is meaningful in mature shops; treat unqualified certainty as a red flag, not reassurance.
- Attribution is the weakest claim. Country-level attribution rests on evidence you cannot inspect and rarely changes what defenders should do. Extract the how and stay agnostic on the who.
- Sample size hides in the prose. "A widespread campaign" built from two incident responses is two data points. Look for the number of victims, samples, or intrusions actually stated.
- Marketing gravity. Dramatic actor codenames, superlatives, and product screenshots correlate inversely with technical density. That does not make the facts wrong; it means the framing serves the vendor.
What to ignore
Be equally deliberate about what you skip: the geopolitical framing, the actor's speculative motivations, the timeline infographic, the closing product pitch. None of it changes a detection or a sweep. Reading discipline is capacity: an analyst who processes a report in ninety minutes with three concrete outputs beats one who reads five reports end to end and produces a summary email.
The end state for every report worth processing: IOCs swept and loaded with expiry dates, techniques mapped against your coverage, one or two detection tickets filed, actor record updated. Then archive the PDF. You have extracted what it had to give.
A CTI report is not news to consume; it is ore to refine. Extract the metal, discard the rock, and move to the next one.
