Methods, apparatus, and non-volatile storage media for generating attack paths

Abstract

This invention discloses a method, apparatus, and non-volatile storage medium for generating attack paths. The method includes: acquiring attack information, wherein the attack information includes an attack target, an attack object, a vulnerability, and an attack result; constructing a task model based on the attack information; constructing multiple collaborative knowledge graphs based on preset semantic anchors; retrieving the multiple collaborative knowledge graphs according to the task model to construct a task subgraph; querying attack paths in the task subgraph according to the attack target to obtain candidate paths; calculating the scores corresponding to the candidate paths; and selecting candidate paths whose scores meet preset conditions as the target attack path. This invention solves the technical problem that existing AI attack path generation methods rely on static graphs, lack real-time environmental feedback and dynamic replanning capabilities, resulting in generated attack paths that cannot respond to execution deviations, alarm triggers, or asset changes, lack a closed-loop feedback mechanism, and cannot dynamically replan or adaptively repair.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and more specifically, to a method, apparatus, and non-volatile storage medium for generating attack paths. Background Technology

[0002] Enterprise-level AI systems consist of core components such as training and inference services, data pipelines, feature / vector libraries, model repositories, MLOps orchestration, and access control and key management. Their attack surface covers four layers: infrastructure, data, models, and external interfaces, facing complex and multi-dimensional threat challenges.

[0003] Existing attack path generation methods largely rely on static attack graphs, based on offline knowledge bases such as CVE, CWE, and ATT&CK. They deduce attack chains through predefined rules or probabilistic models, abstracting attack steps into nodes and searching paths using fixed dependencies and a single metric (such as success rate). However, these methods cannot integrate dynamic environmental information such as real-world asset configurations, network topology, software versions, and defense strategies, resulting in paths that are "theoretically feasible but practically unreachable." They lack runtime closed-loop feedback, failing to respond to alarms, state changes, or contradictory evidence. Their evaluation mechanisms are one-sided, neglecting stealth, execution costs, and the support of multi-source evidence. Furthermore, dynamic observation data such as security logs and CTI are not structured into computable "evidence anchors," failing to support dynamic perception and replanning of AI-specific attacks such as hint injection and adversarial examples.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides an attack path generation method, apparatus, and non-volatile storage medium to at least solve the technical problems of existing AI attack path generation methods that rely on static graphs, lack real-time environmental feedback and dynamic replanning capabilities, resulting in generated attack paths that cannot respond to execution deviations, alarm triggers, or asset changes, lack a closed-loop feedback mechanism, and cannot dynamically replan or adaptively repair.

[0006] According to one aspect of the present invention, an attack path generation method is provided, comprising: acquiring attack information, wherein the attack information includes an attack target, an attack object, a vulnerability, and an attack result; constructing a task model based on the attack information; constructing multiple collaborative knowledge graphs based on preset semantic anchors; retrieving the multiple collaborative knowledge graphs according to the task model to construct a task subgraph; querying attack paths according to the attack target in the task subgraph to obtain candidate paths; calculating the scores corresponding to the candidate paths; and selecting candidate paths whose scores meet preset conditions as target attack paths.

[0007] Optionally, the multiple collaborative knowledge graphs include an attack semantic graph, a tool implementation graph, and an environment and asset graph, wherein the attack semantic graph is a graph describing attack logic, the tool implementation graph is a graph describing attack tools and constraints, and the environment and asset graph is a graph describing attack states.

[0008] Optionally, based on the task model, multiple collaborative knowledge graphs are searched to construct a task subgraph, including: searching for attack semantic chains in the attack semantic graph based on the attack target; searching for constraints and implementation tools in the tool implementation graph based on the task model and attack semantic chains; searching for attack states in the environment and asset graph based on the task model to determine feasibility conditions; and constructing a task subgraph based on the attack semantic chains, constraints, implementation tools, and feasibility conditions.

[0009] Optionally, in the task subgraph, the attack path is queried according to the attack target to obtain candidate paths, including: starting from the attack target, querying the attack relationship in reverse step by step in the task subgraph and checking whether the attack relationship meets the preset conditions, wherein the attack relationship includes the attack status and attack tool; and determining the path that the attack relationship meets the preset conditions as the candidate path.

[0010] Optionally, detecting whether the attack relationship meets preset conditions includes: detecting whether the attack state is supported by the current environment assets, wherein the current environment assets include the target system version, permission level and network reachability; and monitoring whether the execution constraints of the attack tool match the environment conditions, wherein the environment conditions include the operating system, dependent components, running permissions and network ports.

[0011] Optionally, the score corresponding to the candidate path is calculated, including: calculating the success confidence, exposure risk and cost indicators corresponding to each of the multiple steps in the candidate path; calculating the path success power, path exposure risk and total path cost corresponding to the candidate path based on the success confidence, exposure risk and cost indicators corresponding to each of the multiple steps; and determining the score corresponding to the candidate path based on the path success power, path exposure risk and total path cost corresponding to the candidate path.

[0012] According to another aspect of the present invention, an attack path generation apparatus is also provided, comprising: an acquisition module for acquiring attack information, wherein the attack information includes an attack target, an attack object, a vulnerability, and an attack result; a first construction module for constructing a task model based on the attack information; a second construction module for constructing multiple collaborative knowledge graphs based on preset semantic anchors; a third construction module for retrieving multiple collaborative knowledge graphs according to the task model and constructing a task subgraph; a query module for querying attack paths in the task subgraph according to the attack target to obtain candidate paths; a calculation module for calculating the score corresponding to the candidate path; and a selection module for selecting candidate paths whose scores meet preset conditions as target attack paths.

[0013] According to another aspect of the present invention, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored program, wherein, when the program is running, the device where the non-volatile storage medium is located is controlled to execute any of the above-described attack path generation methods.

[0014] According to another aspect of the present invention, a computer device is also provided, the computer device including a processor, the processor being configured to run a program, wherein the program executes any of the above-described attack path generation methods during runtime.

[0015] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the method for generating any of the above-described attack paths.

[0016] In this embodiment of the invention, an attack path generation method is adopted. This method constructs an attack semantic graph, implements a multi-knowledge graph system that coordinates the tool graph with the environment and asset graphs, and achieves cross-graph entity alignment based on a unified semantic anchor point. Driven by the attack target, the attack relationship is queried backward level by level in the task subgraph, and feasibility gating is performed by combining environmental asset support and tool execution constraints. After generating candidate paths, their success confidence, exposure risk, and execution cost are calculated, and the best path is selected based on a comprehensive score. At the same time, during the runtime, observation events (such as alarms, logs, and rule hits) are continuously connected to dynamically update the consistency of path evidence, triggering branch switching or local repair. This achieves the goal of real-time linkage between the generated attack path and the real environment state, execution constraints, and observation feedback, thereby realizing the technical effects of attack path executability, verifiability, and adaptive repair capability. This solves the technical problem that existing AI attack path generation methods rely on static graphs, lack real-time environmental feedback and dynamic replanning capabilities, resulting in the generated attack paths being unable to respond to execution deviations, alarm triggers, or asset changes, lacking a closed-loop feedback mechanism, and unable to dynamically replan and adaptively repair. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0018] Figure 1 A hardware structure block diagram of a computer terminal for implementing an attack path generation method is shown.

[0019] Figure 2 This is a flowchart illustrating the attack path generation method provided in an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of the overall architecture provided by an optional embodiment of the present invention;

[0021] Figure 4 This is a schematic diagram of the multi-source data input, alignment, and missing mapping completion process provided by an optional embodiment of the present invention;

[0022] Figure 5 This is a schematic diagram of a hybrid retrieval and controlled generation process provided by an optional embodiment of the present invention;

[0023] Figure 6 This is a schematic diagram of the target-driven reverse expansion attack graph skeleton and self-healing loop provided by an optional embodiment of the present invention.

[0024] Figure 7 This is a schematic diagram of branch switching, local repair, or global replanning triggered by observation evidence and thresholds during runtime, provided by an optional embodiment of the present invention.

[0025] Figure 8 This is a structural block diagram of an attack path generation device provided according to an embodiment of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0029] "Semantic anchors" refer to standardized identifiers used for entity alignment across multiple knowledge graphs. These include unique identifiers recognized in industry or standard systems such as CVE-ID, CPE, ATT&CK Technique / Sub-technique ID, CWE-ID, and CAPEC-ID. Their function is to map entities (such as vulnerabilities, software versions, and attack techniques) scattered across different knowledge graphs, such as attack semantics, tool implementations, and environmental assets, to a unified reference semantic layer. This achieves semantic consistency and computability, ensuring that data from different sources are logically related and reasonable.

[0030] The "Implementation" in the "Tool Implementation Map" refers to the concretization of abstract attack techniques (such as ATT&CK sub-techniques) into executable attack artifacts or scripts, and the association with hard constraints such as the platform, permissions, dependent versions and network conditions required for their operation. It is a key bridge from tactical semantics to engineering implementation.

