Automating Threat Intelligence: Moving Beyond Manual CTI Analysis

TLDR: Threat intelligence reports are often trapped in unstructured text, making them difficult to scale for automated defense. This research introduces an agentic system that uses LLMs and custom tools to synthesize these reports into structured, actionable battlecards. By moving beyond simple RAG, this approach allows security teams to proactively identify new infrastructure and TTPs associated with known threat actors.

Security researchers and incident responders spend an absurd amount of time manually parsing threat intelligence reports. We read PDFs, scrape blog posts, and copy-paste indicators into spreadsheets or threat intelligence platforms. It is a slow, error-prone process that leaves us constantly playing catch-up. By the time a report is published, the threat actor has often already rotated their infrastructure. The real-world risk is clear: if your detection engineering pipeline relies on manual ingestion, you are effectively blind to the rapid infrastructure shifts used by modern adversaries.

The Problem with Unstructured Intelligence

Public threat intelligence reports are gold mines of information, but they are written for humans, not machines. They contain natural language descriptions of TTPs, embedded images of attack chains, and conflicting data points across different sources. Attempting to automate this with basic keyword extraction or simple Retrieval-Augmented Generation (RAG) often fails because it lacks the context required to synthesize complex, multi-stage attack patterns.

The research presented at DEF CON 2025 demonstrates a shift toward agentic systems. Instead of just retrieving documents, an agentic system uses an LLM in a loop, calling specific tools to verify, extract, and structure data. This is not just about summarizing text; it is about building a machine-readable "battlecard" for a specific threat actor.

Building the Agentic Pipeline

The core of this system relies on a four-step pipeline: collecting reports, grouping them by threat actor, generating structured battlecards, and discovering new IOCs. The system uses a "React" (Reasoning and Acting) pattern, where the LLM decides which tool to invoke based on the current state of the analysis.

The agent uses three primary tools:

1. Report Collector: Fetches and stores raw CTI data.
2. Search Tool: Injects external context to resolve ambiguities in the reports.
3. Extractor: Parses the raw data into structured JSON objects.

The following Python snippet illustrates how the agent handles the synthesis of multiple reports into a single, unified battlecard:

def get_battlecards(threat_actor, input_list):
    # Logic to merge multiple battlecards into one
    # Removes duplicate IOCs and consolidates campaign timelines
    # Returns a single, structured JSON object
    return merged_battlecard

By using BERT or Gemini embeddings, the system can cluster reports based on semantic similarity rather than just shared keywords. This allows the agent to identify that two different reports, written months apart, are actually describing the same campaign or infrastructure reuse.

Real-World Application for Pentesters

For those of us on the offensive side, this system is a force multiplier. During a red team engagement, you need to know how a specific actor operates to emulate them effectively. Instead of manually digging through years of MITRE ATT&CK mappings, you can feed the agent a collection of reports on a target actor and instantly generate a battlecard that highlights their preferred TTPs, such as T1588 (Obtain Capabilities) or T1584 (Compromise Infrastructure).

The most impressive part of this research is the "graph expansion" technique. Once the agent has a battlecard, it builds a network graph of the known IOCs. It then looks for associations—like shared SSL certificates or common registration patterns—to discover new, unlisted infrastructure. This is exactly how you find the "next" C2 server before the threat actor even starts using it for a live attack.

Defensive Implications

Defenders can use this to automate the "so what?" phase of threat intelligence. When a new report drops, the agent can automatically update the organization's blocklists and detection rules. By reducing the human-in-the-loop requirement, the time between report publication and defensive action drops from days to minutes. However, the researchers correctly note that human oversight remains critical. LLMs can hallucinate, and blindly trusting an automated agent to push block rules to production is a recipe for a self-inflicted denial-of-service attack.

What to Do Next

Stop treating your threat intelligence as a static library of PDFs. If you are a developer or a researcher, look into how you can integrate agentic workflows into your existing security stack. The goal is to move from "reading about threats" to "programmatically responding to threats." Start by identifying one specific threat actor you track, collect their recent reports, and see if you can build a simple agent to extract their TTPs into a structured format. The tools are available, the research is proven, and the manual approach is officially obsolete. If you aren't automating your intelligence ingestion, you are already behind.