Threat Actor Profiling with LLMs: Building Persistent Adversary Models from Fragmentary Intelligence

Threat actor profiling has always been a memory problem. Analysts accumulate fragments: a TTPs assessment from six months ago, a signals report tied to an infrastructure cluster, forum posts scraped from a Tor-adjacent marketplace, an indictment that names three shell companies. Stitching those pieces into a coherent, living adversary model requires hours of synthesis work that most shops simply don't have. LLMs don't solve the memory problem automatically, but they change what's possible when you design the pipeline correctly.

Photo by AI25.Studio Studio on Pexels.

Why Static Profiles Fail

Most organizations maintain threat actor profiles in wikis, SharePoint pages, or TIP databases. These artifacts are snapshots. The moment the adversary changes infrastructure, shifts targeting priorities, or onboards a new affiliate, the profile is wrong. Analysts know this, which is why experienced practitioners treat formal profiles with quiet skepticism. They'll reference a profile, then mentally layer in everything they've absorbed since it was written.

The real issue isn't that profiles decay. Everything decays. The problem is that there's no systematic update mechanism tied to incoming reporting, so drift accumulates silently. A profile can be eighteen months stale and still carry the same visual weight in a briefing as a freshly written assessment.

The Architecture of a Persistent Adversary Model

Building LLM-augmented adversary models requires thinking in layers. Each layer handles a different fidelity of information and a different update cadence.

graph TD
    A[/Raw Intelligence Ingest/] --> B(Entity Extraction and Deduplication)
    B --> C{Conflict with Existing Profile?}
    C -->|Yes| D[Human Review Queue]
    C -->|No| E[Profile Attribute Update]
    D --> E
    E --> F[Vector Store: Adversary Embedding]
    F --> G((Analyst Query Interface))

Raw reporting flows in from OSINT feeds, finished intelligence, malware sandbox results, and structured TIP data. An extraction layer pulls named entities, TTPs mapped to MITRE ATT&CK, infrastructure indicators, and temporal markers. Before anything touches the adversary profile, a conflict-detection step compares new attributes against existing ones. Attribution shifts, for instance a group previously assessed as Chinese state-nexus now showing Iranian tooling signatures, should not update automatically. They go to a human.

The vector store holds adversary embeddings generated from the full profile corpus, not just the summary field. When an analyst queries a profile, the retrieval isn't keyword-based. Semantic proximity surfaces related activity clusters the analyst might not have thought to request.

What LLMs Actually Do in This Pipeline

Three tasks where LLMs earn their compute cost in this workflow:

Narrative synthesis. Given twenty-three disparate reporting fragments about a ransomware affiliate cluster, an LLM can produce a coherent operational summary with source citations. A skilled analyst doing this manually takes two to four hours. The LLM takes seconds, and the output is good enough for a first draft that the analyst reviews and corrects. The analyst is now editing rather than drafting, which is a fundamentally different cognitive load.

Hypothesis surfacing. Feed the adversary's historical behavior patterns into a prompt structured around a specific analytic question: "Given this group's retooling timeline after prior exposure, what infrastructure changes would you expect in the next sixty days?" You're not treating the output as ground truth. You're using it to generate a set of testable hypotheses your collection team can actually go look for.

Profile delta reporting. Each time a significant new attribute gets added, run a comparison prompt against the prior profile state. The output is a structured changelog: what changed, what was confirmed by new reporting, and what gaps remain unresolved. This beats hunting through version history in a wiki.

The Hallucination Tax

Anyone deploying LLMs against classified or sensitive threat intelligence needs to treat hallucination as a tax, not an edge case. The model will confabulate. It will blend two similar threat actors, invent an infrastructure connection that sounds plausible, or assign a TTP based on superficial textual similarity rather than evidence.

The mitigation isn't heroic prompt engineering. Ground every output in retrieved source documents using a RAG setup with strict citation requirements. If a claim in the synthesized profile can't be traced to a specific source passage, flag it for review before it enters the persistent store. Polluted profiles are worse than no profiles, because analysts trust them.

Cadence and Ownership

Persistent adversary models need an owner. Not a team. A person. Someone who reviews the automated update queue, resolves conflicts, and periodically runs a full-profile revalidation against current reporting. Without that ownership, the system produces sophisticated-looking garbage over time.

Update cadence should scale with adversary activity tempo. A nation-state APT with a documented operational cycle probably warrants weekly review. A low-activity criminal group can run on monthly. Build that logic into the pipeline so analysts aren't reviewing quiet profiles on the same schedule as active ones.

The goal isn't to automate the analyst out of threat actor profiling. Judgment about adversary intent still requires a human who understands geopolitical context, organizational behavior, and the weight of evidence. What automation handles is the retrieval, synthesis, and maintenance overhead that currently prevents analysts from exercising that judgment at all.