[0031] "Evidence anchors" refer to unique log patterns, alarm rules, or security event characteristics that correspond to specific attack steps and can be detected or observed in the target environment. They are used to quantify the likelihood of attack behavior being exposed in a real system. Their sources include SIEM rules, EDR monitoring items, network traffic signatures, etc., and they are the core basis for supporting path evidence consistency assessment and dynamic replanning.

[0032] "Feasibility Gating F(u)" refers to the binary judgment made on whether a single attack step can be bound and executed based on the actual asset status in the environment graph (such as operating system version, account permission level, network connectivity, and vulnerability existence). F(u)=1 indicates that the current environment meets all the constraints of the step and can be safely included in the candidate path. F(u)=0 means that it is directly eliminated, thus realizing path pruning with environment awareness in the generation stage.

[0033] The "task subgraph" refers to a local relational subgraph structure that is retrieved and aggregated from multiple knowledge graphs based on the attack target and constraints. It contains semantic links, implementation artifacts, environmental constraints, and evidence anchors. It is the direct operational space for generating candidate attack paths. Its construction process realizes unified modeling of semantic reasoning, feasibility verification, and evidence association. It is the structural foundation that supports closed-loop generation and dynamic adjustment.

[0034] The above terms are all core components of the technical solution of this invention. Although some of them are derived from general concepts in the security field, they are given specific structured definitions and collaborative usage methods in this invention, which are necessary for understanding the closed-loop mechanism and dynamic replanning capability of this solution.

[0035] According to an embodiment of the present invention, a method embodiment for generating an attack path is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing an attack path generation method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0037] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0038] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the attack path generation method in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the above-mentioned attack path generation method for the application. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0039] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0040] Figure 2 This is a flowchart illustrating the attack path generation method provided by an embodiment of the present invention, as shown below. Figure 2 As shown, the method includes the following steps:

[0041] Step S202: Obtain attack information, which includes the attack target, the target of the attack, the vulnerability, and the attack result.

[0042] In this step, the process of acquiring attack information aims to systematically collect structured content related to the attack. This attack information explicitly includes four core elements: attack target, attack object, vulnerability, and attack result. By identifying and extracting these four characteristics, this step ensures that the acquired information fully covers the intent of the attack (attack target), the target (attack object), the exploitable flaw (vulnerability), and the expected or actual state achieved (attack result), thus providing foundational data support for subsequent attack path analysis. Each element is directly collected as an independent and necessary component, without relying on any additional contextual inference or implementation methods, and is defined and acquired solely in literal terms.

[0043] Optionally, attack information can be obtained through natural language description input, structured predicate input, or a combination of both. The attack target is transformed into a computable target node in the task model, which is associated with one or more post-effect predicates used to trigger reverse path search in the attack semantic graph. The attack object is used to specify the scope of critical assets in the tested system, including components such as inference service nodes, model repositories, data processing services, orchestration modules, and access control modules. Vulnerability information and attack results correspond to the feasibility determination of the steps and the verification basis for achieving the target state, respectively.

[0044] Step S204: Construct a task model based on the attack information.

[0045] In this step, a task model is first constructed based on the attack information. This involves using the attack target and constraints as input, and defining the attack intent and its execution boundaries in a structured manner. The attack information, as the raw input, is parsed into explicit target predicates and limiting conditions, forming logical entities that can be recognized and processed by the system to drive subsequent graph retrieval and path generation. This task model does not depend on specific implementation methods; it establishes an abstract framework for expressing the attack intent solely through the attack information itself, serving as the starting point and constraint benchmark for the entire collaborative reasoning process.

[0046] Optionally, the target set G, constraint set C, and environmental and intelligence context B can be uniformly modeled into a task model. as follows:

[0047] ;

[0048] The target set G contains one or more target predicate nodes, the constraint set C contains one or more of the risk threshold ΘR, cost threshold ΘC and evidence consistency threshold ΘE, and the environment and intelligence background B contains one or more of the following: environment topology and asset list, account permission relationship, software and configuration fingerprint, vulnerability and risk signal library, security announcement and CTI report text, and detection rules and alarm types.

[0049] Optionally, the attack target can be in the form of natural language description or in the form of structured predicates; the constraint set can include one or more of the following: concealment requirements, time window limits, alarm categories that should not be triggered, budget and risk thresholds, etc. By encoding them as constraint predicate nodes and writing them into the graph, the task model can be computable and reasonable.

[0050] Optionally, the environment topology and asset inventory includes host / service / port information, connectivity relationships, network partitions, and access control configurations; account permission relationships include accounts, roles, permission inheritance, and trust relationships; software and configuration fingerprints include CPE / version information, configuration items, and exposure surfaces; the vulnerability and risk signal database includes fields such as CVSS, EPSS, and KEV; security bulletins and CTI report texts include bulletin content, APT analysis, and threat intelligence; and detection rules and alarm types include rule hit events, alarm categories, and monitoring coverage information.

[0051] Step S206: Construct multiple collaborative knowledge graphs based on preset semantic anchors.

[0052] In this step, multiple collaborative knowledge graphs are constructed based on preset semantic anchors. Semantic anchors serve as unified identifiers, establishing entity alignment relationships between different knowledge graphs to ensure that entities in each graph fall within the same semantic coordinate system, thereby achieving cross-graph collaborative expression. The multiple knowledge graphs respectively carry information from different dimensions, such as attack semantics, tool implementation, environmental constraints, and plan structure. Through the binding of semantic anchors, the graphs form a linked network without altering their own structures, supporting collaborative reasoning and consistency verification in subsequent steps.

[0053] Optionally, the preset semantic anchors include one or more of the following: CVE-ID, CWE-ID, CAPEC-ID, ATT&CK Technique / Sub-technique ID, CPE (vendor-product-version-configuration normalization key), asset / account / rule / event primary key, and STIX intelligence object identifier. Semantic anchors are used to construct a reference semantic layer, defining entity mapping and alignment relationships for each graph, ensuring that cross-graph entities fall within the same semantic coordinate system, achieving traceability, computability, and auditability.

[0054] The aforementioned anchor points can be categorized into four types based on knowledge domains: Vulnerabilities / Weaknesses / Attack Patterns: CVE-ID, CWE-ID, CAPEC-ID; Products and Impact Surfaces: CPE (Vendor-Product-Version-Configuration Normalization); Tactical Techniques: ATT&CK Technique / Sub-technique ID; Intelligence Objects: STIX Object Mapping and Export. Specifically, CVE-ID connects vulnerability information with attack techniques, CPE links software versions with affected assets, and ATT&CK ID unifies attack semantics and the semantic coordinates of implementation tools, ensuring that cross-source data is computable, traceable, and auditable under a unified ontology.

[0055] Optionally, each graph entity is aligned to the reference semantic layer using a mapping function. It uses preset semantic anchors to establish cross-graph mapping and alignment, and performs version statistics and quality inspection records on the graph.

[0056] Mapping function as follows:

[0057] ;

[0058] in For each set of atlas entities, This is a reference semantic layer entity set.

[0059] Optionally, multiple collaborative knowledge graphs can form a multi-knowledge graph set:

[0060] ;

[0061] in These are respectively the entity set, the relation set, and the attribute / constraint set; These are the semantic attack graph, the tool implementation graph, the environment and asset graph, and the plan graph.

[0062] Different graphs are linked through unified identifiers, mapping relationships, and alignment rules to form a connected knowledge network, which connects the attack semantic layer, the implementation artifact layer, the environmental constraint layer, and the planning structure layer.

[0063] Optionally, the number of graph categories in the multi-knowledge graph set is not limited, and graphs can be reduced or added according to the attack scenario. For example, a new "permission relationship graph" can be added to express role inheritance, delegation authorization and session token propagation chain, or a new "network policy graph" can be added to express security groups, ACLs, micro-segmentation rules and traffic whitelist constraints.

[0064] Step S208: Based on the task model, retrieve multiple collaborative knowledge graphs and construct a task subgraph.

[0065] In this step, a retrieval is first performed based on a multi-knowledge graph set. By querying the graph structure, attack semantics, implementation constraints, and environmental asset information related to the task objective are obtained. Combined with text semantic retrieval, relevant content in security announcements and threat intelligence is extracted to form a structured context. Subsequently, the retrieved semantic steps, implementation artifacts, environmental bindings, and evidence anchors are aligned and associated through a unified identification system to construct a local knowledge subgraph covering target-driven dependencies, executable conditions, and environmental constraints, which serves as the direct basis for generating candidate attack paths.

[0066] Step S210: In the task subgraph, query the attack path based on the attack target to obtain candidate paths.

[0067] In this step, a path query is first performed in the task subgraph based on the predetermined attack target to obtain a set of potential attack paths related to that target. The task subgraph, as a structured graph space carrying the attack plan, derives its nodes and edges from the alignment results of the attack semantic graph, tool implementation graph, and environment and asset graph, ensuring that the query scope is strictly limited to the constructed substructures with semantic associations and environmental constraint mappings. The path query process does not rely on external knowledge or unbound global graphs. Instead, it is based on existing entity relationships and dependency edges within the task subgraph, deducing backwards or forwards from the target predicate, extracting only candidate path fragments that conform to the topology and binding relationships within the subgraph. Each candidate path output is directly derived from the explicit connections and references between entities in the subgraph, without introducing steps not defined in the subgraph or unaligned entities.

