Why OSINT indicator feeds fail threat intelligence at scale

▶ Watch (00:06)

Palo Alto Networks tracks over 200 OSINT sources and crawls roughly 10,000 threat reports per week. No team reads that.

“The best thing about open source intelligence data is free.” — Dongdong Sun

The catch: free to collect, expensive to use. Indicator feeds give you a plug-and-play list of IOCs for your EDR, but they strip the context — why this indicator matters, what campaign it belongs to, which threat actor deployed it. That context sits in unstructured report text, buried across sources that overlap, contradict, and never talk to each other.

How knowledge graphs model threat actor relationships

▶ Watch (03:19)

Cybersecurity data is interconnected by nature. Threat actors link to malware, malware links to CVEs, CVEs link to attack patterns — and a knowledge graph captures those connections where STIX cannot. STIX is machine-readable but too rigid for humans and too verbose for LLMs. A knowledge graph sits between: semi-structured enough to constrain what you extract, loose enough to keep the contextual text that explains each entity. He walked through the BeyondTrust report → knowledge graph extraction and attack chain query (04:53) live. One 11-minute threat report about VShell and SparkRAT yielded over 100 entities and over 100 relationships, with previous campaigns, infection vectors, and a full exploitation chain all visible in a single graph.

Multi-step LLM pipeline for entity and relationship extraction

▶ Watch (07:34)

“LM has been very good at doing stuff, but then doing stuff reliable is you can’t just like one shot this thing from the get-go.” — Dongdong Sun

A single report can contain 100+ entities. Extracting them in one pass produces noise. Instead, the pipeline uses a skeleton extractor as a router: scan the report, identify what entity types are present, then dispatch each type to a dedicated extractor. MITRE ATT&CK patterns get a second pass, where the model generates candidate patterns, reads the relevant ATT&CK entries from a knowledge base, and corrects itself to a final mapping. Relationships use constrained triplets, limiting which entity-pair combinations are valid, while still attaching a free-text description to each edge so the graph captures how a relationship holds, not just that it does.

Building evaluation and prompt optimization when no benchmark exists

▶ Watch (09:55)

“The most important thing about this all this AI application is how you do your evaluation and this is the only indicator of quality of your data, especially for threat intelligence.”

No benchmark existed for extracting threat entities from long reports, so the team built one from scratch. Threat researchers hand-curated a small dataset, the model trained to 90% accuracy within two or three iterations, and each new batch required only a spot-check rather than full annotation. Automated prompt optimization hit a fix-one-break-another loop, so they split the prompt into a human-controlled section and an LLM-editable section. The reflection step surfaced a bonus: inter-annotator inconsistencies the researchers hadn’t caught themselves.

Graph-traversal agent for multi-hop threat intelligence queries

▶ Watch (13:52)

The agent pivots from a start node, walks the graph, and pulls subgraphs at each hop. For APT28, it resolves multiple aliases, then traverses malware relationships via semantic search to return a consolidated tool list — APT28 malware and tooling discovery via multi-hop traversal (15:37). A follow-on query asks what connects APT28 and APT29. The agent searches for co-occurrence (entities mentioned together in the same reports), shared CVEs, and shared infrastructure. It returns common tooling and attribution to Russian GRU and SVR, grounded entirely in graph nodes — APT28 vs APT29 relationship discovery using co-occurrence and alias resolution (17:44). Every answer includes a bracketed source citation tracing each claim to the originating node.

Q&A

How do you qualify the outputs and what are your failure rates for responses being incorrect analysis? Quality comes from rigorous evaluation on hundreds of threat reports, iterative decoding for large indicator sets, cross-checking against internal Palo Alto data sources, and forcing disagreeing threat researchers to align on a single ground truth — Sun says he spends more than 50% of his time on evaluation alone. ▶ 19:52

Did you do anything specific to prevent the LLM from hallucinating connections between APT28 and APT29 based on model knowledge rather than the knowledge graph? The fix is grounding the model to the knowledge graph exclusively and requiring every output statement to cite a bracketed source node, so the LLM cannot fall back on internal model knowledge about shared naming conventions like ‘bear’. ▶ 22:53

What kind of monitoring is in place to feed results back into the evaluation feedback loop during training and inference? During training, automated prompt optimization runs continuously against the benchmark — Sun noted that newer models and thinking models do not reliably beat older non-thinking models because thinking models over-rely on model knowledge rather than the grounded sources. During inference, LLM-as-a-judge runs in production but is treated as secondary to the evaluation dataset. ▶ 23:50

Are you looking at metadata to detect degrading attribution quality across OSINT sources — cases where the community makes claims without indicators? They haven’t looked deeply into this yet, but Sun suggested the graph itself acts as an informal evidence calibration: a well-supported attribution claim produces many connected nodes, while a thin news-report claim like the Notepad++ Chinese attribution produces few, making low-evidence assertions structurally visible. ▶ 26:15

Notable Quotes

The best thing about open source intelligence data is free. Dongdong Sun · ▶ 0:27

LM has been very good at doing stuff, but then doing stuff reliable is you can’t just like one shot this thing from the get-go. Dongdong Sun · ▶ 7:44

The most important thing about this all this AI application is how you do your evaluation and this is the only indicator of quality of your data, especially for threat intelligence. Dongdong Sun · ▶ 10:00

more than 50% of time I spend on just building evaluation Dongdong Sun · ▶ 20:39

thinking model is think thinks to thinks too much, mostly rely on model knowledge Dongdong Sun · ▶ 24:27

Key Takeaways

  • Build a knowledge graph, not an indicator feed — context lives in entity relationships, not raw IOCs.
  • Split LLM extraction into skeleton routing, per-entity extraction, and constrained relationship triplets to hit 90%+ accuracy.
  • Invest more than half your pipeline effort in evaluation; ground every LLM answer to a specific graph node, not model memory.