Turn a CTI Report into a Tested Detection with ATT&CK Mapping

Tier: Advanced · Workflow area: Detection engineering with AI

This playbook runs the full pipeline — extract the techniques and IOCs, map them to ATT&CK, generate a candidate detection, and test it — with verification at every hop, because each step is a place the model can quietly fabricate a technique, an indicator, or a field.

When to reach for this

• •
  A CTI report lands describing a campaign or malware and you need coverage fast.
• •
  You want a repeatable path from unstructured intel to a tested rule, not a one-off manual read.
• •
  You are building a detection-from-intel capability and want the human checkpoints designed in.

Skip AI when the report already ships with vendor-authored, tested detections for your stack — validate theirs rather than regenerating.

The workflow

1. 1.

   Extract behaviors and IOCs with citations back to the report. Prose in, structured facts out — each anchored to the sentence it came from.

   Copy

   From this threat report (pasted), extract:
   - Adversary behaviors, each mapped to the most specific MITRE ATT&CK
     technique ID you can justify.
   - IOCs (hashes, IPs, domains, filenames), typed.
   For every item, quote the sentence from the report it came from. If a
   technique mapping is a guess, mark it LOW CONFIDENCE. Do not add techniques
   or IOCs that are not stated in the report.
   

   Expected output: a behavior→technique table and a typed IOC list, each row quoting its source sentence, with weak mappings flagged.

2. 2.

   Verify the ATT&CK mappings against the matrix. Open each cited technique in ATT&CK Navigator and confirm the report's described behavior actually matches that technique's definition. Models routinely map to a related technique that is subtly wrong — T1059 (command interpreter) where the report describes T1053 (scheduled task).

3. 3.

   Verify IOCs against the source text. Confirm every extracted hash/IP/domain appears verbatim in the report. A transposed character in a hash makes the resulting detection worthless. This is a literal string-match check.

4. 4.

   Generate a candidate detection for a behavior worth detecting. IOCs age fast; prioritize a behavioral detection. Feed the verified technique into the Sigma authoring flow (see pb-06) and compile it to your SIEM.

5. 5.

   Test against known-bad and known-good. Reproduce the behavior safely with an Atomic Red Team test where one exists, confirm the rule fires, then confirm it stays silent on benign sample data. An untested intel-derived rule is just a rumor in YAML.

6. 6.

   Record provenance end to end. The final artifact links report → technique → rule → test result, so a reviewer can trace why the detection exists and what it was proven against.

Verify before you trust it

• Citation check on extraction: every technique and IOC must quote a source sentence. A row with no quote is the model adding intel the report never contained — delete it.
• Technique-definition check: compare the report's behavior to the ATT&CK technique's actual description, not just its name. Near-miss mappings corrupt your coverage map and send you building the wrong detection.
• False-positive catch: the known-good test is decisive. An intel-derived rule keyed on a common LOLBin will flood your queue; prove it stays quiet on benign activity before deployment.

Pitfalls

• IOC-only detections. Hashes and IPs rotate within days; a rule built only on them is stale on arrival. Extract the behavior and detect that.
• Confident mis-mapping. The model maps to a plausible-adjacent technique with full confidence. Only checking against the matrix definition catches it — and a wrong mapping silently misdirects your whole build.
• Trusting report accuracy. CTI reports themselves contain errors and low-confidence attributions. Preserve the report's own uncertainty; do not launder a "possibly linked to" into a firm detection rationale.
• Skipping the reproduction test. Without an Atomic Red Team or crafted sample, you never confirm the rule fires on the behavior it targets. Test or do not deploy.

Tools

• MITRE ATT&CK Navigator: the ground truth for verifying technique mappings and visualizing the new coverage.
• Sigma + pySigma: turns the verified behavior into a portable, testable rule (hands off to pb-06/pb-07).
• Atomic Red Team + STIX/MISP: reproduce the behavior for known-bad testing and store the extracted IOCs in a structured, shareable form.

Client-safe variant

Threat reports are often shared under TLP restrictions, and the resulting detections reveal a client's coverage — both are sensitive. Run extraction and mapping on a local Ollama model or the client's approved endpoint, and honor the report's TLP marking: TLP:RED intel does not go into any shared or third-party tool. Verify mappings against the public ATT&CK matrix (safe to consult). Keep IOC handling, rule generation, and testing inside the client's environment, and record the full provenance chain in the client's detection repo so their analysts can audit why each intel-derived rule exists and what it was tested against.