[0068] Step S212: Calculate the score corresponding to the candidate path.

[0069] In this step, the score for each candidate path is calculated by quantitatively evaluating the feasibility, confidence in success, exposure risk, execution cost, and evidence consistency of each step within the path. These step-level indicators are then aggregated into a comprehensive path-level score. For each candidate path, the system calculates the confidence in success, exposure risk, execution cost, and evidence consistency support for each step based on its sequence of steps. The overall success probability of the path is then calculated through a product, the overall exposure risk through a complementary product, the total execution cost through summation, and the evidence consistency level through a weighted average. Finally, these four indicators are combined according to preset weights into a comprehensive scoring function, used to rank and optimize candidate paths. This scoring function is directly derived from the quantitative characteristics and relationships of each step within the path, without relying on any additional evaluation dimensions or external reference standards.

[0070] Step S214: Select candidate paths whose scores meet preset conditions as target attack paths.

[0071] In this step, candidate paths whose scores meet preset conditions are selected as target attack paths. This means that from the multiple candidate attack paths that have been generated, the comprehensive score results are used to filter and retain only the paths whose scores reach or exceed the preset threshold as the final target paths for attack assessment or simulation. This process does not involve re-analyzing the path structure, implementation method, or environmental constraints. It only completes the selection and confirmation of the path based on the comparison between the established score value and the preset conditions. Its direct effect is to compress the complex attack path space into a finite set that meets the score requirements, ensuring that subsequent operations only focus on paths with sufficient probability of success, low exposure risk, low execution cost, or high evidence consistency, thereby providing clear and actionable attack targets for attack and defense assessment.

[0072] Through the above steps, an automatic attack path generation and optimization method based on multi-knowledge graph collaborative reasoning for AI systems can be realized. This method first defines the target and constraints through structured attack information and constructs a task model as a search guide. Then, based on a unified semantic anchor, it integrates three types of knowledge graphs: attack semantics, tool implementation, and environmental assets, forming a knowledge foundation with semantic consistency and environmental verifiability. On this basis, it performs joint retrieval of multiple graphs according to the task model, dynamically constructs a task subgraph focused on the current attack target, and ensures that the generated path is strictly limited by real environmental constraints and technical implementation conditions. Subsequently, it reverse-engineers the attack chain in the task subgraph, generates logically consistent and environmentally feasible candidate paths, and selects the optimal attack path by comprehensively evaluating its success confidence, exposure risk, and execution cost. Thus, without human intervention, it completes end-to-end automated generation from high-level attack intent to an executable, scoreable, and selectable attack plan, significantly improving the accuracy, environmental adaptability, and decision-making efficiency of attack path generation.

[0073] Figure 3 This is a schematic diagram of the overall architecture provided by an optional embodiment of the present invention, such as... Figure 3 As shown, this invention uses multi-knowledge graph collaboration as its core organizational method, establishes a unified semantic anchor point and cross-graph alignment mechanism, constructs an evidence situation variable E as a unified intermediate variable, and realizes a closed-loop strategy generation framework of retrieval enhancement generation—environmental constraint verification—evidence consistency assessment—dynamic replanning. This framework is designed for AI system attack and defense assessment scenarios, introducing structured constraints and consistency verification in the generation stage to prevent candidate plans from deviating from the real environment and verifiable evidence. The process begins with "task input," with the input format being... ,in Indicate the goal, Indicates constraints. The background is then introduced. The process then proceeds to the "Task Parsing" stage, where target predicates and constraints are extracted. Next comes "Hybrid Retrieval," combining graph retrieval (Rgraph) and vector retrieval (Rvec) to obtain query results. Then, "Controlled Generation" is implemented to generate a structured plan draft. Following this, "Constraint Validation" checks aspects such as version, permissions, dependencies, and CPE (Common Platform Enumeration). After passing validation, the process proceeds to "Scoring and Optimization," based on an evaluation function. The process involves scoring and selecting the Top-K best results. Finally, a "plan map / evidence matching" result is output as the final outcome of the entire process. This workflow demonstrates a series of processing steps from task input to output, emphasizing the synergistic effect of multiple knowledge graphs.

[0074] As an optional embodiment, the multiple collaborative knowledge graphs include an attack semantic graph, a tool implementation graph, and an environment and asset graph, wherein the attack semantic graph is a graph describing attack logic, the tool implementation graph is a graph describing attack tools and constraints, and the environment and asset graph is a graph describing attack states.

[0075] In this embodiment, multiple collaborative knowledge graphs are constructed, including an attack semantic graph, a tool implementation graph, and an environment and asset graph. The attack semantic graph is used to depict the logical dependencies between attack steps, the tool implementation graph is used to map the availability of attack tools and their execution constraints, and the environment and asset graph is used to reflect the state changes of the target system in real time. The three graphs achieve semantic alignment and collaborative retrieval based on preset semantic anchors. This ensures that the construction of the task subgraph is not only based on the logical deduction of the attack target, but also comprehensively considers the executability of tools and the real constraints of the environment. As a result, attack paths that are out of touch with reality or infeasible are automatically filtered during the candidate path generation process, and state awareness and feedback are provided for subsequent dynamic replanning. This effectively solves the problems of traditional methods, such as paths that are out of touch with reality and cannot respond to alarms or asset changes due to the single graph structure and lack of hierarchical modeling. This achieves highly reliable generation and adaptive closed-loop optimization of attack paths.

[0076] In this embodiment, the attack semantic graph is used to express the dependencies between tactics, techniques, sub-techniques, and steps, characterize the attack stages and causal chains, and provide a semantic path from high-level targets to technical steps; the tool implementation graph is used to express the mapping from techniques / sub-techniques to implementation artifacts and their constraints and evidence anchors, realizing the executable binding from semantics to implementation; the environment and asset graph is used to express the AI ​​system topology, hosts, service ports, account permissions, software and vulnerabilities, configuration status, defense measures and monitoring points, serving as a basis for feasibility determination.

[0077] Optionally, multiple collaborative knowledge graphs generate a plan graph at runtime to carry the candidate attack plans generated by the system. The plan is represented by a graph structure that includes sequential / parallel / alternative branches. Each step is bound to semantic references, implementation artifacts, and environmental prerequisites, providing structural space for dynamic adjustments. Multiple collaborative knowledge graphs are interconnected through unified identifiers, mapping relationships, and alignment rules to form a linked knowledge network, connecting the attack semantic layer, implementation artifact layer, environmental constraint layer, and plan structure layer.

[0078] Optionally, entities in the planning graph must include at least one of Plan, PlanStep, Branch, and Binding, and relationships must include at least one of contains, next, alternative, binds, and uses. Example fields are as follows:

[0079] PlanStep{step_id, sem_ref, tool_ref, env_binding, preconditions, evidence_anchors[]}.

[0080] Optionally, the attack semantic graph contains the logical dependencies of the attack stages. These logical dependencies are expressed through a causal structure of "preconditions - actions - consequences". Each action corresponds to a deducible attack behavior unit. This behavior unit exists in the graph as a step template. Its definition includes a set of preconditions that must be met, the system state changes that occur after execution, and observable evidence that can be associated, which is used to support the hierarchical decomposition from abstract attack targets to verifiable operations.

[0081] Optionally, the attack semantic graph includes at least step templates, technology or sub-technology entities, and dependency edges, wherein the dependency edges include at least one or more of precedes, requirements, and achievements; and candidate plan skeletons are generated on the attack semantic graph based on target-driven reverse expansion. Optionally, the entities also include one or more of Tactic, StepTemplate, and Predicate.

[0082] The field example is as follows:

[0083] Technique{id, tactic, name}

[0084] SubTechnique{id, parent_id}

[0085] StepTemplate{sid, preconditions[], effects[], evidence_hints[]}

[0086] In the attack semantic graph, Technique / Sub-technique is used to express the attack semantic organization and dependency structure; sub-techniques are used for more refined step decomposition and link reasoning, without promising specific implementation methods.

[0087] Optionally, the tool implementation graph maps a technology or sub-technology to one or more implementation artifacts, and associates at least one execution constraint and at least one evidence anchor with each implementation; wherein the constraint includes at least one or more of platform, permission, dependency, version range, and network conditions, and the evidence anchor includes at least one or more of source type, matching pattern, and rule reference.

[0088] Optionally, the entities in the tool implementation graph must include at least one of Implementation, Constraint, EvidenceAnchor, and Artifact, and the relationships must include at least one of implements, hasConstraint, emitsEvidence, and requiresArtifact. Example fields are as follows:

[0089] Implementation{impl_id,type,input_schema,output_schema,side_effect_level}

[0090] Constraint{os,privilege,dependency,version_range,network_condition}

[0091] EvidenceAnchor{anchor_id,source_type,pattern,rule_ref}

[0092] In the tool implementation graph, Sub-technique is mapped to multiple Implementation nodes, which carry strong constraints such as platform / permission / dependency / version range and explicitly associate evidence anchors, realizing the implementation path of multiple implementation candidates corresponding to the same semantic technology, filtering by environment and selecting the best implementation based on evidence constraints.

