Paper deep dive
An Automated Framework for Extracting Reachable Attack Chains from Cyber Threat Intelligence Reports
Wenbo Hou, Ning Hu, Xueping Wang, Jiahao Gu, Wenjian Luo
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 89%
Last extracted: 7/23/2026, 2:34:50 AM
Summary
This paper proposes an automated framework to extract reachable attack chains from unstructured Cyber Threat Intelligence (CTI) reports. The framework models each attack step as an 'attack unit' consisting of preconditions, attack behavior, and postconditions. Using a multi-stage pipeline assisted by Large Language Models (LLMs), it extracts behavior skeletons, recovers and normalizes conditions into predefined predicates, and repairs broken dependencies. The resulting units are compiled into Datalog-style rules for reachability reasoning. The method outperforms existing CTI extraction systems in coverage and consistency, successfully enabling Datalog inference to reach attack goals in 19 out of 20 tested reports.
Entities (10)
Relation Signals (10)
Attack Unit → consistsof → Preconditions
confidence 95% · modeling each attack step as an attack unit of preconditions, an attack behavior, and postconditions.
Attack Unit → consistsof → Postconditions
confidence 95% · modeling each attack step as an attack unit of preconditions, an attack behavior, and postconditions.
Attack Unit → consistsof → Attack Behavior
confidence 95% · modeling each attack step as an attack unit of preconditions, an attack behavior, and postconditions.
Automated Framework → models → Attack Unit
confidence 95% · This paper proposes an automated framework that extracts reachable attack chains by modeling each attack step as an attack unit...
Automated Framework → uses → LLMs
confidence 95% · A multi-stage pipeline assisted by large language models (LLMs) extracts attack behavior skeletons...
Attack Unit → compiledinto → Datalog
confidence 90% · the resulting units are compiled into Datalog-style rules for attack-goal reachability reasoning.
Behavior Vocabulary → informedby → MITRE ATT&CK
confidence 85% · The behavior vocabulary (informed by MITRE ATT&CK tactics...)
Predicate Vocabulary → normalizes → Preconditions
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Cyber Threat Intelligence (CTI) reports richly describe real-world attack processes, but their unstructured narratives cannot be directly used for automated attack-path reasoning. Existing CTI extraction methods focus on indicators, entities, or TTP labels without modeling the execution conditions and resulting states of each attack step, so the extracted knowledge supports neither state matching nor reachability analysis across multi-stage attack chains. This paper proposes an automated framework that extracts reachable attack chains by modeling each attack step as an attack unit of preconditions, an attack behavior, and postconditions. A multi-stage pipeline assisted by large language models (LLMs) extracts attack behavior skeletons, recovers their preconditions and postconditions, normalizes them into predefined predicates, and repairs broken dependencies; the resulting units are compiled into Datalog-style rules for attack-goal reachability reasoning. On a dataset of 20 CTI reports containing 334 human-validated annotated steps, our framework achieves higher annotated-step coverage than representative CTI extraction systems in recovering attack behaviors. Moreover, by explicitly generating preconditions and postconditions, it produces attack units that are more complete and consistent than those generated by end-to-end LLM baselines. On the extracted chains, Datalog inference reaches the specified attack goal in 19 of 20 reports, while backward search yields 34 attack paths under the generated rules. The source code and experimental artifacts are available in an anonymized repository. .
Tags
Links
- Source: https://arxiv.org/abs/2607.19742v1
- Canonical: https://arxiv.org/abs/2607.19742v1
Trouble viewing inline? Open PDF directly →
Full Text
77,894 characters extracted from source content.
Expand or collapse full text
An Automated Framework for Extracting Reachable Attack Chains from Cyber Threat Intelligence Reports Wenbo Hou1,2, Ning Hu2,*, Xueping Wang1,3, Jiahao Gu1, and Wenjian Luo1,* Abstract Cyber Threat Intelligence (CTI) reports richly describe real-world attack processes, but their unstructured narratives cannot be directly used for automated attack-path reasoning. Existing CTI extraction methods focus on indicators, entities, or TTP labels without modeling the execution conditions and resulting states of each attack step, so the extracted knowledge supports neither state matching nor reachability analysis across multi-stage attack chains. This paper proposes an automated framework that extracts reachable attack chains by modeling each attack step as an attack unit of preconditions, an attack behavior, and postconditions. A multi-stage pipeline assisted by large language models (LLMs) extracts attack behavior skeletons, recovers their preconditions and postconditions, normalizes them into predefined predicates, and repairs broken dependencies; the resulting units are compiled into Datalog-style rules for attack-goal reachability reasoning. On a dataset of 20 CTI reports containing 334 human-validated annotated steps, our framework achieves higher annotated-step coverage than representative CTI extraction systems in recovering attack behaviors. Moreover, by explicitly generating preconditions and postconditions, it produces attack units that are more complete and consistent than those generated by end-to-end LLM baselines. On the extracted chains, Datalog inference reaches the specified attack goal in 19 of 20 reports, while backward search yields 34 attack paths under the generated rules. The source code and experimental artifacts are available in an anonymized repository111https://anonymous.4open.science/r/artifact064b. I Introduction CTI reports describe real-world attack incidents in detail, covering the full process from initial compromise to final objectives [1]. Such reports provide rich knowledge about threat actors, malware behaviors, exploited vulnerabilities, attack tools, and network infrastructure [13, 4]. A central use of this knowledge is downstream attack-path reasoning: given a description of a target system, an analyst wants to know whether an attack goal is reachable, which steps lead to it, and which state dependencies support the corresponding attack paths [17, 36]. However, most CTI reports are written in unstructured natural language, where attack actions, contextual evidence, and technical details are mixed across paragraphs [8]. Attack steps are often described implicitly or across multiple sentences, making it difficult to identify their temporal order and causal dependencies [26, 20]. Although human analysts can mentally reconstruct attack chains from these narratives, automated systems still struggle to transform them into a representation over which such reasoning can actually be performed. Notably, formal attack-graph reasoning already provides the machinery for this goal. Logic-based analyzers such as MulVAL [25] model each attack step as a rule whose body is a set of preconditions and whose head is the resulting security state, and derive reachable attack goals by logical inference. The bottleneck is therefore not the reasoning engine but the supply of rules: such preconditions and postconditions have traditionally been hand-written by experts, and no existing CTI extraction method produces them automatically from narrative reports. This rule-supply gap exposes a fundamental limitation of current CTI extraction: existing CTI automation yields descriptive rather than executable knowledge. As illustrated in Figure 1, prior methods extract indicators of compromise (IOCs) that can only be matched against observations [18], assign flat MITRE ATT&CK technique labels without execution conditions [13, 28, 31], or build entity-relation and attack knowledge graphs [17, 29, 9, 6], with recent variants using LLMs for graph construction and completion [10, 7]. Graph-based methods add useful structure, such as behavioral sequences, temporal dependencies, and technique associations [33, 32]. However, they mainly capture the topology among entities and behaviors, rather than the state-transition semantics of each attack step. They do not specify the conditions under which a behavior becomes executable or the security states produced after execution. Therefore, their outputs cannot be directly used for state matching, dependency verification, or attack-goal reachability analysis. Figure 1: Security analysis task and comparison of previous CTI extraction methods with the proposed approach. Previous methods based on IOCs, TTPs, and knowledge graphs suffer from three key limitations: no explicit preconditions/postconditions, no state matching, and no reachability reasoning. The proposed method represents each attack step as an attack unit with an explicit Pre→ → structure, enabling state matching and reasoning about attack-goal reachability. These observations expose two gaps that, together, separate current CTI extraction from reasoning-ready knowledge. Gap 1 (Representation). Dominant CTI representations, including IOCs, tactics, techniques, and procedures (TTPs), entity-relation triples, and attack graphs, do not carry explicit preconditions and postconditions. Without them, an automated reasoner cannot determine whether an attack step is executable under the current system state, nor can it propagate the security states produced by that step to enable subsequent behaviors. The consequence is concrete: extracted knowledge supports neither executability checking, nor dependency verification, nor attack-goal reachability analysis. Closing this gap requires each attack step to be modeled as an executable state transition rather than as a descriptive record, so that it can be converted into the rule form used by logic-based attack-graph engines such as MulVAL [25]. Gap 2 (Extraction). A straightforward approach is to prompt an LLM to generate the complete precondition–behavior–postcondition chain end to end, since LLMs have shown strong performance in CTI extraction, ATT&CK mapping, and knowledge graph construction [2, 5, 34, 12]. However, end-to-end generation is unreliable for several reasons. First, generated conditions are often expressed in open-ended natural language, which makes exact symbolic reasoning difficult. Second, CTI reports rarely describe attack steps as explicit state transitions; the enabling conditions and resulting effects of a behavior are often implicit, scattered across paragraphs, or only clarified by later context. Third, generated steps may drift in granularity, causing intermediate states to be omitted, merged, or fragmented [11]. Finally, end-to-end generation provides no explicit mechanism to check whether each generated step is executable from the initial facts and the states produced by earlier steps. As a result, missing conditions, unsupported intermediate states, and broken dependencies may remain hidden until formal reasoning fails. Closing this gap requires more than prompting a stronger model. The extraction process must be decomposed into controllable stages that stabilize attack-step granularity, recover enabling and resulting states, normalize them into a shared predicate space, and verify that the resulting units form a connected derivation. This paper proposes a multi-stage framework for extracting reachable attack chains from CTI reports. Targeting Gap 1, the framework models attack processes as state-transition chains composed of attack units: Attack Unit=⟨Preconditions,Attack Behavior,Postconditions⟩Attack Unit= ,\;Attack Behavior,\;Postconditions . Each attack unit represents one state-changing attack step. The preconditions describe the environmental states, user actions, or previously derived attack states required before the behavior can occur, while the postconditions describe the new security states produced after execution. Under this representation, an extracted attack step is not merely a textual event, a graph edge, or an ATT&CK label, but an executable transition rule whose postconditions can satisfy the preconditions of subsequent units, enabling state matching, dependency verification, and attack-goal reachability reasoning. Targeting Gap 2, the framework replaces single-pass generation with a controllable pipeline: attack behavior skeleton extraction, precondition and postcondition extraction, predicate normalization, diagnosis-guided repair, and Datalog-based reachability reasoning. A behavior vocabulary constrains the granularity of extracted attack steps, a predicate vocabulary normalizes free-text conditions into unified symbolic states, and diagnosis-guided repair checks and fixes broken dependencies before the units are converted into rules. The main contributions are as follows: • A reasoning-ready representation (Gap 1). We model each attack step as an attack unit whose postconditions can satisfy the preconditions of subsequent units, turning a narrative report into a chain of reachable state transitions rather than descriptive IOC, entity, relation, or TTP records. • A reliable extraction framework (Gap 2). We replace end-to-end generation with a multi-stage LLM-assisted pipeline. A behavior vocabulary stabilizes attack-step granularity, a predicate vocabulary normalizes free-text conditions into a shared symbolic space, and diagnosis-guided repair enforces dependency consistency. • A bridge from CTI text to formal reasoning. Normalized attack units are compiled into Datalog-style rules, which are used for MulVAL-style reachability reasoning and path search. These rules have traditionally required expert hand-writing; our framework produces them automatically from narrative reports. • Evaluation of reasoning support. On 20 CTI reports with 334 human-validated annotated steps, our framework achieves the highest annotated-step coverage among the compared systems. It produces more complete and consistent preconditions and postconditions than end-to-end LLM generation. Datalog inference on the extracted chains reaches the specified attack goal in 19 of 20 reports. The remainder of this paper is organized as follows. Section I reviews related work. Section I defines the attack-unit representation and reasoning semantics. Section IV presents the proposed extraction and reasoning framework. Section V reports the experimental results. Sections VI and VII discuss limitations and conclude the paper. I Related Work I-A CTI Extraction and Graph Construction A large body of work transforms unstructured CTI reports into machine-readable knowledge, but the output remains descriptive rather than executable. Early systems extract IOCs—IPs, domains, hashes, and vulnerability identifiers [39, 15, 37]; for example, iACE distinguishes true indicators from benign technical strings using contextual patterns [18]. Such indicators support detection and sharing but carry no information about dependencies among attack steps. A second line maps CTI text to ATT&CK tactics, techniques, and procedures [19, 27, 16, 38]: TTPDrill uses a threat-action ontology [13], and later methods adopt domain-specific language models for sentence- or report-level TTP classification [28]. A recent SoK shows that existing TTP extraction methods are difficult to compare because they rely on different task settings, TTP ontologies, datasets, and evaluation protocols [4]. More importantly for attack-path reasoning, these methods mainly identify which ATT&CK techniques appear in a report, but do not model the execution conditions, resulting states, or dependencies among attack steps. Annotated resources such as CTI-HAL [8] and AnnoCTR [14] improve fine-grained labeling, but still target entities, concepts, or technique labels rather than executable state dependencies. To capture richer context, recent work builds graph-based representations from CTI reports. Provenance-style attack behavior graphs, such as Extractor [29], map system-level operations to entities such as processes, files, registries, and network sockets, making them suitable for alignment with audit logs. However, they primarily describe observable interactions—such as read, write, execute, and send—rather than the conditions required by each behavior and the security states it produces. ATT&CK-aware knowledge graphs organize attack entities, behavioral relations, and technique-level knowledge. AttacKG [17] aligns extracted attack graphs with ATT&CK technique templates, while AttacKG+ [36] extends this representation with behavior graphs, TTP labels, and phase-level state summaries in a multi-layer knowledge graph. Attack-scenario approaches focus more directly on graph completeness and plausibility. For example, CRUcialG [6] verifies the consistency of attack stages and repairs incomplete scenario-graph structures. LLM-assisted methods further improve graph construction and completion. CTINEXUS [7] uses optimized in-context learning, hierarchical entity alignment, and long-distance relation prediction to construct and complete entity–relation graphs. LLM-TIKG [10] and CTI-Thinker [34] similarly extract entities, relations, and TTPs for graph storage, retrieval, and question answering. Together, these methods represent complementary forms of CTI-derived structure, ranging from behavior graphs and ATT&CK-aware knowledge graphs to repaired scenario graphs and LLM-generated relation graphs. However, these methods mainly represent relationships and ordering among entities and behaviors. Their outputs remain graph nodes, edges, relations, or stage-level summaries rather than executable rules that specify the preconditions and postconditions of each attack step. Consequently, they cannot directly determine whether an attack behavior is executable under the current system state or whether its effects enable a subsequent step. I-B Logical Attack Graph Reasoning Logical attack graphs provide exactly the reasoning machinery our representation targets. MulVAL [25] models vulnerabilities, host configurations, network access, and privileges in Datalog, and derives multi-stage attack paths by inference: a rule body encodes the conditions required for an attack action and the rule head encodes the resulting security state, naturally capturing precondition–postcondition dependencies. Scalable logical attack-graph generation [24] builds on this by encoding causal dependencies among facts, rules, and derived privileges, avoiding enumeration of global system states. However, these systems assume the required facts and rules are already available in structured form—typically from vulnerability scanners, configuration inventories, and expert-defined exploit rules. They solve downstream reachability once rules exist, but not the upstream problem of acquiring those rules from natural-language CTI. Our work is complementary: we extract attack units from CTI reports, normalize their preconditions and postconditions into a predicate vocabulary, and convert them into Datalog-style rules, thereby supplying the rules that logical attack-graph analyzers have traditionally required experts to write by hand. I Preliminaries The objective of this paper is to transform unstructured CTI narratives into reachable attack chains that can be used for reachability reasoning. Instead of only identifying security entities, indicators, or ATT&CK techniques, we focus on the state dependencies among attack behaviors: what conditions must hold before an attack step can occur, and what security states are produced after it is executed. I-A Task Definition Given a CTI report D, a predicate vocabulary V, and a behavior class vocabulary ℬB, the extraction task aims to produce a set of normalized attack units: =u1,u2,…,un.U=\u_1,u_2,…,u_n\. (1) Each attack unit represents one state-changing behavior described in the report. The predicate vocabulary V defines the symbolic state space used to represent preconditions and postconditions, while the behavior vocabulary ℬB constrains the granularity of extracted behaviors. Given an initial fact set F0F_0 and an attack goal g, the reasoning task determines whether g can be derived from F0F_0 using the rules converted from U. I-B Attack Unit Representation We model each attack step as an attack unit: uj=⟨Prej,Actj,Postj⟩.u_j= Pre_j,Act_j,Post_j . (2) Here, PrejPre_j denotes the conditions required before the behavior can be executed, ActjAct_j denotes the attack behavior described in the report, and PostjPost_j denotes the security states produced after execution. To make attack units reachable, all preconditions and postconditions are normalized into predicate instances from V: Prej⊆,Postj⊆.Pre_j , _j . This representation allows the postconditions of one attack unit to satisfy the preconditions of another, thereby turning a narrative attack description into a chain of state transitions. The behavior vocabulary ℬB does not participate in logical inference; it is used during extraction to stabilize the semantic boundary of ActjAct_j and reduce over-compression or over-fragmentation of attack steps. I-C Rule and Reachability Semantics Each normalized attack unit uj=⟨j,j,j⟩u_j= _j,Act_j,Post_j defines an executable state transition: when all states in jPre_j hold, the behavior jAct_j can be executed and produces the states in jPost_j. For Datalog-style reasoning, this transition is compiled into rules. Given j=p1,p2,…,pmPre_j=\p_1,p_2,…,p_m\ and j=q1,q2,…,qsPost_j=\q_1,q_2,…,q_s\, where m and s denote the numbers of preconditions and postconditions, respectively, we generate one rule for each postcondition: rj,l:ql←p1,p2,…,pm,l=1,…,s.r_j,l: q_l← p_1,p_2,…,p_m, l=1,…,s. (3) The rule body represents the states required for the corresponding attack behavior to be executable, and the rule head represents one security state produced after execution. Let ℛR be the set of generated rules. Starting from the initial fact set F0F_0, reachability reasoning repeatedly applies rules whose bodies are satisfied and adds their heads as new facts until the goal g is reached. This rule formulation also provides a diagnosis signal. A precondition p∈jp _j is unsupported if it is neither an initial fact nor produced by any preceding attack unit: p∉F0andp∉⋃k<jPostk.p∉ F_0 p∉ _k<jPost_k. (4) Unsupported preconditions indicate potential defects such as missing initial facts, missing intermediate states, misplaced pre/postconditions, or inconsistent predicate normalization. IV Framework This section presents the proposed framework for extracting reachable attack chains from CTI reports. The framework transforms unstructured threat narratives into normalized attack units and further converts them into Datalog-style rules for reachability reasoning. IV-A Overview As shown in Figure 2, the framework operates in two phases. The first phase, CTI-to-Attack-Unit Repository Construction, transforms raw CTI reports into reasoning-ready attack knowledge. It extracts attack behavior skeletons, recovers and normalizes preconditions and postconditions, repairs inconsistent dependencies, and converts the standardized attack units into Datalog-style rules. The second phase, Repository-Based Attack Path Reasoning, uses the generated attack-unit repository together with a target system’s initial facts to perform reachability reasoning. It determines whether the specified attack goal is reachable and recovers the supporting attack paths. The framework relies on two vocabularies. The behavior vocabulary (informed by MITRE ATT&CK tactics [31, 30] and common CTI action semantics) constrains the granularity of attack-step extraction, and the predicate vocabulary (following MulVAL-style [25] precondition–postcondition semantics) normalizes free-text conditions into symbolic states. Both vocabularies were constructed before evaluation. We first built an initial version based on standard CTI knowledge, MITRE ATT&CK [30, 31]. We then refined the vocabularies with five CTI reports outside the evaluation dataset. Appendix -A and Appendix -B provides the templates and construction details. (a) CTI-to-Attack-Unit Repository Construction. (b) Repository-Based Attack Path Reasoning. Figure 2: Overview of the proposed CTI-to-Attack-Unit extraction and attack path reasoning framework. IV-B Attack Behavior Skeleton Extraction CTI reports usually contain mixed information, including attack procedures, vulnerability analysis, malware implementation details, indicators of compromise, and mitigation suggestions. Not all such information corresponds to attack-chain steps. The goal of attack behavior skeleton extraction is therefore to identify an ordered sequence of attack behaviors that directly participate in the observed attack process. Given a CTI report DiD_i, the framework extracts an ordered attack behavior skeleton: Ai=⟨Act1i,…,Actnii⟩.A_i= ^i_1,…,Act^i_n_i . (5) Each ActjiAct^i_j describes one core attack behavior, such as opening a malicious document, downloading a payload, executing a script, bypassing a defense mechanism, or establishing a C2 channel. A major challenge in this stage is inconsistent step granularity: overly coarse steps merge multiple state-changing behaviors, making it difficult to assign accurate pre- and postconditions, while overly fine steps fragment the chain into actions that are not meaningful state transitions. We therefore use the behavior vocabulary ℬB as a granularity anchor. It contains 16 coarse-grained classes such as user_action, download, execute, and communication. During skeleton extraction, each behavior is assigned one class to keep the step boundaries consistent. For example, the phrase “the victim opens a malicious PDF and downloads an RTF document” is split into a user_action step and a download step. IV-C Precondition and Postcondition Extraction After obtaining the attack behavior skeleton, the framework extracts the preconditions and postconditions of each attack behavior. For a behavior ActjiAct^i_j, the LLM generates candidate preconditions Preji,candPre^i,cand_j and postconditions Postji,candPost^i,cand_j: preconditions describe the states that must hold before the behavior can occur, and postconditions describe the states produced after the behavior is executed. To improve coverage while limiting context noise, we use a dual-channel strategy. The local channel feeds the LLM the current step, its neighboring steps, and a report fragment retrieved around relevant keywords, focusing on local textual evidence and suppressing irrelevant context. The global channel feeds the complete CTI report, allowing the model to capture long-range dependencies that span multiple paragraphs. For each behavior, the candidates from the two channels are then fused into a single set of preconditions and postconditions. The fusion prioritizes conditions supported by both channels, merges near-duplicates, drops unsupported or overly general items, and reassigns conditions that are attributed to the wrong neighboring step. To avoid noisy expansion, each step retains only a small number of high-confidence preconditions and postconditions. IV-D Predicate Normalization The fused preconditions and postconditions are still natural-language phrases, whereas reachability reasoning requires symbolic states that can be matched exactly across attack units. The normalization stage therefore maps each candidate condition c to one or more predicate instances from the predefined predicate vocabulary V: Normalize(c,)=p1,p2,…,pk,pl∈.Normalize(c,V)=\p_1,p_2,…,p_k\, p_l . (6) where each plp_l is a predicate instance representing one security state described by c. Each predicate instance takes the form category.predicate_name(param1, param2, ...): the category classifies the type of security state, the predicate name specifies the state property or relation, and the parameters bind the entities involved. For example, “the victim host is vulnerable to CVE-2017-11882” is normalized as host.vuln_present(victim_host, CVE-2017-11882), and “the malware establishes an HTTPS C2 channel” as data.c2_channel( victim_host, c2_server, HTTPS). We apply three simple normalization rules. First, each condition must be mapped to predicates in the predicate vocabulary V, rather than to newly invented predicate names. Second, a compound condition is split into multiple predicates when it contains multiple states. Third, the same entity is written with the same canonical name across the chain. These rules help the postconditions of one unit match the preconditions of later units. After normalization, each attack unit becomes a fully symbolic state transition uji=⟨NormPreji,Actji,NormPostji⟩,u^i_j= NormPre^i_j,\,Act^i_j,\,NormPost^i_j , (7) with NormPreji,NormPostji⊆NormPre^i_j,NormPost^i_j , ready for consistency diagnosis and rule generation. Representative predicate templates are listed in Appendix -B. IV-E Diagnosis-Guided Repair After normalization, some attack units may still contain errors that prevent the chain from being used for reachability reasoning. For example, a precondition may not be produced by any earlier step, or a predicate may not match the meaning of the report. We therefore add a diagnosis and repair stage before rule generation. The diagnosis stage uses an LLM to inspect the normalized attack chain and produce structured descriptions of potential inconsistencies and corresponding repair suggestions. The diagnosed problems may involve unsupported dependencies, predicates inconsistent with the report evidence, or incorrectly represented branch relationships. First, it checks whether the chain is connected. Each precondition should either be produced by an earlier attack unit or be included in the initial fact set F0F_0. Second, it checks whether each normalized predicate still matches the report evidence. Third, it checks whether alternative attack branches have been incorrectly merged into one path. Each detected problem is recorded with an issue type and severity. The repair stage strictly follows the diagnosis results. It only fixes the flagged issues and does not add, delete, or rewrite other parts of the chain. We run this process twice: the first round applies the fixes, and the second round checks whether any flagged issues remain. Appendix -D lists all issue types and repair actions. IV-F Datalog Rule Generation After diagnosis and repair, we convert each normalized attack unit into Datalog-style rules. The normalized preconditions become the rule body, and each normalized postcondition becomes a rule head. When an attack unit has multiple postconditions, we generate one rule for each postcondition, following Eq. (3). Each rule is stored as r=⟨rule_id,head,body⟩r= rule\_id,head,body . The complete set of rules forms the attack rule set ℛR used for downstream reachability reasoning. IV-G Attack Path Reasoning Given the rule set ℛR, the initial fact set F0F_0, and the attack goal g, the framework first checks whether g is reachable. Starting from the initial fact set F0F_0, reachability reasoning repeatedly applies satisfied rules and adds their heads as new facts, until either the goal g is derived or no new facts can be derived. For reachable goals, the framework traces the derivation backward from g to the initial facts, producing a set of attack paths Paths(g)Paths(g). Each path is an ordered list of attack units that contribute to the goal. V Evaluation V-A Experimental Setup V-A1 Dataset and Ground Truth We evaluate the proposed framework on 20 publicly available CTI reports [26, 17], containing 334 executable annotated attack steps. The reports cover diverse attack scenarios, ranging from spear phishing, watering-hole attacks, and document exploitation to anti-analysis checks, DLL search-order hijacking, memory exploitation, and C2 communication. System-initial-condition records, such as software versions, vulnerability existence, binary availability, and network reachability, are used only as candidate initial facts for Datalog reasoning and are not counted as executable attack steps. The ground truth is constructed with an LLM-assisted annotation and manual review process. We first use gpt-5.5 [23] to identify candidate state-changing attack behaviors from each report, and then verify the candidates with Claude Opus 4.8 [3] and manual review. Each annotated step corresponds to one core state-changing attack behavior and is represented in structured JSON with pre_groups and post_groups. Predicates within the same group represent equivalent or alternative expressions, while different groups represent separate required conditions or effects. All 20 reports are used for attack-step coverage and predicate-level evaluation. Among them, four representative reports are further used for detailed case analysis and ablation: DeputyDog, Frankenstein, OceanLotus, and Cobalt [17]. These reports cover different combinations of report length, chain topology, and branching structure. V-A2 Compared Methods and Implementation We compare our framework with three representative CTI extraction systems: AttacKG+ [36], CRUcialG [6], and CTINEXUS [7]. These methods produce heterogeneous outputs, such as entity-relation triples, attack graphs, TTP labels, or cyber threat knowledge graphs. Since they are not designed to output explicit precondition–postcondition attack units, directly comparing predicate-level recall would be unfair. We therefore compare all methods using attack-step coverage, which evaluates whether the core attack behaviors in the annotated steps are recovered. Our framework uses gpt-4.1 [21] for attack behavior skeleton extraction, pre/postcondition extraction, and predicate normalization, and uses gpt-5.2 [22] for diagnosis-guided repair. Full prompts and decoding parameters are provided in our code222https://anonymous.4open.science/r/artifact064b. The Datalog reasoning stage uses no LLM. The internal ablation variants are described in Section V-E. Reasoning configuration In practical deployment, F0F_0 would be provided by the configuration of the target system. Since the evaluated CTI reports are not accompanied by concrete target-system inventories, we construct F0F_0 from static conditions supported or reasonably implied by each report, such as vulnerability presence, software or binary availability, credentials, and network connectivity. States produced by attacker behaviors, including downloaded payloads, started processes, and established C2 channels, are excluded from F0F_0 and must be derived from the extracted rules. For each report, we select a security-relevant terminal state described in the report as the reasoning goal. The purpose of this setup is to evaluate the internal reasoning readiness of the extracted chain: whether its attack units form a connected derivation from the report-supported initial conditions to the selected terminal state. V-A3 Evaluation Metrics We use two complementary evaluation metrics. First, we use attack-step coverage to compare CTI extraction systems. Because the methods produce different types of results, we manually align their extractions with the annotated attack steps. The alignment is ground-truth-step-centered: one ground-truth step may align with one extracted unit or multiple finer-grained extracted units, but it contributes only one score. Each ground-truth step is labeled Full, Partial, or Miss according to its coverage. A Full match requires the aligned extraction to recover the core attack behavior and the essential behavioral details needed to distinguish the step, such as its target, object, or execution mechanism. A Partial match is assigned when the core behavior is recognizable but one or more distinguishing details are omitted, over-generalized, or only indirectly represented. A Miss indicates that no extracted output can be semantically aligned with the annotated step. For each ground-truth step s, we define its coverage score as: score(s)=1,Full,0.5,Partial,0,Miss.score(s)= cases1,&Full,\\ 0.5,&Partial,\\ 0,&Miss. cases (8) We report the numbers of steps labeled Full, Partial, and Miss (F/P/M), together with Step Coverage. Step Coverage is the mean coverage score over all ground-truth executable steps: StepCoverage=1N∑s=1Nscore(s)=F+0.5PF+P+M×100%,StepCoverage= 1N _s=1^Nscore(s)= F+0.5PF+P+M× 100\%, (9) where N=F+P+MN=F+P+M is the number of ground-truth executable steps. Second, we use pre/postcondition coverage to evaluate whether the extracted preconditions and postconditions match the ground-truth annotation. This metric is used only for our framework and its internal variants, because the compared systems do not produce normalized precondition–postcondition attack units. An extracted predicate is counted as correct only when its predicate and normalized parameters match those in the ground-truth annotation. In some cases, the same condition or effect may have multiple valid predicate expressions. We put these expressions into the same alternative group. Matching any predicate in the group counts as covering that condition or effect, and the group is counted only once. We report Predicate F1 across all precondition and postcondition items, along with Precondition Recall and Postcondition Recall. Recall measures the fraction of ground-truth items covered by the extraction, and precision measures the fraction of extracted items supported by the ground truth. V-B Attack-Step Coverage (a) AttacKG+ (b) CRUcialG (c) CTINEXUS (d) Ours Figure 3: Local comparison of different extraction methods on the Cobalt report. The selected region corresponds to the JScript backdoor branch, where the proposed framework preserves explicit state transitions between adjacent attack steps. Figure 3 shows a local example from the Cobalt JScript-backdoor branch. The compared methods recover different kinds of information: AttacKG+ extracts entities and high-level relations, CRUcialG builds a coarse scenario graph, and CTINEXUS produces relation triples. In contrast, our framework extracts attack units with explicit preconditions and postconditions, making the state transitions between adjacent steps visible. TABLE I: Attack-step coverage comparison with existing CTI extraction methods on 20 CTI reports. For each method, F/P/M denotes the numbers of annotated steps that are fully covered, partially covered, and missed, respectively. The best Step Coverage result for each report is highlighted in bold. Report Ground Truth AttacKG+ CRUcialG CTINEXUS Ours F/P/M Coverage(%) F/P/M Coverage(%) F/P/M Coverage(%) F/P/M Coverage(%) Cobalt 27 6/20/1 59.3 6/19/2 57.4 18/8/1 81.5 23/4/0 92.6 DeputyDog 12 5/7/0 70.8 3/6/3 50.0 9/3/0 87.5 11/1/0 95.8 Frankenstein 19 14/5/0 86.8 3/11/5 44.7 16/3/0 92.1 16/3/0 92.1 OceanLotus 15 9/6/0 80.0 3/7/5 43.3 9/6/0 80.0 12/3/0 90.0 XAgentOSX 17 13/4/0 88.2 2/10/5 41.2 13/4/0 88.2 13/4/0 88.2 macOS.Macma 13 8/4/1 76.9 4/3/6 42.3 9/3/1 80.8 10/2/1 84.6 Emotet Campaigns 12 8/4/0 83.3 5/5/2 62.5 10/2/0 91.7 12/0/0 100.0 Silence Trojan 18 11/7/0 80.6 7/11/0 69.4 12/6/0 83.3 18/0/0 100.0 Elfin / APT33 23 18/3/2 84.8 10/10/3 65.2 15/6/2 78.3 22/1/0 97.8 SpeakUp 21 16/5/0 88.1 2/6/13 23.8 10/5/6 59.5 18/3/0 92.9 TSCookie 15 11/4/0 86.7 1/6/8 26.7 11/4/0 86.7 15/0/0 100.0 Sodinokibi Crescendo 27 18/8/1 81.5 1/9/17 20.4 13/8/6 63.0 22/5/0 90.7 Sofacy Fysbis 12 6/6/0 75.0 0/6/6 25.0 5/5/2 62.5 10/1/1 87.5 Gamaredon COVID-19 12 8/4/0 83.3 0/6/6 25.0 11/1/0 95.8 12/0/0 100.0 BabyShark 17 10/7/0 79.4 1/14/2 47.1 11/6/0 82.4 17/0/0 100.0 Deep Panda 15 11/4/0 86.7 0/11/4 36.7 13/2/0 93.3 15/0/0 100.0 HermeticWiper 17 10/7/0 79.4 1/5/11 20.6 9/8/0 76.5 12/5/0 85.3 Rover Trojan 16 13/3/0 90.6 6/8/2 62.5 14/2/0 93.8 16/0/0 100.0 DEV-0586 / WhisperGate 8 5/3/0 81.2 1/6/1 50.0 6/2/0 87.5 8/0/0 100.0 Sednit Zebrocy 18 12/5/1 80.6 4/6/8 38.9 12/5/1 80.6 18/0/0 100.0 Total F/P/M 334 212/116/6 - 60/165/109 - 226/89/19 - 300/32/2 - Average - - 81.1 - 42.6 - 82.2 - 94.9 Because the compared methods do not generate normalized precondition–postcondition units, we evaluate them at the attack-step level. Attack-step coverage measures how well the extracted steps cover the ground-truth attack steps. Table I reports attack-step coverage on 20 reports containing 334 annotated executable steps. Our framework achieves the highest macro-average Step Coverage of 94.9%, compared with 82.2% for CTINEXUS, 81.1% for AttacKG+, and 42.6% for CRUcialG. Across all 334 annotated steps, our framework fully covers 300, partially covers 32, and misses only two. AttacKG+ and CTINEXUS achieve lower coverage primarily because more annotated steps are only partially covered, while CRUcialG misses 109 steps. These results show that the improvement mainly comes from recovering complete executable attack steps rather than outputs that capture only some of the relevant entities, relations, techniques, or scenario nodes. Our framework achieves the best or tied-best result on every report, providing a strong basis for the subsequent evaluation of preconditions, postconditions, and reasoning readiness. V-C Pre/Postcondition Coverage We evaluate pre/postcondition coverage using the predicate-level metrics defined in Section V-A3. TABLE I: Pre/postcondition coverage on 20 CTI reports under exact predicate checking after normalization. Predicate F1, Precision (P), and Recall (R) are computed over all precondition and postcondition items. Pre R and Post R report recall for preconditions and postconditions, respectively. Report F1(%) P(%) R(%) Pre R(%) Post R(%) Cobalt 95.7 95.0 96.3 94.7 97.7 DeputyDog 93.8 100.0 88.3 88.9 87.9 Frankenstein 93.3 100.0 87.5 89.3 86.1 OceanLotus 95.3 100.0 91.1 90.0 92.0 XAgentOSX 52.7 66.0 43.9 33.3 58.3 macOS.Macma 51.3 49.1 53.8 55.0 52.6 Emotet Campaigns 81.1 71.2 94.3 94.4 94.1 Silence Trojan 75.4 89.1 65.4 75.0 57.1 Elfin / APT33 81.7 87.9 76.4 82.1 69.7 SpeakUp 93.0 98.8 88.0 93.0 82.5 TSCookie 84.6 84.1 85.1 90.0 81.5 Sodinokibi Crescendo 79.1 76.7 81.6 90.9 72.1 Sofacy Fysbis 85.5 97.4 76.2 91.3 57.9 Gamaredon COVID-19 71.9 75.7 68.4 70.0 66.7 BabyShark 77.3 84.6 71.2 86.2 56.7 Deep Panda 94.2 94.3 94.1 100.0 88.5 HermeticWiper 66.7 80.6 56.9 57.7 56.0 Rover Trojan 66.7 61.3 73.2 69.0 77.8 DEV-0586 / WhisperGate 91.9 100.0 85.0 90.9 77.8 Sednit Zebrocy 85.8 93.3 79.4 80.0 78.9 Average 80.9 85.3 77.8 81.1 74.6 Table I reports the predicate-level results on the 20 CTI reports. The performance is consistently high for most reports. Twelve of the 20 reports achieve Predicate F1 above 80%, including seven above 90%. In particular, Cobalt, DeputyDog, Frankenstein, OceanLotus, SpeakUp, Deep Panda, and DEV-0586/WhisperGate all achieve Predicate F1 above 90%. Averaged across the 20 reports, the framework achieves 80.9% Predicate F1, with 85.3% precision and 77.8% recall overall, and precondition and postcondition recall of 81.1% and 74.6%, respectively. These results indicate that the extracted attack units generally recover both the conditions required to execute an attack behavior and the security states produced after its execution. To understand the failure modes of exact predicate matching, we analyze the two lowest-scoring reports. In both, our method recovers the underlying attack behaviors, but the resulting predicates do not align with the annotation under exact checking. For XAgentOSX, the low coverage comes from a coarser normalization that stays internally consistent but no longer matches the annotated predicates. This mismatch comes mainly from two recurring substitutions. First, the running malware is represented by the generic state access.session(victim_host, C2_agent) and reused as a precondition across almost every downstream step. The ground truth instead keeps two distinct states: access.process_started for the running process and access.remote_control for attacker control. Second, distinct C2 commands are each specified in the ground truth with a specific parameter, such as c2_command_received(victim_host, remote_shell_command). The pipeline assigns all of them the same generic parameter attacker_command. For macOS.Macma, the low coverage comes from errors of a different kind: a structural mistake in the branch topology and pervasive naming inconsistency. The report describes two independent delivery branches that later converge. One is a DMG branch that drops UserAgent_2019 without any exploit; the other is a vulnerability branch in which a zero-day and an N-day drop a standalone installer that installs UserAgent_2021. The pipeline collapses these into one: it models the two vulnerabilities as variants but has both produce UserAgent_2019, and does not recover the separate 2021 installer or the UserAgent_2021 binary. As a result, the 2021 branch is not preserved as a distinct state-transition sequence, causing its associated predicate groups to remain unmatched or only partially matched under exact checking. The remaining loss is naming drift—the same entity written as UserAgent_2019 versus UserAgent 2019, or as a canonical symbol versus a full path—which stays consistent within the chain but fails exact matching. The unmatched predicates reveal that extraction can still suffer from over-general normalization, branch conflation, and entity-naming drift. Nonetheless, the framework produces accurate precondition–postcondition units on most of the CTI reports. V-D Datalog Reasoning We evaluate whether the final attack chains can support Datalog-based reachability reasoning and attack-path recovery. As described in Section IV-F, the normalized attack units are converted into Datalog-style rules. For each report, we specify an attack goal. Forward chaining starts from the initial fact set F0F_0 and checks whether the goal can be derived. For a reachable goal, backward search traces the dependencies from the goal to the initial facts and recovers the supporting attack paths. The reasoning evaluation operates on the final attack units rather than directly on the annotated attack steps. The number of final units may therefore exceed the number of annotated steps because one annotated behavior may be decomposed into several finer-grained state transitions. For example, the 27 annotated steps in Cobalt are represented as 41 attack units. Table I reports the reasoning results on all 20 reports. In addition to goal reachability and the number of recovered paths, we use two deterministic consistency checks on the final chains. Resid. counts preconditions that are neither included in F0F_0 nor produced by an earlier attack unit. NoPost counts units whose postcondition set is empty. TABLE I: Datalog reasoning results on the 20 CTI reports. #Units is the number of attack units in the final chain. Reach indicates whether forward chaining derives the specified attack goal from F0F_0. #Paths is the number of supporting attack paths recovered by backward search. Resid. counts preconditions that remain unsupported in the final chain. NoPost counts units with an empty postcondition set. Report #Units Reach #Paths Resid. NoPost Cobalt 41 ✓ 2 0 0 DeputyDog 17 ✓ 1 0 1 Frankenstein 20 ✓ 1 0 0 OceanLotus 23 ✓ 1 0 4 XAgentOSX 15 ✓ 1 0 0 macOS.Macma 17 ✓ 7 0 2 Emotet Campaigns 18 ✓ 2 0 2 Silence Trojan 23 ✓ 3 0 5 Elfin / APT33 23 ✓ 2 0 2 SpeakUp 20 ✓ 2 0 1 TSCookie 15 ✓ 1 0 0 Sodinokibi Crescendo 55 ✓ 3 2 6 Sofacy Fysbis 12 ✓ 1 0 0 Gamaredon COVID-19 14 ✓ 1 0 2 BabyShark 19 ✓ 2 0 1 Deep Panda 20 ✗ 0 1 0 HermeticWiper 17 ✓ 1 0 1 Rover Trojan 32 ✓ 1 1 1 DEV-0586 / WhisperGate 9 ✓ 1 0 2 Sednit Zebrocy 26 ✓ 1 0 4 Total 436 19/20 34 4 34 Across the 20 reports, forward chaining derives the specified attack goal in 19 cases, and backward search recovers 34 supporting attack paths in total. These results show that the extracted rules usually contain at least one connected path from the initial facts to a security-relevant terminal state. The number of paths varies across reports because some reports describe alternative delivery, execution, or payload branches, whereas others contain only one route to the selected goal. The path count is therefore a description of the generated chain structure rather than a higher-is-better metric. Seventeen of the 20 reports contain no unsupported preconditions in their final chains. Only four unsupported preconditions remain across the test: two in Sodinokibi Crescendo, one in Deep Panda, and one in Rover Trojan. Sodinokibi Crescendo and Rover Trojan remain goal-reachable because the unresolved conditions are not required by at least one successful path. This result shows that a selected goal can remain reachable even when another branch contains an unresolved dependency. Among the 436 final attack units, 402 units contain at least one postcondition and therefore generate at least one Datalog rule. The remaining 34 units have an empty postcondition set and do not produce a rule head. These units may preserve behaviors recovered from the report, but they do not define complete state transitions and cannot propagate new facts during forward chaining. A NoPost unit may arise because the report does not clearly describe the resulting state, or because an implicit effect is not successfully mapped to a normalized predicate. Sodinokibi Crescendo illustrates a different limitation from ordinary dependency breaks. The report summarizes several affiliate groups, campaign periods, and initial-access methods, including spear-phishing, RDP compromise, and ransomware distribution through managed service providers. These activities are not presented as one continuous attack instance. However, the normalization stage fails to preserve campaign-specific entity identities and maps hosts from different incidents to shared symbols such as victim_host. This collapses otherwise separate campaign contexts and allows a state from one campaign to incorrectly satisfy a precondition from another. The resulting cross-campaign paths are not supported by any single attack instance described in the report. This effect is visible in the three recovered paths. For example, one path joins the MSP-distribution branch with an RDP-credential branch and a local-exploit privilege-escalation branch before reaching the ransomware-deployment goal. The individual steps are supported by the report, but the report does not explicitly describe them as one end-to-end attack sequence. The resulting path is valid under the generated rules, but it may represent a composition of different campaign fragments rather than one observed attack instance. The 2 residual preconditions and 6 NoPost units further show that the report cannot be represented as a single complete chain without preserving campaign-specific context. Deep Panda is the only report for which the specified goal is unreachable. The failure is caused by an implicit static environment condition being represented as a dynamically produced attack state. The report states that the attackers used WMI to remotely deploy PowerShell scripts and create scheduled tasks on other systems. This behavior reasonably requires WMI connectivity between the involved hosts. The extracted remote-deployment unit is represented as: Pre: access.credential(compromised_user_account, password),net.lateral_access(victim_host,target_windows_host, WMI) array[t]@l@ access.credential(compromised\_user\_account, password),\\ net.lateral\_access(victim\_host,target\_windows\_host, WMI) array Post: access.persistence(target_windows_host, scheduled_task),data.on_disk(target_windows_host,powershell_task_script, PowerShell) array[t]@l@ access.persistence(target\_windows\_host, scheduled\_task),\\ data.script\_on\_disk(target\_windows\_host,\\ 16.38895pt powershell\_task\_script, PowerShell) array The extracted unit uses net.lateral_access (victim_host, target_windows_host, WMI) as a precondition of the remote-deployment step. This predicate is a reasonable prerequisite, but it represents a static target-system condition and should be included in initial fact F0F_0. However, in the extracted chain, it is neither included in F0F_0 nor produced by an earlier attack unit. The diagnosis stage identifies this unsupported precondition, but the repair stage handles it incorrectly. It introduces a bridge step that attempts to derive the WMI lateral-access predicate from: Pre:net.same_subnet(victim_host,target_windows_host)Post:net.lateral_access(victim_host,target_windows_host, WMI) array[]@l@Pre:& net.same\_subnet(victim\_host,target\_windows\_host)\\[3.0pt] Post:& net.lateral\_access(victim\_host,target\_windows\_host, WMI) array This newly introduced precondition is also absent from F0F_0 and is not produced by any preceding unit. Consequently, the bridge step cannot be executed, and the required WMI lateral-access state is still not derived. Forward chaining therefore stops before the remote-deployment step, preventing the subsequent scheduled-task step and the specified goal from being reached. A more appropriate representation would classify WMI connectivity as a static target-system condition rather than a state produced during the attack. Since the report describes the attackers using WMI but does not identify any earlier step that establishes this connectivity, net.access(victim_host, target_windows_host, WMI) should be included in F0F_0 when this interpretation is supported by the report. Such a fact should not be introduced merely to make the goal reachable. This case highlights that CTI reports often assume existing environmental capabilities without stating them explicitly. Distinguishing such static conditions from dynamically produced attack states is essential for reliable attack-path reasoning. Overall, the results show that the extracted attack units generally form connected rule sets that support attack-goal reachability and attack-path recovery. The remaining limitations mainly arise from implicit target-system assumptions, incomplete state transitions, and reports that aggregate multiple campaign contexts into one narrative. V-E Ablation Study We conduct the ablation study on Cobalt, DeputyDog, Frankenstein, and OceanLotus [17]. These reports cover different attack-chain structures, including multiple delivery paths, converging infection branches, and platform-specific payload delivery. All variants are evaluated using the predicate-level metrics defined in Section V-C. We compare the full pipeline with four variants. Full uses all stages of the proposed framework. End-to-End GPT-4.1 and End-to-End GPT-5.2 directly generate the final normalized attack chain from each input report. The two variants use gpt-4.1 and gpt-5.2, respectively. They use the same output schema and vocabularies as the full pipeline but bypass the intermediate stages of behavior extraction, condition extraction, predicate normalization, and diagnosis-guided repair. w/o Repair removes the diagnosis-guided repair stage after predicate normalization. w/o Behavior removes the behavior vocabulary during attack-skeleton extraction while retaining the remaining stages. TABLE IV: Ablation results under exact predicate matching. R, P, and F1 denote predicate recall, precision, and F1, respectively. Report Method R (%) P (%) F1 (%) Cobalt Full 96.3 95.0 95.7 End-to-End GPT-4.1 28.0 47.5 35.3 End-to-End GPT-5.2 22.0 28.9 24.9 w/o Repair 81.7 78.0 79.8 w/o Behavior 35.4 68.4 46.6 DeputyDog Full 88.3 100.0 93.8 End-to-End GPT-4.1 50.0 80.0 61.5 End-to-End GPT-5.2 71.7 74.5 73.0 w/o Repair 71.7 80.8 75.9 w/o Behavior 60.0 77.8 67.7 Frankenstein Full 87.5 100.0 93.3 End-to-End GPT-4.1 45.3 80.0 57.9 End-to-End GPT-5.2 60.9 68.4 64.5 w/o Repair 75.0 96.4 84.4 w/o Behavior 64.1 58.9 61.4 OceanLotus Full 91.1 100.0 95.3 End-to-End GPT-4.1 26.7 50.0 34.8 End-to-End GPT-5.2 42.2 43.2 42.7 w/o Repair 75.6 84.2 79.6 w/o Behavior 48.9 65.4 55.9 Average Full 90.8 98.8 94.5 End-to-End GPT-4.1 37.5 64.4 47.4 End-to-End GPT-5.2 49.2 53.8 51.3 w/o Repair 76.0 84.8 79.9 w/o Behavior 52.1 67.6 57.9 Table IV shows that the full pipeline achieves the best result on all four reports. Its average recall, precision, and F1 are 90.8%, 98.8%, and 94.5%, respectively, indicating that the pipeline recovers most annotated predicates while introducing few unsupported predictions. The two end-to-end variants perform substantially worse. End-to-End GPT-4.1 achieves an average F1 of 47.4%. End-to-End GPT-5.2 improves recall from 37.5% to 49.2%, but its precision decreases from 64.4% to 53.8%, resulting in an average F1 of only 51.3%. These results show that using a stronger model alone does not provide the structured and precise predicate extraction achieved by the staged pipeline. Removing repair reduces the average F1 from 94.5% to 79.9%. The performance decrease appears on all four reports, showing that the repair stage corrects predicate errors that remain after normalization. Removing behavior guidance causes a larger decrease, reducing the average F1 to 57.9%. Without behavior guidance, the extracted steps have less stable boundaries, which affects subsequent condition extraction and predicate normalization. Overall, the results show that staged extraction, behavior guidance, and diagnosis-guided repair all contribute to the accuracy of the generated attack chains. VI Discussion and Limitations This work focuses on converting unstructured CTI reports into reachable attack chains. By representing each attack step with preconditions, an attack behavior, and postconditions, the framework connects CTI extraction with Datalog-based reachability reasoning. The evaluation shows that this representation can recover attack behaviors, construct state dependencies, and support attack-path analysis. However, several limitations remain. First, the predicate vocabulary construction still depends heavily on expert knowledge [31] and manual design. Different choices of predicate granularity may lead to different representations of the same attack process. A coarse vocabulary may merge distinct states, while an overly detailed vocabulary increases the difficulty of normalization and reduces predicate reuse. The current vocabulary may therefore require further adjustment when applied to new report types or attack domains. Second, even with a fixed vocabulary, the LLM does not always map semantically equivalent states to a single canonical representation. Differences in predicate names, entity aliases, parameter values, and abstraction levels may result in the same preconditions and postconditions being expressed in multiple forms. These variations reduce exact predicate agreement even when the underlying attack behavior has been correctly recovered. Third, extraction quality is also limited by the reasoning capability of the LLM. Complex reports often contain implicit conditions, long-range dependencies, and alternative branches. The model may omit necessary conditions, merge independent branches, or introduce bridge states that appear internally consistent but are not fully supported by the report. Such errors may leave the generated chain connected while still introducing incorrect assumptions. Future work will explore more systematic vocabulary construction, stronger entity and predicate canonicalization, evidence-constrained extraction to reduce unsupported model inference, and privacy-preserving inference for hosted LLM services [35] to limit data exposure in sensitive deployments. VII Conclusion This paper presents an automated framework for transforming unstructured CTI reports into reachable attack chains. It represents each attack step with explicit preconditions, an attack behavior, and postconditions, and converts the normalized attack units into Datalog-style rules. This representation enables CTI knowledge to move beyond flat entities and technique labels toward connected state transitions that support reachability reasoning and attack-path recovery. Experiments on 20 CTI reports show that the framework can recover attack behaviors and construct reasoning-ready attack chains more effectively than representative extraction methods. Overall, this work provides a practical way to turn natural-language CTI into structured knowledge that can be directly used for automated security reasoning. Ethical Considerations This work uses publicly available CTI reports and focuses on extracting structured attack-chain representations for defensive analysis. The framework does not introduce new exploits, malware implementations, or operational attack procedures. The extracted attack units are normalized into abstract predicates and are used for dependency checking and reachability reasoning rather than for executing attacks. Nevertheless, CTI reports may contain sensitive technical details. We therefore avoid releasing additional offensive instructions beyond what is already publicly available in the source reports. The intended use of the framework is to support defensive reasoning, security analysis, and research reproducibility. References [1] M. T. Alam, D. Bhusal, L. Nguyen, and N. Rastogi (2024) CTIBench: A Benchmark for Evaluating LLMs in Cyber Threat Intelligence. In Advances in Neural Information Processing Systems 37, Vancouver, BC, Canada, p. 50805–50825. External Links: Document, ISBN 979-8-3313-1438-5 Cited by: §I. [2] M. T. Alam, D. Bhusal, Y. Park, and N. Rastogi (2023-10) Looking Beyond IoCs: Automatically Extracting Attack Patterns from External CTI. In Proceedings of the 26th International Symposium on Research in Attacks, Intrusions and Defenses, Hong Kong China, p. 92–108. External Links: Document, ISBN 979-8-4007-0765-0 Cited by: §I. [3] Anthropic (2026) Introducing Claude Opus 4.8. Note: Large language model. Accessed June 2026 External Links: Link Cited by: §V-A1. [4] M. Büchel, T. Paladini, S. Longari, M. Carminati, S. Zanero, H. Binyamini, G. Engelberg, D. Klein, G. Guizzardi, M. Caselli, A. Continella, M. van Steen, A. Peter, and T. van Ede (2025-08) SoK: Automated TTP Extraction from CTI Reports – Are We There Yet?. In 34th USENIX Security Symposium (USENIX Security 25), Seattle, WA, p. 4621–4641. External Links: ISBN 978-1-939133-52-6 Cited by: §I, §I-A. [5] M. Chen, K. Zhu, B. Lu, D. Li, Q. Yuan, and Y. Zhu (2025-03) AECR: Automatic attack technique intelligence extraction based on fine-tuned large language model. Computers & Security 150, p. 104213. External Links: ISSN 01674048, Document Cited by: §I. [6] W. Cheng, T. Zhu, T. Chen, Q. Yuan, J. Ying, H. Li, C. Xiong, M. Li, M. Lv, and Y. Chen (2025-11) CRUcialG: Reconstruct Integrated Attack Scenario Graphs by Cyber Threat Intelligence Reports. IEEE Transactions on Dependable and Secure Computing 22 (6), p. 6345–6360. External Links: ISSN 1545-5971, 1941-0018, 2160-9209, Document Cited by: §I, §I-A, §V-A2. [7] Y. Cheng, O. Bajaber, S. A. Tsegai, D. Song, and P. Gao (2025-06) CTINexus: Automatic Cyber Threat Intelligence Knowledge Graph Construction Using Large Language Models. In 2025 IEEE 10th European Symposium on Security and Privacy (EuroS&P), Venice, Italy, p. 923–938. External Links: Document, ISBN 979-8-3315-9493-0 Cited by: §I, §I-A, §V-A2. [8] S. Della Penna, R. Natella, V. Orbinato, L. Parracino, and L. Pianese (2025) CTI-HAL: A Human-Annotated Dataset for Cyber Threat Intelligence Analysis. arXiv. External Links: Document Cited by: §I, §I-A. [9] P. Gao, X. Liu, E. Choi, S. Ma, X. Yang, and D. Song (2023-11) ThreatKG: An AI-Powered System for Automated Open-Source Cyber Threat Intelligence Gathering and Management. In Proceedings of the 1st ACM Workshop on Large AI Systems and Models with Privacy and Safety Analysis, Salt Lake City UT USA, p. 1–12. External Links: Document, ISBN 979-8-4007-1209-8 Cited by: §I. [10] Y. Hu, F. Zou, J. Han, X. Sun, and Y. Wang (2024-10) LLM-TIKG: Threat intelligence knowledge graph construction utilizing large language model. Computers & Security 145, p. 103999. External Links: ISSN 01674048, Document Cited by: §I, §I-A. [11] L. Huang, W. Yu, W. Ma, W. Zhong, Z. Feng, H. Wang, Q. Chen, W. Peng, X. Feng, B. Qin, and T. Liu (2025-03) A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions. ACM Transactions on Information Systems 43 (2), p. 1–55. External Links: ISSN 1046-8188, 1558-2868, Document Cited by: §I. [12] L. Huang and X. Xiao (2024) CTIKG: LLM-powered knowledge graph construction from cyber threat intelligence. In First Conference on Language Modeling, Cited by: §I. [13] G. Husari, E. Al-Shaer, M. Ahmed, B. Chu, and X. Niu (2017-12) TTPDrill: Automatic and Accurate Extraction of Threat Actions from Unstructured Text of CTI Sources. In Proceedings of the 33rd Annual Computer Security Applications Conference, Orlando FL USA, p. 103–115. External Links: Document, ISBN 978-1-4503-5345-8 Cited by: §I, §I, §I-A. [14] L. Lange, M. Müller, G. Haratinezhad Torbati, D. Milchevski, P. Grau, S. C. Pujari, and A. Friedrich (2024-05) AnnoCTR: a dataset for detecting and linking entities, tactics, and techniques in cyber threat reports. In Proceedings of the 2024 Joint International Conference on Computational Linguistics, Language Resources and Evaluation (LREC-COLING 2024), Torino, Italia, p. 1147–1160. External Links: Link Cited by: §I-A. [15] V. Legoy, M. Caselli, C. Seifert, and A. Peter (2020) Automated Retrieval of ATT&CK Tactics and Techniques for Cyber Threat Reports. arXiv. External Links: Document Cited by: §I-A. [16] L. Li, C. Huang, and J. Chen (2024-05) Automated discovery and mapping ATT&CK tactics and techniques for unstructured cyber threat intelligence. Computers & Security 140, p. 103815. External Links: ISSN 01674048, Document Cited by: §I-A. [17] Z. Li, J. Zeng, Y. Chen, and Z. Liang (2022) AttacKG: Constructing Technique Knowledge Graph from Cyber Threat Intelligence Reports. In Computer Security – ESORICS 2022, V. Atluri, R. Di Pietro, C. D. Jensen, and W. Meng (Eds.), Vol. 13554, p. 589–609. External Links: Document, ISBN 978-3-031-17139-0 978-3-031-17140-6 Cited by: §I, §I, §I-A, §V-A1, §V-A1, §V-E. [18] X. Liao, K. Yuan, X. Wang, Z. Li, L. Xing, and R. Beyah (2016-10) Acing the IOC Game: Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna Austria, p. 755–766. External Links: Document, ISBN 978-1-4503-4139-4 Cited by: §I, §I-A. [19] C. Liu, J. Wang, and X. Chen (2022-06) Threat intelligence ATT&CK extraction based on the attention transformer hierarchical recurrent neural network. Applied Soft Computing 122, p. 108826. External Links: ISSN 15684946, Document Cited by: §I-A. [20] H. Ma, J. Yong, Y. Ma, K. Chen, A. Yusof, Z. Liang, and E. Chang (2025) AttackSeqBench: Benchmarking the Capabilities of LLMs for Attack Sequences Understanding. arXiv. External Links: Document Cited by: §I. [21] OpenAI (2025) Introducing GPT-4.1 in the API. Note: Large language model. Accessed June 2026 External Links: Link Cited by: §V-A2. [22] OpenAI (2025) Introducing GPT-5.2. Note: Large language model. Accessed June 2026 External Links: Link Cited by: §V-A2. [23] OpenAI (2026) Introducing GPT-5.5. Note: Large language model. Accessed June 2026 External Links: Link Cited by: §V-A1. [24] X. Ou, W. F. Boyer, and M. A. McQueen (2006-10) A scalable approach to attack graph generation. In Proceedings of the 13th ACM Conference on Computer and Communications Security, Alexandria Virginia USA, p. 336–345. External Links: Document, ISBN 978-1-59593-518-2 Cited by: §I-B. [25] X. Ou, S. Govindavajhala, and A. W. Appel (2005-07) MulVAL: a logic-based network security analyzer. In 14th USENIX Security Symposium (USENIX Security 05), Baltimore, MD. External Links: Link Cited by: §I, §I, §I-B, §IV-A. [26] M. R. Rahman, B. Wroblewski, Q. Matthews, B. Morgan, T. Menzies, and L. Williams (2025-10) Mining temporal attack patterns from cyberthreat intelligence reports. Knowledge and Information Systems 67 (10), p. 8941–8981. External Links: ISSN 0219-1377, 0219-3116, Document Cited by: §I, §V-A1. [27] N. Rani, B. Saha, V. Maurya, and S. K. Shukla (2023-01) TTPHunter: Automated Extraction of Actionable Intelligence as TTPs from Narrative Threat Reports. In 2023 Australasian Computer Science Week, Melbourne VIC Australia, p. 126–134. External Links: Document, ISBN 979-8-4007-0005-7 Cited by: §I-A. [28] N. Rani, B. Saha, V. Maurya, and S. K. Shukla (2024-12) TTPXHunter: Actionable Threat Intelligence Extraction as TTPs from Finished Cyber Threat Reports. Digital Threats: Research and Practice 5 (4), p. 1–19. External Links: ISSN 2576-5337, Document Cited by: §I, §I-A. [29] K. Satvat, R. Gjomemo, and V.N. Venkatakrishnan (2021-09) Extractor: Extracting Attack Behavior from Threat Reports. In 2021 IEEE European Symposium on Security and Privacy (EuroS&P), Vienna, Austria, p. 598–615. External Links: Document, ISBN 978-1-6654-1491-3 Cited by: §I, §I-A. [30] B. E. Strom, A. Applebaum, D. Miller, K. C. Nickels, A. G. Pennington, and C. B. Thomas (2020) MITRE ATT&CK: Design and philosophy. Technical report The MITRE Corporation. Cited by: §IV-A. [31] The MITRE Corporation (2026) MITRE ATT&CK enterprise matrix. Cited by: §I, §IV-A, §VI. [32] Z. Wang, S. Fei, Y. Hu, D. Shan, S. Xiao, L. You, and P. Chen (2025-06) Automated Attack Knowledge Graph Construction with Large Language Models. In Proceedings of the 2025 2nd International Conference on Computer and Multimedia Technology, Sanming China, p. 700–706. External Links: Document, ISBN 979-8-4007-1334-7 Cited by: §I. [33] M. Xu, H. Wang, J. Liu, X. Li, Z. Yu, W. Han, H. W. Lim, J. S. Dong, and J. Zhang (2024) ThreatPilot: Attack-Driven Threat Intelligence Extraction. arXiv. External Links: Document Cited by: §I. [34] X. Yang, R. Zhong, Y. Chen, G. Peng, D. Yao, C. Chen, C. Wang, D. Zhang, Y. Zhou, and Z. Yang (2026-01) CTI-Thinker: an LLM-driven system for CTI knowledge graph construction and attack reasoning. Cybersecurity 9 (1), p. 106. External Links: ISSN 2523-3246, Document Cited by: §I, §I-A. [35] Z. Ye, W. Luo, Q. Zhou, and Y. Tang (2026) Reconstruction attack-resistant inference paradigm for llm cloud services. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 40, p. 17939–17947. Cited by: §VI. [36] Y. Zhang, T. Du, Y. Ma, X. Wang, Y. Xie, G. Yang, Y. Lu, and E. Chang (2025-03) AttacKG+: Boosting attack graph construction with Large Language Models. Computers & Security 150, p. 104220. External Links: ISSN 01674048, Document Cited by: §I, §I-A, §V-A2. [37] J. Zhao, Q. Yan, J. Li, M. Shao, Z. He, and B. Li (2020-08) TIMiner: Automatically extracting and analyzing categorized cyber threat intelligence from social data. Computers & Security 95, p. 101867. External Links: ISSN 01674048, Document Cited by: §I-A. [38] J. Zhao, Q. Yan, X. Liu, B. Li, and G. Zuo (2020-10) Cyber threat intelligence modeling based on heterogeneous graph convolutional network. In 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020), San Sebastian, p. 241–256. External Links: ISBN 978-1-939133-18-2 Cited by: §I-A. [39] Z. Zhu and T. Dumitras (2018-04) ChainSmith: Automatically Learning the Semantics of Malicious Campaigns by Mining Threat Intelligence Reports. In 2018 IEEE European Symposium on Security and Privacy (EuroS&P), London, p. 458–472. External Links: Document, ISBN 978-1-5386-4228-3 Cited by: §I-A. -A Behavior Vocabulary The behavior vocabulary contains 16 coarse-grained behavior classes used during attack behavior skeleton extraction. These classes help keep attack steps at a stable granularity, but they are not used in Datalog reasoning. Table V lists the behavior classes. TABLE V: Behavior vocabulary used for attack behavior skeleton extraction. Behavior class Description user_action A victim-triggered action that directly advances the attack chain, such as opening a document or clicking a link. delivery A malicious artifact, lure, or initial stage is delivered into the victim environment. download A document, script, payload, or other artifact is retrieved from a remote location. write An artifact is written, dropped, or stored on disk, in the registry, or in another persistent location. execute Code, script, exploit, macro, payload, or command execution occurs. evasion A defense, policy, restriction, or visibility mechanism is bypassed, weakened, or evaded. communication The malware or attacker communicates over the network, especially with C2 infrastructure. collection The malware or attacker gathers information from the victim environment. exfiltration Previously collected data is sent out of the victim environment to attacker-controlled infrastructure. persistence An automatic execution mechanism is established or modified to survive reboot, login, or service restart. discovery Hosts, accounts, services, drives, or network topology are enumerated to guide later movement or targeting. credential_access Credentials, tokens, password hashes, or cookies are obtained, dumped, reused, or brute-forced. lateral_movement The attacker moves to another host, account, or network segment via valid credentials or remote execution. impact Destructive, disruptive, or monetization-oriented effects are caused on the victim environment. removable_media Removable media is used as an execution, propagation, command-transfer, or exfiltration channel, especially for air-gapped environments. outcome A resulting attacker advantage, final compromise state, or achieved end state is explicitly described. -B Predicate Vocabulary The predicate vocabulary contains 139 predicate templates in 10 categories: net, host, access, data, user, evasion, persistence, discovery, load, and impact. Each predicate has the form category.predicate(arg1,arg2,...) and is used to represent a symbolic precondition or postcondition. Tables VI and VII list representative predicate templates. The complete vocabulary is released with the artifact. TABLE VI: Core predicate templates for normalized attack units. Category Predicate template Meaning Host state host.platform(host,platform) The host runs a specific platform or operating system. Host state host.software(host,software) The host has a required software component. Host state host.vuln_present(host,cve) The host is affected by a vulnerability. Host state host.feature_enabled(host,feature) A required feature or configuration is enabled. Network state net.access(src,dst,proto) The source can reach the destination over a protocol. Network state net.traffic_allowed(src,dst,proto) Traffic between two endpoints is allowed. User action user.opens_file(user,file) The victim opens a file. User action user.clicks_link(user,context) The victim clicks a link in an email, document, or web page. Delivery data.email_delivered(host,artifact) A malicious email or artifact is delivered to the victim. Document state data.document_downloaded(host,doc) A document is downloaded to the host. File state data.file_on_disk(host,file) A file or artifact exists on disk. Execution state access.process_started(host,proc) A process is started on the host. Code execution access.code_exec(host,priv) The attacker obtains code execution capability. TABLE VII: Auxiliary and impact predicate templates for normalized attack units. Category Predicate template Meaning Script state data.on_disk(host,script) A script is written to or present on disk. Script execution data.host_exec(host,proc,type) A script is executed through a host process. Payload state data.payload_downloaded(host,payload) A payload is downloaded to the host. Payload state data.payload_in_memory(host,payload) A payload is staged or loaded in memory. Payload execution data.payload_executed(host,payload) A payload is executed on the host. Loading load.dll_loaded(host,dll) A DLL is loaded by a process or the system. Loading load.driver_loaded(host,driver) A driver is loaded on the host. Evasion evasion.applocker_bypassed(host) Application control restrictions are bypassed. Evasion evasion.analysis_avoided(host) Anti-analysis or sandbox-evasion behavior succeeds. Collection data.collected(host,data) Information, files, or credentials are collected. Communication data.c2_request_sent(host,c2) The host sends a request to a C2 endpoint. Communication data.c2_channel(host,c2,proto) A command-and-control channel is established. Persistence access.persistence(host,method) A persistence mechanism is installed or enabled. Impact impact.mbr_corrupted(host) The master boot record is corrupted. Impact impact.partition_corrupted(host,part) A disk partition or file system structure is corrupted. Impact impact.file_encryption_attempted(host,file) The malware attempts to encrypt files. -C Attack-Unit Annotation Schema Each annotated attack unit contains an identifier, an attack behavior, and two predicate-group fields: pre_groups and post_groups. A precondition or postcondition may have multiple equivalent or alternative predicate expressions. These predicates are placed in the same group and are counted as one semantic condition or effect. Different groups are counted as separate conditions or effects. Figure 4 shows a simplified example. Long predicate arguments are shortened for readability. "id": "G03", "name": "Payload is downloaded", "pre_groups": [ ["access.code_exec(host,user)"], ["net.access(host,c2,HTTP)"] ], "post_groups": [ [ "data.payload_downloaded(host,payload)", "data.file_on_disk(host,payload)" ] ] Figure 4: Simplified attack-unit annotation schema. -D Diagnosis and Repair Details This appendix lists the issue types and repair actions used in the diagnosis-guided repair stage. The repair stage follows the diagnosis results: it only fixes the flagged issues and keeps the remaining attack chain unchanged. Table VIII summarizes the issue types used in our implementation. Connectivity issues indicate broken links between a precondition and earlier states. Semantic issues indicate predicates that do not match the report evidence or the predicate vocabulary. Branching and granularity issues describe incorrectly merged, split, or ordered attack steps. Repair-induced issues are checked in the second diagnosis round. TABLE VIII: Diagnosis issue types and repair actions used in diagnosis-guided repair. Issue type Category Repair action Unsupported precondition Connectivity Add a supported initial fact or connect the precondition to an earlier postcondition. Missing bridge state Connectivity Add a minimal bridge predicate to an earlier attack unit when supported by the report. Misplaced condition Connectivity Move the predicate to the attack step where the report evidence supports it. Semantic drift Semantic Replace the predicate with a faithful template from the predicate vocabulary. Over-specific mapping Semantic Use a more general predicate when the report does not support the specific state. Missed mapping Semantic Map an unresolved natural-language condition to an existing predicate template. Overclaimed postcondition Semantic Remove the unsupported postcondition or replace it with a weaker supported state. Weak postcondition Semantic Strengthen the postcondition if the report supports a more useful resulting state. Branch logic error Branching Split alternative branches so that they are not encoded as conjunctive dependencies. Over-compressed step Granularity Split one coarse step into multiple attack units with separate state transitions. Over-fragmented step Granularity Merge redundant fragments that do not produce distinct reasoning states. Ineffective repair Repair-induced Re-check repaired steps and remove repairs that do not resolve the diagnosed issue. Dynamic state as initial fact Repair-induced Move a dynamic attack state from the initial fact set to the postcondition of an attack step. We distinguish static requirements from dynamic attack states during repair. Static requirements, such as software availability, vulnerability existence, binary availability, and network reachability, can be added to the initial fact set when they are supported by the report or target-system setting. Dynamic states, such as downloaded payloads, started processes, established C2 channels, and collected data, must be produced by earlier attack units. They are therefore repaired by adjusting earlier postconditions rather than by adding them to the initial fact set. This prevents attacker-produced states from being treated as initial system facts.