Source-linked AI summary
Adversary Brains: Hypothesis-Based Logical Signatures for Threat Actor Detection with LLMs
Gadi Evron
TL;DR
Threat-actor knowledge often remains in prose or hand-built playbooks that must be reapplied. The paper proposes continuously tested, evolving logical signatures, with reported cases showing both successful forecasts and a forecast that missed a change in platform techniques.
Problem
Threat-actor knowledge can remain in prose reports or hand-built playbooks that a person must reread and reapply.
Source: §I · p. 2Method
The design uses language models to make claims about actor behavior into live hypotheses tested against defender telemetry, with match judgments updating their standing.
Source: §I · p. 2Results
Two Azure-linked behaviors forecast as stable were replaced by VMware techniques, while later reports partly supported forecasts for rotating links.
Source: §III · p. 6Takeaways & Limitations
The proposed workflow tests whether an actor’s recurring behaviors are rare enough to warrant a brain before building the smallest useful version.
Source: §VI · pp. 7–8Cross-brain p-values are not established as comparable across brains that use different matching methods.
Source: §III · p. 5
Abstract
from arXiv · showhide
An adversary brain is an LLM-based model of a threat actor's behavior, held as an evolving logical signature: a hypothesis with enough structure that data can test it continuously, without a person re-interpreting it each time. Rather than any single observation, such as an IoC (Indicator of Compromise), it is the arrangement that becomes a detection, or intelligence, mechanism. Where YARA matches a file and Sigma matches a log line, an adversary brain matches the activity pattern of a campaign or threat actor. This is based on an intelligence analysis technique called Analysis of Competing Hypotheses (ACH), which the design lifts from the limitation of a few hypotheses at a time, to thousands, and then also operationalizes it for continuous detection purposes. Language models make the concept, and scale, practical: they turn prose reports into brains, judge matches, and drive the loop that keeps brains current. A partial pattern in a brain can also match a new value, such as a fresh C2 (command and control) domain name, assisting with the discovery of new indicators, and turning unknown unknowns into known unknowns, and potentially into knowns. The author would like to thank Ryan Moon for the collaboration, and Sounil Yu, Chris Inglis, Thomas Roccia, Marius Benthin, Israel Grimberg, Michal Kamensky, Justin Borland, Brandon Levene, John Hultquist, and John Bambenek for their feedback and assistance.
I. INTRODUCTION
An adversary brain turns a threat actor’s behavior into a structured logical signature that incoming data can test. The design scales competing hypotheses into continuous detection and uses matches to guide analyst judgment and evidence collection.
I. INTRODUCTION
- A brain matches arrangements of activity across campaigns, time, systems, and artifacts rather than treating any single observation as the detection.The design contrasts this with YARA matching a file and Sigma matching a log line.Source: §I · p. 1
- Confirmed and dismissed matches raise or lower a brain’s standing and can retire the underlying claim as telemetry arrives.This makes the claim itself—not merely a rule that cites it—run against defender telemetry.Source: §I · p. 2
- Brains aim to detect TTPs as arrangements of observations, hold thousands of hypotheses, and turn unknown activity into known unknowns and potentially knowns [2].The design also names uses including identifying actors worth representing, prioritizing durable links, and surfacing missing evidence.Source: §I · p. 2
- Each brain represents a machine-checkable hypothesis, allowing thousands of hypotheses to be scored against the same incoming data continuously.ACH traditionally scores explanations against shared evidence by hand; the design extends that approach beyond the cited limit of more than seven manageable hypotheses.Source: §I · p. 2
- The approach assumes actor activity has structures stable and rare enough to represent, but some actors shift their methods and simpler stacks may match or outperform it.The proposed test is whether the structure is worth representing before investing in a brain.Source: §I · p. 2
- The text specifies a design and reference implementation, but does not measure detection rates, false positives, or robustness against indicator rotation on real telemetry.Thousands-of-brains matching cost is also not analyzed.Source: §I · pp. 2–3
II. WHAT A BRAIN IS
A brain is a structured hypothesis about what an arrangement of observations would mean, represented through entities and links that data can test. Its scale, representation, and match rules can vary while preserving that core purpose.
II. WHAT A BRAIN IS
- A brain is a hypothesis about what arranged observations would mean, not merely a record of what happened.Its structure makes the claim machine-testable.Source: §II · p. 3
- Entities are observables and links are typed relations; rarity gives a matching piece more discriminative weight.Weights derive from each defender’s background traffic, so they remain unchanged when brains are added, split, or merged.Source: §II · p. 3
- Required links form the core for firing, while supporting links contribute additional evidence; observability and volatility describe visibility and expected change.Volatility is a forecast that may be wrong; durable behavioral links can persist while faster-changing lower-level pieces churn.Source: §II · p. 3
- Brains can represent ordered chains, whole sets, or learned centroids and embeddings, depending on the content and how it is matched.For example, a chain can encode ordered SUNBURST steps, while a list can represent Akira’s targeted file types.Source: §II · p. 3
- Unlike a technique label, a brain asserts a specific weighted arrangement; its concrete observables sit mostly at the procedure level, though some brains contain only state.Tactics can be carried as notes or custom entities, but matching them requires telemetry that already labels events with tactics.Source: §II · pp. 3–4
- A brain can scale from a link to a technique set, attack chain, campaign pattern, or threat actor, with higher levels composed from lower-level patterns.Where campaigns share no common core, an actor may not reduce to a single brain.Source: §II · pp. 3–4
III. HOW IT WORKS
The system scores incoming observations against many revisable brains, using matches both to detect known patterns and to form new hypotheses. A continuous loop updates brain standing and connects the hypotheses to detection and collection, while some judgments remain outside the loop.
III. HOW IT WORKS
- One pass scores each incoming observation against thousands of competing brains, corroborating fits, detecting completed patterns, screening contradictions, and generating hypotheses from unmatched activity.Absence alone does not count as contradiction.Source: §III · pp. 4–5
- Discover builds brains bottom-up from unmatched data, while Extract creates them top-down from reports, curated intelligence, or analyst input.Discover’s proposals may include benign patterns that still need pruning.Source: §III · pp. 4, 6
- The same pass can score brains at every scale, matching an observation wherever it fits and allowing unmatched scales to remain open for later discovery.Discover can cluster observations that fit no existing brain rather than force them into the nearest one.Source: §III · pp. 4–5
- The loop continually updates each brain’s standing from corroborating and contradicting evidence, and can split, merge, fade, or retire brains as patterns change.A mere absence does not lower standing because it may reflect missing data.Source: §III · p. 5
- The loop seeks disconfirmation as well as confirmation, but it does not decide whether changing matches reflect actor drift, a split pattern, or fused actors.Attribution and drift confirmation are judgments it does not make on its own.Source: §III · pp. 4–5
- Cross-brain p-value comparability across different match methods remains untreated, and model confidence is uncalibrated, so it is used only for ranking.The design also constrains language-model verdicts to evidence from the deterministic match block.Source: §III · pp. 5–6
- In a synthetic test, a behavioral brain fired on all 99 runs with rotated indicators; later reports also showed two Azure-tied stable-link forecasts missed when techniques shifted to VMware.The text does not measure detection rates, false-positive rates, or rotation robustness on real telemetry; resistance was tested only on synthetic data and one emulated case.Source: §III · p. 6
- A brain’s fidelity sets its operational use: high-fidelity brains can alert, while lower-fidelity brains can rank triage or seed hunts.The system’s operations connect matching and discovery to coverage mapping, compilation, and sharing.Source: §III · pp. 4, 6
IV. WHAT YOU DO WITH A BRAIN, AND WHAT IT RESOLVES
The brain is used across operations that turn intelligence and observations into revisable, testable detection hypotheses. These operations address discovery, matching, coverage, implementation in a detection stack, and peer sharing.
IV. WHAT YOU DO WITH A BRAIN, AND WHAT IT RESOLVES
- Discover proposes brains bottom-up from unmatched observations, while Extract builds them top-down from reports, curated intelligence, or analyst input.Extracted brains are born unconfirmed and can be tested against the defender’s own data.Source: §IV · p. 6
- Match scores an observation against brains so the arrangement across artifacts, rather than any one artifact or IoC, can be detected.Run in reverse, Match asks what evidence would complete a brain.Source: §IV · p. 6
- Coverage-map sorts brain entities and links into covered, visible but uncovered, or invisible, and suspends a brain when a required link cannot be observed.This distinguishes a real no-match from evidence that sensors could not see.Source: §IV · pp. 6–7
- Compile converts a brain into a cheaper form a detection stack can run, such as a Sigma or YARA rule, SIEM query, watchlist, or hunt playbook.Coverage-map should run first because compilation writes to the stack.Source: §IV · p. 7
- Share distributes a brain’s structure for peers to verify against their own data, without requiring the sender’s attribution to transfer.Environment-specific fields are stripped on publication and recomputed by each receiver.Source: §IV · p. 7
V. THE SCHEMA
The schema represents a brain as a small, standards-based knowledge graph whose hypothesis can be tested against data. It separates shared definitions from local trust and blocks automated detections from re-entering as evidence, while retaining a human-relay risk.
Schema objects
- Each link records its relation, role, observability, volatility, locally computed weight, and provenance; each brain records identity, status, scale, links, match settings, lineage, and local fidelity.Fidelity is the brain’s confirmed-match rate and remains local because it records the receiver’s analysts’ verdicts.Source: §V · p. 7
- A brain is a typed property graph: entities are nodes, links are edges, and the brain file serializes that graph using STIX vocabulary and a closed set of link relations and attributes.The schema adds the hypothesis layer that event and entity standards do not provide; it defines three objects and no separate event taxonomy.Source: §V · p. 7
Evidence flow
- Compiled detections carry their brain’s id, and ingest drops observations bearing that id, preventing the automated path from feeding a brain’s own conclusions back as evidence.The human relay remains a residual risk: an analyst may write an alert into a report that is later ingested.Source: §V · p. 7, Figure 7 · p. 7
Trust and attribution
- Attribution is omitted from matching, while provenance tracks trust per link and fidelity tracks it per brain.A brain can gather links from reports, telemetry, and peers over time rather than inheriting trust from one source.Source: §V · p. 7
Sharing
- Brains are shared as repository definitions, not live state: receivers recompute weights from local background rates, and published internal entities are sanitized to avoid exposing the victim.The normative specification defines the fields, allowed values, sharing rules, file conventions, repository layout, and a worked example.Source: §V · p. 7
VI. WHETHER TO BUILD, AND HOW
The section proposes testing whether an actor leaves a rare, durable, observable structure before investing in an actor-scale brain. If that wager is supported, build a minimal behavioral detector first and keep attribution optional and evidence flow one-way.
Test the wager
- Before building, test whether an actor’s structure is rare, durable, and observable by checking understood past intrusions against existing background data, without new collection or attribution.The check asks how often characteristic pieces recur across related incidents and how rare they are in ordinary traffic.Source: §VI · p. 7
- If only recurring links are commodity, a simpler detection stack may suffice; if rare and recurring links exist, build the smallest useful version.The wager test is intended to reach that decision cheaply, before over-building.Source: §VI · pp. 7–8
Build the minimum
- Start with the schema and one behavioral detection delivered as a recommendation, where analysts confirm or dismiss each fire to provide a clean feedback loop.Sharing, discovery, and attribution come afterward.Source: §VI · p. 8
Rules throughout
- Keep status visible, allow evidence to flow only upward, and decouple naming from matching; attribution stays optional and last because adversaries can fake traces used to name them.A brain claims a coherent pattern rather than a culprit and remains a revisable hypothesis.Source: §VI · p. 8
APPENDIX 1: BRAIN SCHEMA, VERSION 0.1
Version 0.1 specifies a validated YAML brain document whose entities and links form a matchable hypothesis, with local fields separated from publishable data. Its flat fire rule and incomplete sequence support impose boundaries on what a brain can represent and match.
Document and attribution
- A brain is authored as one UTF-8 YAML file, validated by a published JSON Schema; attribution is excluded from matchable fields to avoid using a conclusion to find its own supporting evidence.The schema also defines JSON as the interchange format and rejects unlisted fields.Source: APPENDIX 1: BRAIN SCHEMA, VERSION 0.1 · p. 8
Entity patterns
- Entity patterns use a small schema-specific syntax, omit regular expressions, and cannot bind a value shared across separate observations; sequence matching supplies binding but version 0.1 does not define its order fields.The flat rule does not bind, so an entity appearing in two links may match different values.Source: APPENDIX 1: BRAIN SCHEMA, VERSION 0.1 · p. 8
Local fields and fire semantics
- Local weight, observability, and fidelity are stripped before publishing and recomputed by each receiver; a shared file containing them must be rejected.These fields reflect local environment facts, and sightings could expose the victim.Source: APPENDIX 1: BRAIN SCHEMA, VERSION 0.1 · p. 8
- A brain fires when all required links match and the weight-weighted share of matched supporting links reaches its threshold; an invisible required link suspends it rather than failing it.Invisible supporting links are excluded from the share; if none remain visible, the brain fires on its required links alone.Source: APPENDIX 1: BRAIN SCHEMA, VERSION 0.1 · p. 8
Fire-rule limits
- The flat fire rule cannot express alternatives across sub-cores, so campaigns with no common required core cannot fire as one actor-scale brain.The text leaves a disjunctive fire form or separate campaign brains grouped under an actor label as unbuilt paths.Source: APPENDIX 1: BRAIN SCHEMA, VERSION 0.1 · p. 8
Sequence and co-occurrence limits
- Version 0.1 does not define sequence-order fields or how centroid and embedding brains fire; the reference implementation instead uses one host within a fixed 24-hour window for activity links.State links are matched across all hosts and times.Source: APPENDIX 1: BRAIN SCHEMA, VERSION 0.1 · p. 8
Inputs and lifecycle
- The schema receives IoCs, reports, network and endpoint events, and control or SOC alerts; repository status advances through review or permitted confirmations, while receivers earn local fidelity.For interchange beyond git, entities and links map to STIX objects and the brain maps to a bundle.Source: APPENDIX 1: BRAIN SCHEMA, VERSION 0.1 · pp. 9–10
APPENDIX 2: BUILDING A BRAIN FROM A REPORT
The worked cases show that a brain is worth building when a report contains a rare, durable, observable piece or arrangement; this combination is uncommon. The examples range from durable structural or behavioral links to cases where only a scaffold—or no actor-scale brain—is justified.
APT1
- APT1’s command-retrieval behavior is a required, stable link, while its more than 3,000 infrastructure indicators were largely abandoned within about three months.The behavior persisted across more than six years of samples, whereas the indicators and links through them were treated as perishable.Source: APPENDIX 2: BUILDING A BRAIN FROM A… · p. 10
SUNBURST
- SUNBURST’s signed Orion monitoring process making an outbound call is a distinctive, observable, required, stable link; its seized C2 domain is ephemeral.The structural process behavior is not a tool choice the operator can swap without giving up the operation.Source: APPENDIX 2: BUILDING A BRAIN FROM A… · p. 10
Scattered Spider
- Scattered Spider’s help-desk phone-call step is off-telemetry, so its brain suspends for lack of visibility; the observable identity-event sequence works only where those events are logged.The sequence is a scaffold because no individual step is rare; the text points to improved help-desk verification and telemetry.Source: APPENDIX 2: BUILDING A BRAIN FROM A… · p. 10
Volt Typhoon
- Volt Typhoon yields two observable, stable native actions—PortProxy relaying and ntdsutil copying the directory database—around which a small behavioral brain can form.Its router-relay infrastructure is ephemeral, while the two actions are close to the operation rather than swappable tools.Source: APPENDIX 2: BUILDING A BRAIN FROM A… · p. 13
Ransomware floor
- Ransomware-floor indicators do not discriminate, and an actor brain built from either report would match unrelated intrusions; the text recommends no actor-scale brain where a single rule does the same work.Akira’s ESXi encryptor writing its own file extension remains a narrower technique-set brain worth keeping.Source: APPENDIX 2: BUILDING A BRAIN FROM A… · p. 13
Across the cases
- Across five cases, a brain is worth building when a piece is rare, durable, and observable; SUNBURST and APT1 nearly have a single link, Volt Typhoon has two native actions, and Scattered Spider has an arrangement only where identity events are logged.The observed ransomware-floor case has no such actor-scale structure.Source: APPENDIX 2: BUILDING A BRAIN FROM A… · pp. 13–14
What the cases show
- The cases illustrate that specificity sets the fidelity a brain can earn, and fidelity determines whether it alerts or only ranks.Weight reflects rarity in ordinary traffic, volatility tracks change, and observability determines whether a receiver can see a link.Source: APPENDIX 2: BUILDING A BRAIN FROM A… · p. 14
APPENDIX 3: THE REFERENCE IMPLEMENTATION
The reference engine tests brain-matching and update rules, mainly on synthetic data; its results illustrate mechanisms rather than establish detection rates. The appendix also reports one emulated case and a study of later public reports.
Implementation and scope
- The engine ships six validated brain files and tests its rules mainly on synthetic data, which tests mechanisms but gives no detection rate.Seven of 71 entities remained prose that Compile could not turn into a match rule; several loop moves are unspecified, and the engine does not use stored representation, match, prior, or volatility to match.Source: APPENDIX 3: THE REFERENCE IMPLEMENTATION · pp. 14–15
Order
- On 6,000 synthetic host-days, three common identity steps required in order for one user fired on 5, versus 6,000 fires for a flat rule over two common pieces.The ordered result is a lower bound because the matcher is greedy; the same steps out of order or spread across three users gave only a partial match.Source: APPENDIX 3: THE REFERENCE IMPLEMENTATION · p. 14
One link and several
- The one-link SUNBURST brain fired on 594 of 6,000 host-days, while the multi-link, APT1, and Akira brains fired on none in the specified background.The SUNBURST destination test uses a substring check, and a C2 domain containing “solarwinds” evades it.Source: APPENDIX 3: THE REFERENCE IMPLEMENTATION · p. 14
Separation
- Under an independent-piece null, the two-required-link Volt Typhoon brain separated from chance, while the three-required-link Scattered Spider brain narrowly did not.The test is optimistic because real pieces co-occur; in a separate fire-rate run, correlated-background SUNBURST fires were 582 of 6,000 versus 561 with independent pieces, and multi-link brains fired on none.Source: APPENDIX 3: THE REFERENCE IMPLEMENTATION · p. 14
Rotation and loss
- Across 100 runs, the behavioral brain fired every time, while its indicator-based twin fired only on the first run; invisible required links suspended the brain.Removing an event for a supporting link changed the outcome from fired to partial.Source: APPENDIX 3: THE REFERENCE IMPLEMENTATION · p. 14
The loop
- A brain confirmed 30 of 30 times reached fidelity 1.0, while one never confirmed in 566 fires was retired.Discover found the planted pattern in 30 of 30 runs and proposed about 25 benign patterns per run, which disproof would need to prune.Source: APPENDIX 3: THE REFERENCE IMPLEMENTATION · p. 14
One emulated case
- On one public emulated lsass-memory-dump case, the brain and a Sigma rule each caught the attack and fired on none of seven other techniques.After the command line changed, the brain still fired while a command-line Sigma rule missed; a different dump tool, dbghelp instead of dbgcore, defeated the brain, so this is not a rate.Source: APPENDIX 3: THE REFERENCE IMPLEMENTATION · p. 14
Durability in public reporting
- Of 23 judged verdicts from later reports, 9 showed a required link persisting and 4 showed it replaced by a successor; reports are a biased sample.The remaining 10 did not count toward durability because they reflected analyst learning, vendor reframing, or a fading link; a link that does not recur may still be durable.Source: APPENDIX 3: THE REFERENCE IMPLEMENTATION · p. 15