[0093] Optionally, the environment and asset graph includes at least one or more of the following: topology reachability, asset and service exposure surfaces, account permission relationships, software product / version information, vulnerability information, and defense control or monitoring coverage information. A feasibility gating function F(u) is constructed, and feasibility gating is established for candidate steps based on the aforementioned environmental facts.

[0094] F(u)∈{0,1};

[0095] in, This indicates that step u satisfies the environmental reachability, constraint satisfaction, and binding closure conditions. This indicates that the step is not feasible and triggers pruning or alternative binding.

[0096] Optionally, the entities in the environment and asset graph should include at least one of Host, Service, Account, Permission, Software, Vuln, and Control, and the relationships should include at least one of runs, connects / reachable, grants, hasSoftware, affectedBy, and coveredBy. Example fields are as follows:

[0097] Software{sw_id,cpe,version}

[0098] Vuln{cve_id,cvss,epss,kev,affected_cpe[]}

[0099] Control{control_id,type,coverage}

[0100] Optionally, the preset semantic anchors include at least one or more of the following: CVE-ID, CWE-ID, CAPEC-ID, ATT&CK Technique / Sub-technique ID, CPE (Product / Version Normalization Key), and asset / account / rule / event primary key. Alignment with intelligence objects (such as STIX) is supported to ensure that extracted triples are stored in the database and computable under schema constraints. A reference semantic layer is defined. Define entity mappings for each graph. This allows cross-graph entities to fall within the same semantic coordinate system, enabling traceability, computation, and auditability.

[0101] Optionally, the evidence situation variable E is a unified intermediate variable that uniformly encodes the success confidence, exposure risk, execution cost and evidence consistency at the step level and path level, and iteratively updates it during the generation and replanning process;

[0102] ;

[0103] Where u represents the planning step, and π represents the candidate planning path. For the set of planned steps; For the set of candidate plan paths, These are the success confidence level, exposure risk, execution cost, and evidence consistency of step u. These are the overall success confidence, cumulative exposure risk, total execution cost, and overall evidence consistency of the candidate path π.

[0104] Optionally, the construction process of multiple collaborative knowledge graphs includes: inputting structured and unstructured data into the graph, aligning, completing, and quality checking. Structured data input: Synchronizing structured data such as CVE / CPE / CVSS / EPSS / KEV, CWE, CAPEC, and ATT&CK from sources such as NVD / CISA / FIRST / MITRE, multi-source data is input into the database according to the graph's function, and cross-source alignment is achieved through a unified anchor point.

[0105] Figure 4 This is a schematic diagram of the multi-source data input, alignment, and missing mapping completion process provided by an optional embodiment of the present invention, which illustrates the multi-source data input, alignment, and missing mapping completion process. Figure 4 This demonstrates the construction and processing flow of a multi-source information security knowledge graph. The left side shows four main data input sources: a structured library (including standardized vulnerability and threat information such as CVE, CWE, CAPEC, ATT&CK, CPE, CVSS, EPSS, and KEV), unstructured text (such as security announcements, CTI reports, and APT reports), observation data (logs, alerts, rule hits), and environmental asset information (topology, hosts, services, accounts, and configurations). This data first undergoes an information extraction (IE) stage, using techniques such as Named Entity Recognition (NER), Relation Extraction (RE), and event structure extraction to transform unstructured content into structured information. It then enters the entity linking and disambiguation stage, using rule candidate and vector nearest neighbor methods to associate extracted entities with existing knowledge and eliminate ambiguity. The processed data is then distributed into different knowledge graph sub-libraries, including… (Semantic Graph) (Tool Atlas) and (Environmental graph). Next, completion and quality control are performed. The graph is improved through learning-based edge completion and rule deduction, and consistency checks and version statistics are conducted to ensure quality. Finally, by unifying anchor point alignment, using standard primary keys such as CVE, CPE, and ATT&CK as benchmarks, the integration and alignment of multiple graphs are achieved.

[0106] The processing of unstructured text employs a three-stage IE+alignment pipeline: the first step is security domain NER, identifying entities such as tools, file objects, paths, configuration parameters, protocols / ports, accounts, organizations, and malware; the second step is relation extraction (RE), extracting relations such as uses / modifies / targets / effects and mapping them to ontology predicates; the third step is event structure extraction, extracting the "action-participant-object-result" event structure and mapping it to patterns such as StepTemplate / Predicate / EvidenceAnchor. Entity linking and disambiguation construct candidate sets based on name, contextual relationships, adjacent entities, time, and version information, employing rule alignment and vector nearest neighbor fusion to achieve merging of entities with the same name and binding of unified identifiers across sources.

[0107] For missing edges commonly found in real-world data, a dual-channel approach is used for completion: a statistical learning chain vectorizes the CVE description and predicts possible CWE / Technique candidates; a symbolic rule chain infers new triples using deductive rules and verifies consistency. Examples of rules include: (a) CPE adaptation gating; (b) platform constraints: if Implementation.os ≠ Host.os, the binding is invalid; (c) permission constraints: if Implementation.privilege > Account.privilege_level, the binding is invalid; (d) dependency closure: if the Predicate required by a step cannot be satisfied by environmental facts or preceding effects, a conditional step is triggered or a branch is switched.

[0108] As an optional implementation, based on the task model, multiple collaborative knowledge graphs are retrieved to construct a task subgraph, including: retrieving attack semantic chains in the attack semantic graph based on the attack target; retrieving in the tool implementation graph based on the task model and attack semantic chains to determine constraints and implementation tools; retrieving attack states in the environment and asset graph based on the task model to determine feasibility conditions; and constructing a task subgraph based on the attack semantic chains, constraints, implementation tools, and feasibility conditions.

[0109] In this embodiment, a structured attack semantic chain is retrieved from the attack semantic graph based on the attack target to clarify the logical path and stage dependencies of the attack. Then, by combining the task model with the semantic chain, executable attack tools and their corresponding constraints are accurately matched in the tool implementation graph to ensure that the attack steps are technically feasible. At the same time, based on the task model, the current network asset status and security protection status are dynamically retrieved in the environment and asset graph to evaluate the environmental adaptability and feasibility of the attack path. Finally, the attack semantic chain, implementation tools, constraints, and environmental feasibility conditions are structurally integrated to construct a task subgraph with a triple verification mechanism of semantic logic closed loop, tool execution constraints, and environmental status verification. This effectively overcomes the defect of path generation being divorced from actual execution conditions in traditional methods, ensuring that candidate paths are semantically traceable, tool-based, and environmentally compliant, significantly improving the practical feasibility and dynamic adaptability of attack paths.

[0110] Optionally, a hybrid retrieval method is used, combining graph structure retrieval results with text semantic retrieval results as a structured context to drive controlled generation. The hybrid retrieval results satisfy the following:

[0111] ;

[0112] in Obtained through graph traversal, path lookup, or constraint lookup, it returns structured fragments of semantic links, implementation constraints, and environmental facts. The structured context input generator (large model, rule engine or combination thereof) is used to retrieve vector similarity from announcement, CTI or security report texts, and returns announcement / CTI text fragments and their evidence anchor descriptions; and outputs a structured plan draft.

[0113] in, For retrieval queries, As a source of knowledge for graph structures, It is a collection of text corpora.

[0114] Optionally, the mixed search results satisfy:

[0115] ;

[0116] Among them, from Obtain the semantic step chain, dependency predicates, and causal relationships related to the target; from Obtain candidate Implementations, constraints, and EvidenceAnchors; from Obtain the set of bindable assets, connectivity reachability, and permission facts.

[0117] Generate candidate plan map It also writes binding information such as sem_ref / tool_ref / env_binding / evidence_anchors for each step.

[0118] Figure 5 This is a schematic diagram of a hybrid retrieval and controlled generation process provided by an optional embodiment of the present invention, such as... Figure 5 As shown, for task query Perform a mixed search And organized into a structured context: where Returning to the semantic link, implementing the structured fragments of constraints and environmental facts, Return the notification / CTI text fragment and its evidence anchor description. Obtain the semantic step chain, dependency predicates, and causal relationships related to the target from the attack semantic graph; obtain candidate implementations, constraints, and... The system retrieves the set of bindable assets, connectivity, reachability, and permission facts from the environment and asset graph. The large language model outputs a structured draft plan. (Step sequence, branch structure, binding placeholders), and then the system performs constraint verification, self-repair and scoring to form an executable candidate plan set.

[0119] The flowchart begins with "Constructing query q," inputting the target predicate and constraints, followed by the "Hybrid Retrieval" stage, which integrates the results of graph retrieval and vector retrieval. The graph retrieval section focuses on mining paths, dependencies, constraints, and reachability relationships. The retrieval results are then processed into "Structured Context Assembly," forming computable fragments containing constraints, evidence, and binding candidates. Next, a structured draft plan is generated and undergoes a "Constraint Validation" step to evaluate F(u) and consistency. Validated plans are added to the "Candidate Plan Set," where the Top-K plans are selected. If validation fails or evidence is insufficient, a "Re-retrieval and Repair" step is triggered, re-injecting feedback information into the hybrid retrieval process to achieve iterative optimization until a high-quality plan satisfying the constraints is generated.

