Claude Skill: threat-report-killchain

Everyday when I come across a threat intelligence report, I have to sift through a lot of data to get to the gist of it. Hence, I created this “threat-report-killchain” Claude skill to automate the process of CTI report triage for me. It does so completely, well 80% to be precise. Since, it helped me a lot, I thought of open sourcing it for the community. This post describes the skill in detail. Read on!

What is: threat-report-killchain Claude Skill?

threat-report-killchain is a highly optimized and parallelized Claude skill that helps you turn vendor reports into something that a detection engineering team can use. Simply point it at a PDF, a Word doc, or a URL and the skill returns an evidence-cited kill chain, a full ATT&CK/ATLAS mapping, a Diamond Model, extracted IOCs, and enrichment against MITRE and VirusTotal. How does it do it?

Functions: threat-report-killchain

These are the current functions provided by the threat-report-killchain Claude skill:

• Takes a URL, PDF or document as an input.
• Extracts IPv4 and IPv6 addresses, email addresses, full-length MD5/SHA1/SHA256 hashes, CVE IDs, Windows registry keys, Windows and Unix file paths, and domains.
• Re-fangs defanged notation (hxxp, [.], (dot), [at], [:]) before matching, so obfuscated IOCs in the source text still get caught.
• Re-defangs captured domains/IPs/emails in the output for safe display.
• Captures ~60 characters of surrounding text as an evidence snippet for every match.
• Deduplicates all indicators case-insensitively.
• Outputs a JSON file with the extracted indicators plus empty scaffold fields that can be used by an analyst to add.
• Resolves extracted threat-actor names and aliases against the MITRE ATT&CK STIX dataset’s intrusion set objects, case-insensitive exact match.
• On match: returns the group’s ATT&CK ID (Gxxxx-ID), known aliases, a truncated description, and its associated techniques and software, pulled from real uses relationships in the STIX graph.
• On miss: returns up to 5 substring-based name suggestions without asserting a false match, and reports it plainly as a non-match.
• Validates every ATT&CK technique ID the analyst claimed in the analysis against the actual dataset, flagging any that don’t exist.
• Fetches full-length file hashes (MD5/SHA1/SHA256) against VirusTotal’s file API. Returns detection ratio, malicious/suspicious/undetected engine counts, known file names, and file type per hash. Reads the API key from an environment variable; if none is set, skips the step cleanly and says so, rather than failing the whole run.
• Converts the finished analysis into a STIX 2.1 bundle for ingestion into an internal TIP, MISP, or OpenCTI instance.
• Not to forget – all code in the skill is highly parallelized and optimized.

With the details out of the way, these are the more verbose details and show you a bit of the workflow:

• Ingestion: PDF, DOCX, or URL, all normalized to plaintext with the source attached, so every citation traces back to where it came from. A scanned-image PDF or a paywalled page gets flagged, and the run stops instead of analyzing garbage. If a source only half-cooperates (a vendor won’t hand over its own IOC table verbatim, only category summaries), it doesn’t paper over that. It re-tries with a narrower ask, and whatever still won’t come through gets named in the report’s limitations section. No silent gaps.
• Extraction:
  • Track one is regex: IPv4/IPv6, domains, emails, full MD5/SHA1/SHA256, Windows and Unix paths, registry keys, CVEs. It re-fangs defanged IOCs before matching (hxxp, [.], (dot), [at]), so 185[.]132[.]53[.]56 still gets caught.
  • Track two is judgment, not regex. It reads the narrative for malware family names and actor aliases, since no pattern catches those. Each one gets tagged with evidence and a confidence flag: actually named versus just mentioned in passing.
• Analysis: Every distinct behavior gets an ATT&CK technique ID, a slot in the Lockheed Martin kill chain, and a place in the Diamond Model (Adversary, Capability, Infrastructure, Victim). ATLAS gets scoped per incident, not per report. A report with six cases might have exactly one where the AI supply chain is the target, and that’s the only one that gets ATLAS IDs. Every ID is claimed, ATT&CK or ATLAS, and gets checked against the real framework data before it is added. Reports get split into separate incident clusters instead of flattened into one blob. Nothing is added without a citation, quote or clear paraphrase, and confidence is scored against a fixed rubric – High/Medium/Low/Speculative.
• Enrichment: Actor names get checked against a locally cached MITRE ATT&CK STIX dataset: real intrusion-set objects, their aliases, associated techniques and software through actual uses relationships. Once it’s cached, this step never touches the network again. A name that doesn’t resolve gets reported as a non-match, full stop, not force-fit onto the nearest-sounding group. Plenty of tracked crews never get an ATT&CK group ID, and pretending otherwise is worse than saying nothing. Hashes are sent to VirusTotal. A free key throttles to stay under rate limits, while a premium key lookups are handled via a multi-threading method. These results then get cached to disk so re-running overlapping reports doesn’t burn quota twice. If no key is counf configured, then the step itself is skipped with a noted in the report. A few sample reports can be found here.

Download: threat-report-killchain

Download the threat-report-killchain v4 Claude Skill here.