A TTPs Scenario Analysis Method for Software-Defined Deception Defense Systems
By combining a cybersecurity knowledge graph with a large language model, the problems of incomplete environmental information extraction and insufficient verification in the software-defined deception defense system are solved. This enables high-fidelity system environment configuration and automated verification of simulation environments, improving the efficiency and accuracy of the defense system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- GUANGZHOU UNIVERSITY
- Filing Date
- 2026-02-05
- Publication Date
- 2026-05-26
AI Technical Summary
In existing software-defined deception defense systems, the analysis of attack techniques is mostly limited to tactical descriptions, lacking a clear connection to the underlying system environment. Environmental information is scattered and difficult to extract in a structured way, and there is a lack of effective verification methods, resulting in insufficient usability and credibility of defense strategies.
By constructing a cybersecurity knowledge graph, semantic retrieval and reasoning are performed based on a large language model to generate structured system environment information. The system environment is then tested in a simulation environment to verify its adaptability, forming a closed-loop process to automatically extract and correct the environment configuration.
It significantly improves the real trigger rate and path reproduction accuracy of attack behaviors in the deception defense simulation environment, enhances the integrity and detail accuracy of environment modeling, and improves the operational efficiency and automated response capability of the defense system.
Smart Images

Figure CN121644246B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of cybersecurity, and in particular to a method for analyzing TTPs scenarios for software-defined deception defense systems. Background Technology
[0002] Cybersecurity confrontations are intensifying, and attacks have evolved from simple disruptions to advanced persistent threats (APTs) with phased approaches, covert paths, and flexible tactics. Traditional defense systems relying on static rules and feature matching are ill-equipped to effectively address the rapid evolution of attack methods and their covert infiltration into normal traffic. Against this backdrop, proactive defense has become a crucial development direction. Software-defined deception (SDD) defense systems, through the unified orchestration and dynamic scheduling of deception resources, achieve efficient trapping and interference of attackers. To enhance the intelligence and response accuracy of such SSD defense systems, the industry is exploring the use of knowledge graphs to structure attack knowledge and leveraging the powerful semantic understanding and reasoning capabilities of Large Language Models (LLMs) to automatically extract and analyze attack patterns from massive amounts of threat intelligence and interaction logs. This invention, within this context, focuses on addressing the specific problem of unclear attack techniques, tactics, and environmental dependencies, aiming to provide verifiable and executable environmental intelligence support for dynamic policy generation and simulation environment construction in SSD defense.
[0003] However, despite advancements in existing technologies, significant shortcomings remain in supporting accurate environment simulation for software-defined deception defense systems. First, the analysis of attack techniques often remains at the tactical description level, with the specific conditions necessary for successful execution, such as the underlying system environment and configuration dependencies, frequently missing or not explicitly linked. Second, relevant environmental information is scattered across unstructured reports and logs, making it difficult to effectively extract and transform into machine-readable, directly usable structured intelligence. Finally, the veracity and effectiveness of the environment configuration derived from the analysis often lacks reliable verification methods, leading to potentially unrealistic defense strategies with insufficient usability and credibility. Therefore, a solution is urgently needed to address these issues. Summary of the Invention
[0004] The purpose of this invention is to provide a TTPs scenario analysis method for software-defined deception defense systems that can improve the problems of incomplete extraction of environmental information and lack of empirical verification mechanisms for attack techniques.
[0005] This invention provides a TTPs scenario analysis method for software-defined deception defense systems, comprising:
[0006] A cybersecurity knowledge graph is constructed based on threat intelligence sources; based on the cybersecurity knowledge graph, attack indicators and observation data are retrieved and extracted according to the input attack technology identifiers and predefined semantic paths to generate structured retrieval data;
[0007] The retrieved data is converted into natural language description text based on a large language model, and interactive reasoning is performed based on the natural language description text using the large language model to generate system environment information corresponding to the attack technology identifier.
[0008] Based on the system environment information, the operation corresponding to the attack technique identifier is executed in the simulation environment to verify the adaptability of the system environment information, and the system environment information is corrected according to the verification results.
[0009] This invention provides a TTPs scenario analysis method for software-defined deception defense systems. Through semantic retrieval and interactive reasoning based on attack technique identifiers, combined with closed-loop verification in a simulation environment, it achieves automated and verifiable extraction and reconstruction of system environment information on which attack techniques depend from massive threat intelligence.
[0010] Optionally, when constructing a cybersecurity knowledge graph based on threat intelligence sources, the following may be included:
[0011] Threat intelligence data is collected from threat intelligence sources and preprocessed. Entities are extracted from the processed threat intelligence data using named entity recognition technology, and relationships between the entities are extracted using relation extraction technology. Based on a preset unified data standard, node modeling is performed on the entities, and relation modeling is performed on the relationships. Based on the modeled entities and relationships, the cybersecurity knowledge graph is constructed.
[0012] The entities include attackers, malware, tools, attack techniques, attack indicators, and observation data; the relationships include the use relationship of attackers using attack techniques, malware, or tools, the relationship based on observation data for attack indicators, the indication relationship of attack indicators indicating attackers, malware, or tools, and the development relationship of malware or tools being developed by attackers.
[0013] Optionally, when generating structured retrieval data based on a cybersecurity knowledge graph, by retrieving and extracting attack indicators and observation data according to the input attack technique identifier and predefined semantic path, the data includes:
[0014] The attack technique number in the MITRE ATT&CK framework is used as the attack technique identifier, and the attack technique identifier is used as the query entry point to locate the corresponding attack technique node in the network security knowledge graph.
[0015] Based on the semantic relationships between entities in the network security knowledge graph, a semantic path is constructed that starts from the attack technology node, passes through the malware node or tool node and the attack indicator node, and finally reaches the observation data node.
[0016] Along the semantic path, traverse and extract associated malware or tool data, attack indicators, and observation data; organize the attack technology identifiers, attack indicators, and observation data into structured retrieval data according to a preset format.
[0017] Optionally, the threat intelligence sources include MITRE ATT&CK, open-source malware sample libraries, advanced persistent threat analysis reports, and threat analysis platform logs; the attack indicators include file hash values, IP addresses, and domain names; and the observation data includes file operation records, process operation records, registry operation records, and network connection records.
[0018] Optionally, when converting the retrieved data into natural language description text based on a large language model, and performing interactive reasoning based on the natural language description text using the large language model to generate system environment information corresponding to the attack technique identifier, the process includes:
[0019] Based on the large language model, the retrieved data is sequentially filled into a preset natural language template to generate the natural language description text;
[0020] An initial prompt containing the attack technique identifier and the natural language description text is constructed and submitted to the large language model to obtain a preliminary answer;
[0021] The initial answer is analyzed, and logical consistency is verified based on the analysis results and combined with an external prior knowledge base. Follow-up questions are then generated, and the large model is guided to perform at least one subsequent inference based on the follow-up questions.
[0022] Based on the initial response and the results of at least one subsequent inference, system environment information corresponding to the attack technique identifier is generated.
[0023] Optionally, when filling the retrieved data into a preset natural language template in an orderly manner based on the large language model, the process includes:
[0024] The behavioral category tags in the retrieved data are semantically expanded and interpreted.
[0025] And / or convert the timestamps in the retrieved data to a standard date and time format;
[0026] And / or mark missing or abnormal fields in the retrieved data.
[0027] Optionally, the system environment information includes attack technique number, system version, process list, file path list, normal software and port list.
[0028] Optionally, when performing an operation corresponding to the attack technique identifier in a simulation environment based on the system environment information, verifying the adaptability of the system environment information, and correcting the system environment information according to the verification result, the process includes:
[0029] Based on the system environment information, configure the simulation environment; in the simulation environment, invoke the automated attack simulation framework to execute the operation sequence corresponding to the attack technique identifier;
[0030] Monitor system events in the simulation environment, obtain execution trajectories, compare the execution trajectories with the expected behavior, and determine whether the attack technique corresponding to the attack technique identifier has been successfully triggered;
[0031] If the system is determined to have failed to trigger, the execution trajectory is analyzed to identify environmental configuration defects. Based on these defects, suggestions for correcting the system environment information are generated, and subsequent simulation verification is iteratively optimized based on these suggestions.
[0032] Compared with the prior art, the present invention has the following advantages:
[0033] 1. This invention forms a complete closed-loop process by integrating semantic retrieval from knowledge graphs, intelligent reasoning from large language models, and empirical verification through automated attack simulation. This process can systematically derive and construct high-fidelity system environment configurations for specific attack techniques (TTPs), thereby significantly improving the real trigger rate and path reproduction accuracy of attack behaviors in deception defense simulation environments, overcoming the shortcomings of traditional methods that rely on static rules and have coarse environment modeling.
[0034] 2. By leveraging large language models to perform deep semantic understanding and contextual reasoning on unstructured threat intelligence and graph retrieval results, this invention can automatically and accurately extract the core features constituting the system environment, including but not limited to operating system version, critical processes, file paths, registry entries, and open ports. This greatly reduces reliance on human experience and enhances the completeness and accuracy of environment modeling.
[0035] 3. This invention introduces an empirical verification step based on an automated attack simulation framework. By executing TTP (Test for Troubleshooting) actions in the configuration environment and monitoring the results, the system can objectively determine the effectiveness of the environment configuration, automatically analyze the reasons for failure, and generate targeted correction suggestions. This achieves a closed loop of environment configuration verification and error correction.
[0036] 4. The environment configuration generated by this invention is output in a structured data format, exhibiting high modularity and standardization. This output format is compatible with the core requirements of software-defined deception defense systems, facilitating rapid loading, dynamic scheduling, and policy updates of honeypot environments by the control center, thereby significantly improving the operational efficiency, scenario adaptability, and automated response capabilities of the entire defense system. Attached Figure Description
[0037] Figure 1 A flowchart illustrating a TTPs scenario analysis method for a software-defined deception defense system provided in this embodiment of the invention. Detailed Implementation
[0038] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art. The terms "comprising" and similar expressions used herein mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but does not exclude other elements or objects.
[0039] See Figure 1 This invention provides a method for analyzing TTPs scenarios in a software-defined deception defense system, comprising the following steps:
[0040] S1. Construct a cybersecurity knowledge graph based on threat intelligence sources; Based on the cybersecurity knowledge graph, retrieve and extract attack indicators and observation data according to the input attack technology identifiers and predefined semantic paths, and generate structured retrieval data;
[0041] S2. Based on the large language model, the retrieved data is converted into natural language description text, and interactive reasoning is performed on the natural language description text through the large language model to generate system environment information corresponding to the attack technology identifier;
[0042] S3. Based on the system environment information, perform the operation corresponding to the attack technology identifier in the simulation environment to verify the adaptability of the system environment information, and correct the system environment information according to the verification results.
[0043] In some embodiments, when constructing a cybersecurity knowledge graph based on threat intelligence sources in step S1, threat intelligence data is first collected from multiple public and proprietary threat intelligence sources. These sources include, but are not limited to, MITREATT&CK, open-source malware sample libraries (such as VirusShare), Advanced Persistent Threat (APT) analysis reports, and threat analysis platform logs. This data covers a wide range of information, from attack tactics and malware samples to observations of specific system behaviors. Next, the threat intelligence data is cleaned (e.g., deduplicated, filtering irrelevant or low-quality data) and standardized in format. Due to the diverse formats of the original threat intelligence data, it needs to be uniformly converted into a preset intermediate representation format for subsequent information extraction engine processing, ensuring data consistency and parsability. Then, entities are automatically extracted and classified from the preprocessed threat intelligence data using named entity recognition technology. Based on entity recognition, semantic relationships between entities are further extracted using relation extraction technology. Based on a preset unified data specification, the extracted entities are modeled as nodes in the knowledge graph, and a type and attributes are defined for each node; the extracted relationships are modeled as edges connecting nodes, with type and direction. All nodes and edges that conform to the unified modeling standard are imported into a graph database for storage and indexing, ultimately forming a cybersecurity knowledge graph. This graph provides a structured knowledge foundation for subsequent semantic retrieval starting from attack technology identifiers.
[0044] Specifically, the entity types in a cybersecurity knowledge graph include:
[0045] An attacker is an organization or threat actor that carries out an attack, such as an APT group number (e.g., APT28), a hacker group, or a cybercrime organization.
[0046] Malware refers to malicious code entities that perform offensive actions, such as backdoors, worms, Trojans, and ransomware.
[0047] Tools refer to legitimate tools or penetration testing tools used by attackers during an attack, such as PowerShell and Mimikatz.
[0048] Tactics, Techniques and Procedures (TTP) refer to the attack tactics, techniques and procedures described in the MITRE ATT&CK framework;
[0049] An attack indicator is an observable feature used to indicate attack intent or malicious activity, such as hashes, IP addresses, domain names, and URLs.
[0050] Observed data refers to system behaviors recorded during the execution of actual attack samples or threat monitoring, such as file creation, process startup, registry modification, and network connection.
[0051] Specifically, there are semantically clear relationships between entities, and key relationship types include:
[0052] The use of the relation (uses) indicates that one entity (such as an attacker or malware) uses another entity (such as an attack technique or tool) in an activity. For example, Attacker→TTP / Malware / Tool means that the attacker uses a specific attack technique, malware, or tool, and Malware→TTP / Tool means that the malware implements the technique, calls or integrates tools to perform its functions during the attack.
[0053] Indicators indicate that a particular attack indicator can be used to infer the presence or activity of a specific entity (such as an attacker or malware). For example, indicator→Attacker / Malware / Tool indicates that an attack indicator points to a specific attack organization, malware, or tool.
[0054] The "based_on" relation indicates that the judgment of a certain attack indicator is derived from specific observation data. For example, "indicator→observed_data" means that a certain attack indicator is generated based on a certain observation data.
[0055] The "authorized_by" relationship indicates that a piece of malware or tool was developed or owned by a specific attacker. For example, Malware / Tool→Attacker means that the malware or tool was developed by a particular attacker.
[0056] In some embodiments, in step S1, when retrieving and extracting attack indicators and observation data based on the input attack technique identifier and predefined semantic path according to the network security knowledge graph, and generating structured retrieval data, the attack technique number in the MITREATT&CK framework is used as the attack technique identifier, and the attack technique identifier is used as the query entry point to locate the corresponding attack technique node in the network security knowledge graph; based on the semantic association between entities in the network security knowledge graph, a semantic path is constructed from the attack technique node, through malware or tool nodes, attack indicator nodes, and finally to the observation data node; along the semantic path, associated malware or tool data, attack indicators, and observation data are traversed and extracted; the attack technique identifier, attack indicators, and observation data are organized according to a preset format to generate structured retrieval data. The specific process is as follows:
[0057] S11. Based on the input attack technique identifier, the system uses this identifier as the query entry point to perform a query in the network security knowledge graph, accurately locating the attack technique node corresponding to that number. The attack technique identifier is the attack technique number (TTP_ID) in the MITRE ATT&CK framework. For example, TTP number T1082 represents "System Information Discovery," used to identify the target host's operating system version, hardware configuration, domain information, etc.
[0058] S12. The system does not use fixed query statements, but dynamically constructs semantic paths based on the rich semantic relationships predefined in the network security knowledge graph. In a typical embodiment, the typical path "attack technology → malware / tools → attack indicators → observation data" is mainly adopted, which reflects the actual execution chain of the attack behavior. The system first starts from the located attack technology node and explores the associated malware or tool nodes along relationships such as uses. Then, starting from these nodes, it queries the corresponding attack indicator nodes along the indicators relationship. Finally, starting from the attack indicator node, it locates the corresponding observation data node along the based_on relationship. This construction process is semantically driven. If some entities and relationships are missing or interrupted in the graph, the system will automatically adjust the retrieval method according to the actual available nodes. For example, when sample information is insufficient, attack technology nodes can be directly associated with typical attack indicator nodes; when indicators are missing but behavior records exist, they can also be directly linked to observation data through sample behavior entities. The retrieval process prioritizes semantic relevance and data integrity, and dynamically selects the main path or alternative path to ensure that the extracted environmental information is as comprehensive and reliable as possible, and can cover the actual performance of attack techniques in different scenarios.
[0059] S13. Following the semantic path constructed above, the system performs a traversal query in the graph database. It sequentially visits malware / tool nodes, attack indicator nodes, and observation data nodes along the path, and extracts data from these nodes. The attack indicator data includes hash values, IP addresses, domain names, and other key features used to identify malicious behavior; the observation data includes system behavior records such as files, registry entries, processes, and network connections.
[0060] S14. Integrate and serialize the context and results of this search. The system organizes the attack technique identifier (which serves as the starting point of the query), the extracted attack indicators, and the observation data list corresponding to each indicator according to a predefined format. In a typical embodiment, this format is JSON. Finally, structured search data is generated.
[0061] To illustrate this more clearly, the following is an example of a structured JSON format for retrieving data. It should be noted that the example below is for illustrative purposes only, demonstrating its core structure, and not a complete definition of the data content. Example as follows:
[0062] {
[0063] "ttp_id": "T1082",
[0064] "indicator": [{
[0065] "id": 1493,
[0066] "hash": "9afd2ccb1..."
[0067] "behavior": ["networks_operation","mutexes_operation",..]
[0068] }],
[0069] "observed_data": [{
[0070] "id": 600,
[0071] "first_observed": 1187089444,
[0072] "last_observed": 1745485135,
[0073] "number_observed": 45118,
[0074] "type": "registry_key",
[0075] "value":"HKEY_CURRENT_USER\\Software\\Microsoft\\..."
[0076] }],
[0077] }
[0078] The `ttp_id` field records the attack technique identifier used as the query entry point. The `indicator` field encapsulates one or more extracted attack indicator entities. Each indicator object contains a unique identifier (id), a hash value, and associated behavior tags, including but not limited to `files_operation`, `processes_operation`, `registry_keys_operation`, `networks_operation`, `services_operation`, `mutexes_operation`, and `windows_operation`. The `observed_data` field encapsulates the specific behavior observation records corresponding to the indicator. Each record contains a unique identifier (id), behavior type (e.g., file, registry, mutex), first observation time (first_observed), last observation time (last_observed), observation frequency (number_observed), and the observed value (value), among other key attributes. This pre-defined format specification allows heterogeneous node data that was originally scattered throughout the graph to be organized into a unified, serializable data entity that can be directly used as input for subsequent large language model inference.
[0079] In some embodiments, in step S2, when converting the retrieved data into natural language description text based on a large language model, and performing interactive reasoning based on the natural language description text through the large language model to generate system environment information corresponding to the attack technique identifier, the retrieved data is sequentially filled into a preset natural language template based on the large language model (such as GPT3.5, Qwen, LLaMA) to generate natural language description text; an initial prompt containing the attack technique identifier and natural language description text is constructed and submitted to the large language model to obtain a preliminary answer; the preliminary answer is parsed, and logical consistency is checked based on the parsing result and combined with an external prior knowledge base to generate follow-up prompts; the follow-up prompts guide the large model to perform at least one subsequent reasoning; based on the preliminary answer and the result of at least one subsequent reasoning, system environment information corresponding to the attack technique identifier is generated. This system environment information is a key input for policy orchestration and resource scheduling in the software-defined system. The specific process is as follows:
[0080] S21. The system receives structured retrieval data from S1 and generates a complete and semantically rich natural language description text by orderly filling key fields from the retrieval data into the corresponding placeholders of a preset natural language template. For example, the hash value in the indicator field is filled into a sentence such as "The MD5 value of the sample is {hash_md5}, and the SHA256 value is {hash_sha256}". To enhance the model's understanding of attack behavior, this process includes semantic enhancement operations: expanding the interpretation of abstract labels in the behavior field (e.g., interpreting "mutexes_operation" as "mutexistence operation, often used to prevent multiple instances from running") to improve the accuracy and readability of contextual expression; converting timestamps (first_observed, last_observed) into a standard date and time format to clarify the active time range of the sample, making it easier for the model to capture time-related environmental features; and annotating and prompting potentially missing or abnormal fields to assist in focusing on key areas during subsequent inference.
[0081] S22. Using the natural language description text and attack technique identifiers generated in S21 as core inputs, the system constructs an initial prompt and submits it to the large language model to obtain a preliminary answer.
[0082] S23. The system analyzes the initial response from the large language model and guides the response convergence through iterative follow-up questions. Details are as follows:
[0083] Parsing and Comparison: Based on preset field extraction rules, the system extracts candidate fields such as system version, process name, file path, registry entry, and network port from the text through regular expression matching, keyword positioning, and model recognition. The system then compares the newly extracted fields with the initially input known information item by item, marking missing fields, fields with ambiguous values, and fields that contradict each other. When multiple different system versions, unclear file paths, or registry entries that are inconsistent with the behavior type appear in the answer, the system treats these fields as "items to be clarified."
[0084] Logical consistency verification: The system also combines external prior knowledge bases (such as MITRE ATT&CK data, operating system specifications, malware behavior databases, IoC databases, network protocol specifications, and vulnerability knowledge bases) to perform logical consistency verification on the model's answers. For example, when the answer contains an operating system that does not match known ATT&CK technology, uses a file path that does not exist in the system specification, or provides hash behavior that is inconsistent with the IoC database record, the system will determine that the field has a logical conflict or contextual contradiction, and automatically generate remedial prompts to request the model to further clarify the meaning of the specific field, confirm whether the path or process belongs to a system component, or determine whether the port number and protocol are reasonable.
[0085] Follow-up Question Generation and Iteration: Based on the above analysis and verification results, the system automatically generates follow-up questions, resubmitting the content that needs to be supplemented or clarified to the model. For example, it may require confirmation of a specific version number, differentiation between normal software paths and attack paths, or limitation of the system component to which a file path belongs. Through this comparison-supplementation method, the model gradually converges to a complete, clear, and consistent environment description in subsequent generation. During multiple rounds of interaction, the large language model dynamically adjusts its questioning strategy based on the quality of the response. If it finds inconsistencies in the generated information or missing key elements, it automatically adds clarifying prompts or restrictive supplements, prompting the large language model to generate more targeted and actionable answers. Through this cyclical processing method of "answer verification—contradiction detection—remedial prompts," the model gradually converges to an environment description that conforms to the attack technique logic and system specifications during multiple rounds of interaction.
[0086] To illustrate the interaction process more specifically, the following are examples of prompts that may be used in this process:
[0087] ① Initial prompt example:
[0088] "Based on the hash values and observed behavior of the following malicious samples, please infer the possible system environment version and main characteristics in which they may be running:"
[0089] MD5:e2e4b2f28d29fd19bb28287a4d99ede2
[0090] SHA1:01ffc3ee5c2c560d29aaa8ac3d17f0ea4f6c0c09
[0091] SHA256:9afd2ccb1e2c434d296a6fa54fa5425c827e4172947c05a7db226076996a3715
[0092] File type: PE32 executable (GUI) Intel 80386, for Windows
[0093] Behavior categories include: network operations, mutex operations (used to prevent multiple instances from running), registry operations, service operations, file operations, and process operations.
[0094] First observation time: 2023-01-15 08:30:00
[0095] Last observation time: 2023-04-20 23:45:00
[0096] Please analyze and describe the operating system version and environmental characteristics that this sample may rely on.
[0097] ②Example of iterative follow-up questions:
[0098] "This sample involves the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. Please determine whether this indicates that the sample has persistent intent? Can its behavior be mapped to MITRE ATT&CK technology number T1547.001? Please provide a detailed description in conjunction with the registry path and behavior type."
[0099] ③Example of environmental exclusion prompts:
[0100] "The file path of the sample contains the directory 'Program Files\Kaspersky\', which usually points to the installation directory of security software. Please determine whether this path may be a factor interfering with normal software, and whether related processes and files should be excluded during the analysis. Please explain your reasoning."
[0101] ④ Example of system environment information:
[0102] Based on the foregoing analysis, please output the multi-dimensional system environment information corresponding to this sample, including:
[0103] "
[0104] S24. After multiple rounds of interaction and the model's responses becoming stable and complete, the system finally extracts and structures system environment information from the dialogue content. This information typically includes the TTP number, system version, process list, file path list, and list of normal software and ports.
[0105] In some embodiments, in step S3, based on system environment information, the operation corresponding to the attack technique identifier is executed in the simulation environment to verify the adaptability of the system environment information, and the system environment information is corrected according to the verification results. Based on the system environment information, the simulation environment is configured; in the simulation environment, the automated attack simulation framework is invoked to execute the operation sequence corresponding to the attack technique identifier; system events in the simulation environment are monitored, the execution trajectory is obtained, and the execution trajectory is compared with the expected behavior to determine whether the attack technique corresponding to the attack technique identifier has been successfully triggered; if it is determined that it has not been successfully triggered, the execution trajectory is analyzed to determine the environment configuration defect, and a correction suggestion for the system environment information is generated based on the environment configuration defect. The subsequent simulation verification is iteratively optimized based on the correction suggestion. The environment configuration verified through empirical testing ensures that every environment template delivered to the deception defense system has high reliability and executability. The specific process is as follows:
[0106] S31. The system receives the system environment information from step S2 and automatically configures a highly controllable simulation environment based on this. This configuration aims to accurately reproduce all inferred items in the environment information list. Specific operations include: setting the specified operating system type and version, creating or implanting necessary file paths, writing corresponding registry entries, starting relevant system services and processes, and opening specific network ports as needed. This step aims to accurately reproduce the target environment inferred by the large language model, laying the foundation for subsequent behavior reproduction.
[0107] S32. In the configured simulation environment, the system calls the automated attack simulation framework (such as Atomic RedTeam, Caldera) to perform operations. The generated environment configuration is used as input to build the corresponding verification scenario. The system executes the commands, scripts or operation instructions corresponding to TTP according to the preset steps to reproduce the execution process of the actual combat TTP behavior in a specific environment.
[0108] S33. During simulation execution, the system captures system events generated within the simulation environment in real time, and records the time sequence and return results of each operation step, forming a complete execution trajectory. System events include process tree changes, file read / write operations, registry key modifications, network connection establishment, and service status changes. The system compares the captured execution trajectory with the expected behavior defined based on TTP semantic requirements. For example, it verifies whether key behaviors are triggered, whether the behavior sequence conforms to the technical semantic description, whether the execution path is consistent with the inferred environmental conditions, and whether abnormal return values or failed steps indicate insufficient environment configuration. When the simulated behavior is detected to be highly consistent with the semantic characteristics of the TTP (such as generating a specific file path, modifying a specified registry key, or establishing a target port connection), it can be determined that the environment configuration can support the effective execution of the TTP, i.e., the attack technique has been successfully triggered. If certain key behaviors are not triggered or unexpected system changes occur, i.e., the attack technique has not been successfully triggered, the system will record the failed steps and reasons, providing a basis for subsequent correction of the environment configuration.
[0109] S34. If the trigger is determined to have failed, the system will perform an adaptation analysis on the current environment configuration based on the captured execution trajectory to identify the specific environment configuration defects that caused the failure. The analysis process first reads the operation instructions, return values, exception logs, and key behaviors that were not triggered corresponding to the failed step, and compares them with the semantic requirements of TTP and the inferred environment fields. For example, it checks whether the target process does not exist, whether the file path is invalid, whether the registry key is missing, whether the port is not open, whether the dependent components are not installed, or whether the permission level is insufficient. Based on the analysis results, the system automatically generates a specific modification suggestion, which may include completing missing files or directories, adjusting registry key values, modifying process startup conditions, adding necessary network ports, switching to a suitable operating system version, or elevating the required permission level.
[0110] S35. The generated correction suggestions will serve as feedback, driving iterative correction and verification of the system environment information. Depending on the nature of the defect, the system can choose to return to step S2 to re-perform environmental reasoning with the corrected information; or return to step S31 to directly apply the correction suggestions and initiate a new round of simulation verification. This ensures that the final configuration can support the complete triggering of TTP behavior.
[0111] While embodiments of the present invention have been described in detail above, it will be apparent to those skilled in the art that various modifications and variations can be made to these embodiments. However, it should be understood that such modifications and variations fall within the scope and spirit of the invention as set forth in the claims. Furthermore, the invention described herein may have other embodiments and can be implemented or carried out in various ways.
Claims
1. A method for analyzing TTPs scenarios in a software-defined deception defense system, characterized in that, include: Building a cybersecurity knowledge graph based on threat intelligence sources; Based on a network security knowledge graph, attack indicators and observation data are retrieved and extracted according to the input attack technology identifier and predefined semantic path to generate structured retrieval data; the observation data refers to system behaviors recorded during the actual attack sample execution or threat monitoring process, including file creation, process startup, registry modification and network connection. The retrieved data is converted into natural language description text based on a large language model, and interactive reasoning is performed based on the natural language description text using the large language model to generate system environment information corresponding to the attack technology identifier. Based on the system environment information, the operation corresponding to the attack technique identifier is executed in the simulation environment to verify the adaptability of the system environment information, and the system environment information is corrected according to the verification results.
2. The method as described in claim 1, characterized in that, When constructing a cybersecurity knowledge graph based on threat intelligence sources, the following are included: Threat intelligence data is collected from threat intelligence sources and preprocessed. Entities are extracted from the processed threat intelligence data using named entity recognition technology, and relationships between the entities are extracted using relation extraction technology. Based on a preset unified data standard, node modeling is performed on the entities, and relation modeling is performed on the relationships. Based on the modeled entities and relationships, the cybersecurity knowledge graph is constructed. The entities include attackers, malware, tools, attack techniques, attack indicators, and observation data; the relationships include the use relationship of attackers using attack techniques, malware, or tools, the relationship based on observation data for attack indicators, the indication relationship of attack indicators indicating attackers, malware, or tools, and the development relationship of malware or tools being developed by attackers.
3. The method as described in claim 2, characterized in that, Based on a cybersecurity knowledge graph, attack indicators and observation data are retrieved and extracted according to the input attack technique identifiers and predefined semantic paths. When generating structured retrieval data, this includes: The attack technique number in the MITRE ATT&CK framework is used as the attack technique identifier, and the attack technique identifier is used as the query entry point to locate the corresponding attack technique node in the network security knowledge graph. Based on the semantic relationships between entities in the network security knowledge graph, a semantic path is constructed that starts from the attack technology node, passes through the malware node or tool node and the attack indicator node, and finally reaches the observation data node. Along the semantic path, traverse and extract associated malware or tool data, attack indicators, and observation data; organize the attack technology identifiers, attack indicators, and observation data into structured retrieval data according to a preset format.
4. The method as described in claim 1, characterized in that, The threat intelligence sources include MITRE ATT&CK, open-source malware sample libraries, advanced persistent threat analysis reports, and threat analysis platform logs; the attack indicators include file hash values, IP addresses, and domain names; and the observation data includes file operation records, process operation records, registry operation records, and network connection records.
5. The method as described in claim 1, characterized in that, When converting the retrieved data into natural language description text based on a large language model, and generating system environment information corresponding to the attack technique identifier through interactive reasoning based on the natural language description text using the large language model, the process includes: Based on the large language model, the retrieved data is sequentially filled into a preset natural language template to generate the natural language description text; An initial prompt containing the attack technique identifier and the natural language description text is constructed and submitted to the large language model to obtain a preliminary answer; The initial answer is parsed, and logical consistency is checked based on the parsing results and combined with an external prior knowledge base. Follow-up questions are then generated. Based on the follow-up questions, the large language model is guided to perform at least one subsequent inference. Based on the initial response and the results of at least one subsequent inference, system environment information corresponding to the attack technique identifier is generated.
6. The method as described in claim 5, characterized in that, When filling the retrieved data into a preset natural language template in an orderly manner based on the large language model, the process includes: The behavioral category tags in the retrieved data are semantically expanded and interpreted. And / or convert the timestamps in the retrieved data to a standard date and time format; And / or mark missing or abnormal fields in the retrieved data.
7. The method as described in claim 1, characterized in that, The system environment information includes attack technique ID, system version, process list, file path list, and list of normal software and ports.
8. The method as described in claim 1, characterized in that, Based on the system environment information, when performing the operation corresponding to the attack technique identifier in the simulation environment, verifying the adaptability of the system environment information, and correcting the system environment information according to the verification results, the process includes: Based on the system environment information, configure the simulation environment; in the simulation environment, invoke the automated attack simulation framework to execute the operation sequence corresponding to the attack technique identifier; Monitor system events in the simulation environment, obtain execution trajectories, compare the execution trajectories with the expected behavior, and determine whether the attack technique corresponding to the attack technique identifier has been successfully triggered; If the system is determined to have failed to trigger, the execution trajectory is analyzed to identify environmental configuration defects. Based on these defects, suggestions for correcting the system environment information are generated, and subsequent simulation verification is iteratively optimized based on these suggestions.