[0120] As an optional embodiment, in the task subgraph, the attack path is queried according to the attack target to obtain candidate paths, including: starting from the attack target, querying the attack relationship in reverse step by step in the task subgraph and detecting whether the attack relationship meets the preset conditions, wherein the attack relationship includes the attack status and attack tool; and determining the path that the attack relationship meets the preset conditions as the candidate path.

[0121] In this embodiment, starting from the attack target, the attack relationship is queried backward level by level in the task subgraph. The attack state and attack tool contained in each level of attack relationship are verified for their collaborative effectiveness. Only when the attack state can be logically deduced from the preceding steps and the corresponding attack tool has the preconditions to act on the state is the path branch retained. In this way, invalid paths that do not match the attack state and tool, have broken logical chains, or are not feasible to execute are actively eliminated during the path generation process. This ensures that the selected candidate paths all meet the causal coherence of the attack behavior and the tool adaptability. This solves the problem of insufficient path rationality and high execution failure rate caused by the lack of state-tool joint constraint mechanism in traditional methods. Finally, the attack path achieves structural self-consistency and high feasibility at the execution level, improving the accuracy and practical value of attack path generation.

[0122] Specifically, the candidate task subgraph generation adopts a target-driven reverse expansion: an attack graph skeleton is generated on the task subgraph and gradually expanded; during the expansion process, environmental facts, implementation artifacts and evidence anchors are bound; pruning and consistency checks are performed (unreachable, condition not met, version mismatch, permission not closed, implementation constraint not satisfied, etc.); for branches with gaps or insufficient evidence, a self-repairing loop (directed re-search + structural repair) is triggered until the output threshold is met or an unreachable proof is given.

[0123] Figure 6 This is a schematic diagram of the target-driven reverse expansion attack graph skeleton and self-healing loop provided by an optional embodiment of the present invention, such as... Figure 6 As shown, the attack graph skeleton is formed by backtracking layer by layer on the task subgraph according to the relationship of "post-effect → pre-condition". During the expansion process, each step is bound to environmental facts (connectivity, vulnerability existence, permission chain closure, etc.), available implementation artifacts (from the tool implementation graph), and evidence anchors (observable event patterns). Environmental constraints and policy constraints are applied to the branches for pruning to ensure that the candidate plan is executable, interpretable, and verifiable.

[0124] This flowchart begins with "setting the goal predicate," clearly defining the objective (Goal) to be achieved. It then proceeds to the "reverse expansion" phase, deriving the preconditions from the effect (effect->precondition) to progressively construct the steps required to achieve the goal. Next, a "binding" operation is performed, associating the derived conditions with specific semantics (sem), tools (tool), environments (env), and anchors, mapping abstract conditions to concrete resources. Following this, the "pruning and consistency verification" phase checks for unreachable paths, mismatched constraints, incomplete permission closures, or evidence gaps, eliminating invalid branches. If defects are found during verification, a "self-repair" mechanism is triggered, correcting the plan by replacing the implementation method, inserting complete conditions, adding branches, or re-searching. The corrected plan re-enters the process until it passes verification. Finally, a "plan skeleton or candidate plan diagram" is output as an executable plan. The entire process embodies iterative optimization and adaptive plan construction logic.

[0125] Optionally, on the task subgraph, a backward expansion is performed starting from the target predicate to generate a "state-action-state" plan structure; each step is explicitly bound: sem_ref∈ (Semantic steps / technical references), tool_ref∈ (Implement artifact referencing), env_binding∈ (Environment entity binding), evidence_anchors (Set of evidence anchors).

[0126] As an optional embodiment, detecting whether the attack relationship meets preset conditions includes: detecting whether the attack state is supported by the current environment assets, wherein the current environment assets include the target system version, permission level and network reachability; and monitoring whether the execution constraints of the attack tool match the environment conditions, wherein the environment conditions include the operating system, dependent components, running permissions and network ports.

[0127] In this embodiment, starting from the attack target, when querying attack relationships in reverse order in the task subgraph, the attack state and attack tool in each attack relationship are checked for environmental compatibility: First, it is checked whether the attack state is supported by the current environment assets, which include the target system version, permission level, and network reachability, to ensure that the attack state has the prerequisites for triggering in the real network environment; at the same time, it is monitored whether the execution constraints of the attack tool match the environmental conditions, which include the operating system type, dependent component version, running permission level, and network port open status, to verify whether the attack tool can be successfully deployed and executed in the target environment; if any detection item is not satisfied, the attack relationship is determined to be inconsistent with the preset conditions and is eliminated, and only the path where the attack state is fully compatible with the environment assets and the attack tool is precisely matched with the environment conditions is retained as the candidate path, thereby effectively avoiding the generation of unexecutable paths due to deviation from the real asset configuration and running constraints, significantly improving the realistic feasibility and execution success rate of the attack path, and finally achieving closed-loop adaptation and dynamic self-consistency between the attack path generation process and the actual network environment.

[0128] Optionally, the feasibility gating function F(u) is used to calculate the appropriate gating function g(v,x) based on the CPE of the environment software and the scope of vulnerability impact, and is then applied to the environment and asset map. Add the affectedBy associated edge:

[0129] ;

[0130] in Indicates a vulnerable node or vulnerable instance. This represents instances of software, components, or assets in the environment. The standardized identifier of the software platform corresponding to asset instance x. The representative will With vulnerabilities The criteria for matching the affected platform range.

[0131] Optionally, consistency checks are performed on the platform, permissions, and dependency constraints of the Implementation with the actual environment (e.g., the satisfaction relationship between Implementation.os and Host.os, and between Implementation.privilege and Account.privilege_level) to form step-level feasibility gating.

[0132] ;

[0133] Where F(u)=1 indicates that step u is bindable and executable under the current environment and constraints, otherwise F(u)=0.

[0134] Optionally, consistency verification includes: reachability of preconditions, satisfaction of dependency order, semantic matching of platform / tool / asset, satisfaction of implementation constraints, and evidence anchors for key steps. When gaps or insufficient evidence are found, targeted re-search and structural repair are triggered: replacing implementation artifacts, inserting intermediate conditional steps, introducing alternative branches, and adjusting parameters and constraints until the threshold is met or an unreachable proof is output.

[0135] As an optional embodiment, calculating the score corresponding to the candidate path includes: calculating the success confidence, exposure risk, and cost indicators corresponding to each of the multiple steps in the candidate path; calculating the path success power, path exposure risk, and total path cost corresponding to the candidate path based on the success confidence, exposure risk, and cost indicators corresponding to each of the multiple steps; and determining the score corresponding to the candidate path based on the path success power, path exposure risk, and total path cost corresponding to the candidate path.

[0136] Optionally, for candidate paths The calculation includes at least two or more of the following indicators: confidence in success, risk of exposure, cost of execution, and consistency of evidence. A comprehensive scoring function J(π) is constructed for ranking and Top-K selection.

[0137] In this embodiment, by acquiring attack information including the attack target, attack object, vulnerability, and attack result, a task model is constructed and multiple collaborative knowledge graphs are linked based on semantic anchors to form a task subgraph that accurately reflects the attack context, thereby querying candidate paths. On this basis, the success confidence, exposure risk, and execution cost of each attack step in the candidate path are quantified to achieve a multi-dimensional performance characterization of the attack behavior at the micro-step level. Furthermore, these step-level indicators are aggregated and calculated to obtain three key path-level indicators: overall success power, exposure risk, and total cost, forming a structured representation of the comprehensive performance of the attack path. Finally, based on the synergistic relationship between the path success power, path exposure risk, and path total cost, the candidate path score is determined by comprehensive weighting. This allows the scoring mechanism to directly reflect the dynamic trade-off between success rate, concealment, and resource consumption of the attack path, thereby overcoming the one-sidedness of path selection caused by traditional methods relying on only a single or fuzzy scoring standard. This enables a refined evaluation and selection of the feasibility, security, and cost-effectiveness of multiple candidate paths in a real-world environment, significantly improving the intelligence, adaptability, and practical executability of attack path generation.

[0138] Optionally, the step-level indicators for each step u are calculated as follows: (1) Feasibility gating is jointly determined by CPE matching, platform / permission / dependency closure, and connectivity reachability; (2) Success confidence (risk signal + fit); (3) Exposure risk (monitoring coverage + action noise); (4) Execution cost; (5) Evidence consistency support (anchor matching degree):

[0139] Let A(u) be the set of step anchor points, and O be the set of observed events. For each step u:

[0140] 1. Feasibility Gating:

[0141] ;

[0142] The determination is made jointly by CPE matching, platform / permission / dependency closure, and connectivity reachability.

[0143] 2. Successful confidence (risk signal + fit):

[0144] ;

[0145] in, Indicates the reference bias term. The weighting coefficient for EPSS risk signals. For CVSS risk signal weighting coefficients, For KEV risk signal weighting coefficients, For the fit weighting coefficient, This represents the feasibility gating factor for step u. Represents the normalized mapping function. , , , These represent the EPSS (ExploitPrediction Scoring System) score, CVSS (Common Vulnerability Scoring System) score, known in-the-wild utilization indicator, and the fitness index of step u on the environmental object x, respectively.

[0146] 3. Exposure risks (monitoring coverage + motion noise):

[0147] ;

[0148] in For the set of monitoring points associated with step u, Let j represent the set of monitoring points. Any monitoring point or protection control unit in the system, This represents the single-point exposure probability of step u relative to the monitoring point or protective control j. - These represent the baseline bias term, monitoring coverage weighting coefficient, and motion noise weighting coefficient, respectively. Represents the normalized mapping function. The monitoring coverage index representing the monitoring point or protection control j, The action noise index represents step u.

[0149] 4. Execution cost:

[0150] ;

[0151] in, These represent the time cost weighting coefficient, resource consumption weighting coefficient, and side effect cost weighting coefficient, respectively. These represent execution time metrics, resource consumption metrics, and side effect metrics, respectively.

[0152] 5. Evidence consistency support (anchor point matching degree):

[0153] ;

[0154] Where A(u) is the set of step anchor points, and O is the set of observed events. The weighting coefficient for evidence anchor point a.

[0155] Optionally, for each candidate path π, calculate the success confidence, exposure risk, and cost metrics:

[0156] ;

[0157] in, These are the t-th steps in the candidate path π. Step-level success confidence, step-level exposure risk value, and step-level execution cost value.

[0158] Optionally, the support of the steps and the consistency of the path are calculated based on the matching relationship between the set of evidence anchors and the set of observed events. The set of observed events includes at least one or more of log events, alarm events, and rule hit events. When any of the triggering conditions of evidence consistency being lower than the threshold, step infeasibility, or risk / cost exceeding the limit are met, branch switching, local patching, or replanning is performed.

[0159] Specifically, the support of the access observation event set O is calculated, and the path consistency is evaluated.

[0160] Optionally, the formula for calculating step support is:

[0161] ;

[0162] Alternatively, the formula for consistency of evidence is as follows:

[0163] ;

[0164] Where A(u) is the set of step anchor points, and O is the set of observed events. These are the weighting coefficients. The path aggregation weight coefficients for the t-th step in candidate path π. For the t-th step in candidate path π Step support.

[0165] Optionally, the comprehensive scoring function is used for Top-K selection, and the path-level indicators for candidate path π are calculated as follows: path success confidence is the composite of success confidences at each step; path exposure risk is the sum of exposure risks at each step; total path cost is the accumulation of costs at each step; evidence consistency E(π); comprehensive scoring function:

[0166] ;

[0167] in The impact function is based on the value of key assets and the advancement of objectives, and can be calculated by matching the criticality of the environment and asset map with the objective predicate. These are the path success confidence score, path evidence consistency score, path exposure risk score, and total execution value of candidate path π, respectively. These are the path success confidence weight coefficient, evidence consistency weight coefficient, path exposure risk weight coefficient, total path cost weight coefficient, and influence function weight coefficient, respectively.

[0168] Optionally, when the candidate path space exceeds a preset size threshold, combinatorial optimization or global search is used to iteratively optimize the candidates. The combinatorial optimization or global search is guided by a comprehensive scoring function J(π) or an equivalent objective. An auditable plan graph structure and cross-graph reference chains are output, where each reference chain includes at least semantic references, implementation artifact references, and environment binding references. During multiple iterations, candidate convergence is guided by pheromone updates and heuristics, resulting in the output of one or more plans with better comprehensive indicators.

[0169] Optionally, when the candidate size is too large, combinatorial optimization or global search is used to iteratively optimize the candidates, including:

[0170] Heuristics introduce consistency of evidence:

[0171] ;

[0172] in, These are the success confidence index, evidence consistency index, exposure risk index, and execution cost index for candidate edges, candidate steps, or candidate transition units e, respectively. It is a smoothing constant. These are the risk adjustment coefficient, cost adjustment coefficient, and baseline adjustment coefficient, respectively.

[0173] Selection probability:

[0174] ;

[0175] in These are the pheromone intensity term and heuristic intensity term for candidate unit e, respectively.

[0176] in, The current pheromone value on candidate unit e. The pheromone influence index is used to adjust the strength of the role of pheromones in selection probability.

[0177] in, The heuristic value for candidate unit e, This is the heuristic influence index, used to adjust the strength of the heuristic information's role in the selection probability.

[0178] Pheromones Update:

[0179] ;

[0180] in, The pheromone value of candidate unit e. The pheromone evaporation coefficient, For the preferred set of paths, This is the pheromone increment coefficient. The overall score for candidate path π. It is a monotonically increasing function.

[0181] Optionally, combinatorial optimization or global search employs ant colony optimization (ACO).

[0182] Figure 7 This is a schematic diagram illustrating runtime branch switching, local patching, or global replanning based on observational evidence and thresholds, according to an optional embodiment of the present invention. Figure 7 As shown, the attack graph skeleton is formed by backtracking layer by layer on the task subgraph according to the relationship of "post-effect → pre-condition". During the expansion process, each step is bound to environmental facts (connectivity, vulnerability existence, permission chain closure, etc.), available implementation artifacts (from the tool implementation graph), and evidence anchors (observable event patterns). Environmental constraints and policy constraints are applied to the branches for pruning to ensure that the candidate plan is executable, interpretable, and verifiable.

[0183] This flowchart comprises six main steps and their decision branches. The process begins with "1. Planning," generating candidate plans; then it proceeds to "2. Verification," determining whether the plan meets the constraints. If verification passes, it proceeds to "3. Execution," advancing according to the plan; if it fails, it jumps directly to "6. Repair / Replanning." After execution, it proceeds to "4. Monitoring," connecting observation data O to evaluate the execution status in real time. If monitoring reveals inconsistent, missing, or conflicting evidence, it makes a judgment based on the following conditions: if E(π) < ΘE (i.e., the plan's effect is lower than the expected threshold), it proceeds to "5. Switching Branches," adjusting the execution path; if F(u) = 0 or the risk / cost exceeds the limit (i.e., the plan's utility is zero or exceeds the tolerance range), it proceeds to "6. Repair / Replanning," revising or regenerating the plan. The results of repair / replanning can be fed back to the planning or verification stages, forming a closed-loop optimization to ensure continuous adaptation to environmental changes and constraint requirements.

[0184] Optionally, during runtime, continuous input of observed events such as alarms, logs, and rule hits forms O, iteratively updating the step support and path consistency E(π). When any of the following triggering conditions are met, branch switching, partial patching, or returning to the retrieval generation stage for replanning is executed: the step is infeasible, i.e., F(u) = 0; evidence consistency is insufficient, i.e., E(π) < ΘE; risk or cost exceeds the limit, i.e. Replanning can reuse alternative branches and structured bindings from existing planning graphs, and if necessary, return to the hybrid retrieval and controlled generation phase to reconstruct the task subgraph and generate a new set of candidate plans.

[0185] Optionally, the output of the method of the present invention includes: a candidate attack plan / attack graph (step sequence, dependencies, branches, constraint satisfaction); step-level and path-level scoring indicators (success confidence, risk, cost, evidence consistency, and comprehensive score); evidence anchor matching records (associations from observed events to step anchors); and cross-graph reference chains (semantic reference—implementation artifact—environment binding—evidence anchor), for audit tracing and reproduction. Simultaneously, verified feasible bindings, constraint satisfaction statistics, and evidence anchor matching statistics are written back to the tool implementation graph and plan graph for subsequent iterative optimization and continuous knowledge evolution.

[0186] The following uses the authorization attack and defense assessment scenario of an enterprise's internal AI system as an example to fully describe the specific implementation of the present invention.

[0187] The tested object is the enterprise's internal AI inference service system, which includes components such as inference service nodes, model warehouse, data processing service, orchestration and permission management modules. The method inputs include: (1) task objectives and constraint set: risk threshold ΘR, cost threshold ΘC, evidence consistency threshold ΘE, etc.; (2) environment topology and asset list: host / service / port, connectivity relationship, network partition and access control; (3) account permission relationship: account, role, permission inheritance and trust relationship; (4) software and configuration fingerprint: CPE / version, configuration items and exposure surface; (5) vulnerability and risk signal library: including CVSS, EPSS, KEV and other fields; (6) security announcement and CTI report text: announcement, APT analysis and threat intelligence content; (7) detection rules and alarm types: rule hit events, alarm categories and monitoring coverage information.

[0188] The scenario is as follows: A company has deployed an AI model service system, including servers providing model inference, pipeline components for data processing, and a backend operation and maintenance management module. The red team's evaluation objective is to obtain the model parameter files on a critical server within this system while minimizing detection. Constraints include avoiding triggering security monitoring alerts as much as possible and completing the task within a limited time window (e.g., 24 hours).

[0189] The first step is task analysis: The red team inputs the attack target description "obtain confidential model files from the model server to avoid detection," and provides the constraint "do not trigger IDS alerts, preferably complete within 24 hours." The system parses the input through steps S202 and S204, forming the target node "obtain file <model file>", and generates constraint predicates (such as "concealment = True" and "time limit = 24h"), while recording the target server identifier and related asset scope in the graph.

[0190] The second step, knowledge graph construction and alignment, involves incorporating, aligning, completing, and quality-checking structured and unstructured data into the graph, forming a collaborative foundation for the four graphs. Structured data such as CVE / CPE / CVSS / EPSS / KEV, CWE, CAPEC, and ATT&CK are synchronized from sources like NVD / CISA / FIRST / MITRE; NER / RE / SRL are performed on security announcements, CTI reports, and APT analysis texts, mapping them to the ontology schema to complete entity linking and disambiguation; missing relationships such as CVE→CWE and CVE→ATT&CK are completed using a dual-channel approach of "embedded classification + logical rules"; graph structure analysis is used to evaluate structural effectiveness, and versioned statistical records are maintained to support auditing and reproducibility. Cross-graph mapping and alignment are established using unified anchor points (CVE, CPE, ATT&CK Technique / Sub-technique, asset / account / rule / event primary keys, etc.), and versioned statistical and quality-check records are maintained for the graphs.

[0191] The third step is cross-graph search and alignment: Focusing on the goal of "obtaining model files," the system searches the attack semantic graph for path segments that can achieve the goal. The typical logic is: first, gain access to the target server, then locate and read the model files. The semantic graph shows that gaining access can be achieved through steps such as "initial intrusion (e.g., phishing into the operations and maintenance terminal) → lateral movement to the model server → privilege escalation." Based on this, the system further searches the tool implementation graph to obtain tool templates, implementation artifacts, and applicable conditions (e.g., platform / permissions / versions / dependency constraints) corresponding to semantic steps such as "phishing into the operations and maintenance terminal," "lateral movement," and "privilege escalation." Simultaneously, the system queries the environment and asset graph for feasibility verification: for example, environmental facts indicate that the operations and maintenance terminal and the model server are in the same intranet domain, and the terminal has VPN access; the model server has an unpatched privilege escalation vulnerability CVE-2025-12345 and is running an older operating system; the operations and maintenance terminal administrator commonly uses a certain office software, which can be used as a phishing entry point. The system uses a unified identifier and entity mapping alignment mechanism to associate the same object from different graphs as a consistent semantic entity (for example, to uniformly align the corresponding nodes of CVE-2025-12345 in each graph), forming a task subgraph oriented towards the task.

[0192] The fourth step is to generate candidate plans and write them into the plan graph: The system assembles candidate attack paths on the task subgraph and generates a set of candidate plans. Example candidate plans include: Path 1: Phishing for the operations and maintenance administrator → Obtaining access to the operations and maintenance terminal → Using the terminal credentials to enter the intranet via VPN → Exploiting privilege escalation vulnerabilities to obtain administrator privileges on the model server → Reading model files → Transmitting files through a covert channel; Path 2: Directly logging in using a weak password exposed to the operations and maintenance management interface → (Subsequent steps are also bound to environmental facts and implementation artifacts). During the generation process, the system, based on the attack chain dependency logic provided by the semantic graph and combined with tools to implement multi-implementation mapping relationships in the graph, systematically explores different combinations (e.g., substitution of phishing and weak password entry points, substitution of different privilege escalation implementations, etc.), while using the environmental graph for feasibility filtering and consistency verification: If a candidate path depends on a vulnerability that does not exist, has a version mismatch, is unreachable by the network, or the privilege chain cannot be closed, then the path is eliminated (e.g., branches involving the non-existent vulnerability CVE-2025-99999 are directly discarded). Finally, multiple candidate attack plans are obtained and written into the plan graph. For example, Plan 1 can be represented as a sequence of steps: [Send phishing email] → [Access internal VPN] → [Escalate privileges using CVE-2025-12345] → [Read file] → [Transfer data outwards]. Each step node is simultaneously bound to: a corresponding semantic step reference, an implementation artifact (tool / script / module), and an environment binding (target host / service / account / vulnerability / control coverage, etc.), and the execution order is marked. The system also configures alternative branches for critical steps: for example, if privilege escalation vulnerability exploitation fails, it can switch to the "credential acquisition / alternative permission achievement" path as an alternative.

[0193] Step 5, Binding and Feasibility Assessment: Calculate the adaptation gating function g(v,x) based on the CPE of the environment software and the scope of vulnerability impact, and add affectedBy related edges to the environment and asset graph. Perform consistency verification between the platform, permissions, and dependency constraints of the Implementation and the actual environment to form a step-level feasibility gating F(u)∈{0,1}.

[0194] Step 6, Iterative Evaluation and Optimization: The system iteratively evaluates candidate plans, calculating the step support s(u) and path consistency E(π) by accessing the observed event set O. A comprehensive scoring function J(π) is used for Top-K optimization, where I(π) is the impact function based on the value of key assets and the progress of the objective, calculated by matching the criticality of the environment and asset graph with the objective predicate. The probability of achieving the objective within a 24-hour window without triggering an IDS is statistically analyzed, taking into account factors such as success probability, exposure risk, and execution cost. Example evaluation results might be: Plan 1 has a high success rate for phishing entry and may not trigger an IDS, but the privilege escalation step has a probability of being blocked by host protection; Plan 2 has a lower success rate for direct login with weak passwords but a shorter link and fewer steps. The system calculates the comprehensive score and performs Top-K optimization accordingly. When the candidate space is large, an ACO combinatorial optimization mechanism can be further introduced to iteratively improve the candidates (e.g., adjusting the step order, replacing implementation artifacts, introducing a "try low-cost entry first—switch after failure" branch structure), forming an improved version Plan 3 (try weak passwords first, then switch to phishing if it fails), etc. After multiple rounds of evaluation and scoring, the system selects the solution with the highest comprehensive score (e.g., Plan 1) and provides quantitative results such as its success probability, exposure risk, and estimated time.

[0195] Step 7, Evidence-Driven Dynamic Replanning: During runtime, continuous monitoring of observed events such as alarms, logs, and rule hits forms O, iteratively updating the step support s(u) and path consistency E(π). During execution, if a critical step fails or the risk of triggering an alarm increases, the system adjusts based on pre-preserved alternative branches or local patching strategies. For example, when a privilege escalation script fails due to host protection blocking, the system switches to an alternative permission achievement branch (such as credential acquisition methods); when outbound traffic is monitored, the system switches communication channels or adjusts the timing of outbound transmission. Through this dynamic adjustment mechanism, the generated attack strategy remains robust to environmental changes and uncertainties.

[0196] Step 8: Output and Knowledge Accumulation: After the exercise, the system generates a structured attack strategy report and auditable artifacts. The report includes: a list and description of attack steps (e.g., phishing for initial access → VPN access to the intranet → privilege escalation → obtaining model files → covert transmission); references to the technologies / tools and implementation artifacts for each step (e.g., phishing templates, privilege escalation artifacts, etc.); prerequisites for each step and their fulfillment (e.g., user interaction, credential validity, vulnerability existence, version / platform constraints, etc.); evaluation metrics (success rate, time taken, risk exposure, etc.) and references to key evidence (log fragments, alarm summaries, rule hit records, etc.). Simultaneously, verified feasible bindings, constraint fulfillment statistics, and evidence anchor matching statistics are written back to the tool implementation graph and plan graph for subsequent iterative optimization and continuous knowledge evolution.

[0197] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0198] Through the above description of the embodiments, those skilled in the art can clearly understand that the attack path generation method according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0199] According to an embodiment of the present invention, an attack path generation apparatus for implementing the above-described attack path generation method is also provided. Figure 8 This is a structural block diagram of an attack path generation device provided according to an embodiment of the present invention, such as... Figure 8 As shown, the attack path generation device includes: an acquisition module 802, a first construction module 804, a second construction module 806, a third construction module 808, a query module 810, a calculation module 812, and a selection module 814, which are used to select candidate paths whose scores meet preset conditions as target attack paths. The attack path generation device will be described below.

[0200] The acquisition module 802 is used to acquire attack information, which includes the attack target, the attack object, the vulnerability, and the attack result.

[0201] The first building module 804 is used to build a task model based on attack information.

[0202] The second construction module 806 is used to construct multiple collaborative knowledge graphs based on preset semantic anchors.

[0203] The third construction module 808 is used to retrieve multiple collaborative knowledge graphs based on the task model and construct task subgraphs.

[0204] The query module 810 is used to query the attack path based on the attack target in the task subgraph and obtain candidate paths.

[0205] The calculation module 812 is used to calculate the score corresponding to the candidate path.

[0206] The selection module 814 is used to select candidate paths that meet the preset scoring conditions as target attack paths.

[0207] It should be noted that modules 802 to 814 correspond to steps S202 to S214 in the embodiments. Multiple modules implement the same instances and application scenarios as their corresponding steps, but are not limited to the content disclosed in the above embodiments. It should also be noted that these modules, as part of the device, can run on the computer terminal 10 provided in the embodiments.

[0208] Embodiments of the present invention may provide a computer device. Optionally, in this embodiment, the computer device may be located in at least one of a plurality of network devices in a computer network. The computer device includes a memory and a processor.

[0209] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the attack path generation method and apparatus in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned attack path generation method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0210] The processor can access information and applications stored in memory via a transmission device to perform the following steps: acquiring attack information, including the attack target, the target object, the vulnerability, and the attack result; constructing a task model based on the attack information; constructing multiple collaborative knowledge graphs based on preset semantic anchors; retrieving the multiple collaborative knowledge graphs according to the task model to construct a task subgraph; querying attack paths according to the attack target in the task subgraph to obtain candidate paths; calculating the scores corresponding to the candidate paths; and selecting the candidate path whose score meets preset conditions as the target attack path.

[0211] Optionally, the processor may also execute program code that performs the following steps: based on the attack target, retrieves the attack semantic chain in the attack semantic graph; based on the task model and the attack semantic chain, retrieves and determines the constraints and implementation tools in the tool implementation graph; based on the task model, retrieves the attack state in the environment and asset graph and determines the feasibility conditions; and based on the attack semantic chain, constraints, implementation tools, and feasibility conditions, constructs a task subgraph.

[0212] Optionally, the processor may also execute program code that performs the following steps: starting from the attack target, querying the attack relationship in reverse order in the task subgraph and checking whether the attack relationship meets the preset conditions, wherein the attack relationship includes the attack status and the attack tool; and determining the path of the attack relationship that meets the preset conditions as the candidate path.

[0213] Optionally, the processor may also execute program code that performs the following steps: detects whether the attack state is supported by the current environment assets, wherein the current environment assets include the target system version, privilege level, and network reachability; and monitors whether the execution constraints of the attack tool match the environment conditions, wherein the environment conditions include the operating system, dependent components, running permissions, and network ports.

[0214] Optionally, the processor may also execute program code that performs the following steps: calculates the success confidence, exposure risk, and cost metrics for each step in the candidate path; calculates the path success power, path exposure risk, and total path cost for the candidate path based on the success confidence, exposure risk, and cost metrics for each step; and determines the score for the candidate path based on the path success power, path exposure risk, and total path cost for the candidate path.

[0215] This invention provides a multi-knowledge graph collaboration scheme. It employs an attack path generation method, constructing an attack semantic graph, a tool-based multi-knowledge graph system that collaborates with environmental and asset graphs, and aligning cross-graph entities based on a unified semantic anchor. Driven by the attack target, it queries attack relationships in reverse hierarchy within the task subgraph, combining environmental asset support and tool execution constraints for feasibility gating. After generating candidate paths, it calculates their success confidence, exposure risk, and execution cost, and selects the optimal path based on a comprehensive score. Simultaneously, it continuously integrates observation events (such as alarms, logs, and rule hits) during runtime to dynamically update path evidence consistency, triggering branch switching or local patching. This achieves real-time linkage between the generated attack path and the real environment state, execution constraints, and observation feedback, thereby realizing the technical effects of attack path executability, verifiability, and adaptive repair capabilities. This solves the technical problem of existing AI attack path generation methods relying on static graphs, lacking real-time environmental feedback and dynamic replanning capabilities, resulting in generated attack paths failing to respond to execution deviations, alarm triggers, or asset changes, lacking a closed-loop feedback mechanism, and unable to dynamically replan or adaptively repair.

[0216] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a non-volatile storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0217] Embodiments of the present invention also provide a non-volatile storage medium. Optionally, in this embodiment, the aforementioned non-volatile storage medium can be used to store the program code executed by the attack path generation method provided in the above embodiments.

[0218] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0219] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: acquiring attack information, wherein the attack information includes attack target, attack object, vulnerability, and attack result; constructing a task model based on the attack information; constructing multiple collaborative knowledge graphs based on preset semantic anchors; retrieving the multiple collaborative knowledge graphs according to the task model to construct a task subgraph; querying attack paths according to the attack target in the task subgraph to obtain candidate paths; calculating the scores corresponding to the candidate paths; and selecting candidate paths whose scores meet preset conditions as target attack paths.

[0220] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: retrieving attack semantic chains in the attack semantic graph based on the attack target; retrieving constraints and implementation tools in the tool implementation graph based on the task model and the attack semantic chains; retrieving attack states in the environment and asset graph based on the task model and determining feasibility conditions; and constructing a task subgraph based on the attack semantic chains, constraints, implementation tools, and feasibility conditions.

[0221] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: starting from the attack target, querying the attack relationship in reverse order in the task subgraph and detecting whether the attack relationship meets the preset conditions, wherein the attack relationship includes the attack state and the attack tool; determining the path of the attack relationship that meets the preset conditions as the candidate path.

[0222] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: detecting whether the attack state is supported by the current environment assets, wherein the current environment assets include the target system version, permission level, and network reachability; and monitoring whether the execution constraints of the attack tool match the environment conditions, wherein the environment conditions include the operating system, dependent components, running permissions, and network ports.

[0223] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: calculating the success confidence, exposure risk, and cost indicators corresponding to each of the multiple steps in the candidate path; calculating the path success power, path exposure risk, and total path cost corresponding to the candidate path based on the success confidence, exposure risk, and cost indicators corresponding to each of the multiple steps; and determining the score corresponding to the candidate path based on the path success power, path exposure risk, and total path cost corresponding to the candidate path.

[0224] Embodiments of the present invention also provide a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can: acquire attack information, wherein the attack information includes an attack target, an attack object, a vulnerability, and an attack result; construct a task model based on the attack information; construct multiple collaborative knowledge graphs based on preset semantic anchors; search the multiple collaborative knowledge graphs according to the task model to construct a task subgraph; query attack paths according to the attack target in the task subgraph to obtain candidate paths; calculate the scores corresponding to the candidate paths; and select the candidate paths whose scores meet preset conditions as the target attack paths.

[0225] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0226] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0227] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0228] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0229] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0230] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0231] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for generating an attack path, characterized in that, include: Acquire attack information, wherein the attack information includes the attack target, the attack object, the vulnerability, and the attack result; Based on the attack information, a task model is constructed; Multiple collaborative knowledge graphs are constructed based on preset semantic anchors; Based on the task model, the multiple collaborative knowledge graphs are retrieved to construct a task subgraph; In the task subgraph, attack paths are queried based on the attack target to obtain candidate paths; Calculate the score corresponding to the candidate path; Candidate paths that meet the preset scoring criteria are selected as the target attack paths.

2. The method according to claim 1, characterized in that, The multiple collaborative knowledge graphs include an attack semantic graph, a tool implementation graph, and an environment and asset graph. The attack semantic graph describes the attack logic, the tool implementation graph describes the attack tools and constraints, and the environment and asset graph describes the attack state.

3. The method according to claim 2, characterized in that, The step of retrieving the multiple collaborative knowledge graphs and constructing a task subgraph based on the task model includes: Based on the attack target, retrieve the attack semantic chain in the attack semantic graph; Based on the task model and the attack semantic chain, the constraints and implementation tools are determined by searching the tool implementation graph. Based on the task model, attack status is retrieved from the environment and asset graph to determine feasibility conditions; Based on the attack semantic chain, the constraints, the implementation tools, and the feasibility conditions, the task subgraph is constructed.

4. The method according to claim 1, characterized in that, In the task subgraph, the attack path is queried based on the attack target to obtain candidate paths, including: Starting from the attack target, the attack relationship is queried in reverse order in the task subgraph and the attack relationship is checked to see if it meets the preset conditions. The attack relationship includes the attack status and the attack tool. The paths that satisfy the preset conditions for attack relationships are identified as candidate paths.

5. The method according to claim 4, characterized in that, The detection of whether the attack relationship meets preset conditions includes: Detect whether the attack state is supported by the current environmental assets, wherein the current environmental assets include the target system version, privilege level, and network reachability; The execution constraints of the attack tool are monitored to ensure they match the environmental conditions, which include the operating system, dependent components, running permissions, and network ports.

6. The method according to any one of claims 1 to 5, characterized in that, The calculation of the score corresponding to the candidate path includes: Calculate the success confidence, exposure risk, and cost metrics for each step in the candidate path; Based on the success confidence, exposure risk and cost indicators corresponding to each of the multiple steps, calculate the path success power, path exposure risk and total path cost of the candidate path. The score corresponding to the candidate path is determined based on the path success power, path exposure risk, and total path cost.

7. An attack path generation device, characterized in that, include: The acquisition module is used to acquire attack information, wherein the attack information includes the attack target, the attack object, the vulnerability, and the attack result; The first construction module is used to construct a task model based on the attack information; The second building module is used to construct multiple collaborative knowledge graphs based on preset semantic anchors; The third construction module is used to retrieve the multiple collaborative knowledge graphs based on the task model and construct a task subgraph. The query module is used to query the attack path based on the attack target in the task subgraph and obtain candidate paths; The calculation module is used to calculate the score corresponding to the candidate path; The selection module is used to select candidate paths that meet preset scoring conditions as target attack paths.

8. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the non-volatile storage medium to execute the attack path generation method according to any one of claims 1 to 6.

9. A computer device, characterized in that, include: Memory and processor The memory stores computer programs; The processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, the processor performs the attack path generation method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the attack path generation method according to any one of claims 1 to 6.

Images