Offline task package generation and result returning method for intrusion and attack simulation

Abstract

The application relates to the technical field of network security, and discloses an offline task package generation and result returning method for intrusion and attack simulation, which comprises the following steps: an attack case script, a dependent file, a task configuration file and a client script are packaged into a self-contained offline task package by a management end; an offline verification node reads the configuration file and autonomously executes all attack cases to generate a structured result compression package; and the management end imports the result compression package, analyzes execution data and calculates a security evaluation index after the result compression package is imported.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and specifically to a method for generating and transmitting offline task packages and results for intrusion and attack simulation. Background Technology

[0002] In security assessment scenarios for enterprise-critical business systems, some target business systems are physically isolated from external management systems. Security teams need to conduct intrusion and attack simulation (BAS) tests on servers in such isolated environments to evaluate their security protection capabilities.

[0003] The existing BAS platform relies on the network connectivity between the management end and the execution end when issuing attack tasks and collecting execution results. It issues tasks to the verification node through the network connection and obtains the execution results in real time.

[0004] When there is no network connectivity between the management terminal and the target node, the existing BAS platform cannot issue attack tasks to the verification nodes in the physically isolated environment, nor can it retrieve the execution results, which prevents the security team from completing attack simulation verification on critical servers in the physically isolated network. Summary of the Invention

[0005] This invention provides a method for generating offline task packages and transmitting results for intrusion and attack simulation, which solves the technical problem in related technologies that the intrusion and attack simulation verification node cannot execute attack cases, collect execution results, and transmit security assessment data normally when it is offline.

[0006] This invention discloses an offline task package generation and result feedback method for intrusion and attack simulation, comprising the following steps: The offline flag field of the target verification node is detected. When the offline flag field is true, the attack test script, dependency files, task configuration file and client script are packaged into a self-contained offline task package. Read the task configuration file on the offline verification node, execute attack cases according to the case priority and concurrency strategy, collect execution logs and screenshots, and write the blocking status and alarm status of each case into a structured result compressed package. Import the results package into the management terminal, verify consistency based on the task identifier, calculate security assessment indicators based on the blocking status and alarm status, and update the task status to complete.

[0007] Furthermore, the self-contained offline task package includes the following: a task configuration file, which includes a task identifier, a list of test case executions, and global execution parameters; execution scripts and auxiliary files for each attack test case, organized in independent subdirectories according to the test case identifier; all dependency files required for execution, uniformly placed in the dependency directory; client scripts and startup scripts adapted to different operating systems, wherein the startup scripts include automatic detection and configuration logic for the runtime environment.

[0008] Furthermore, attack test cases are executed based on test case priority and concurrency strategy, including: determining the execution order based on the priority field of each test case; determining the execution method based on the maximum concurrency number field in the global execution parameters. When the maximum concurrency is 1, all test cases are executed serially; when the maximum concurrency is greater than 1, concurrent execution is managed in a thread pool manner, and the concurrency does not exceed the upper limit of the maximum concurrency value; for test cases that declare dependencies, it is ensured that the dependent test cases have been executed before the dependent test cases start.

[0009] Furthermore, the step of writing the blocking status and alarm status of each test case into the structured result compressed package also includes: capturing the exit code of the test case execution script, and determining the execution result as one of four states: success, failure, timeout, or error based on the exit code and the predefined result code mapping table; if the execution time of the test case exceeds the timeout threshold, actively terminating the corresponding subprocess and marking the execution status as timeout; and writing the execution status, exit code, start time, end time, and execution time into the execution result summary file in a structured format.

[0010] Furthermore, security assessment metrics are calculated based on the blocking and alarm states, including: assuming the total number of use cases in the task is... The number of test cases with execution status of success or failure is The number of use cases with a blocked status is The number of use cases with an alarm status of "alarmed" is The number of use cases that were both blocked and generated alarms is Then the blocking rate Alarm rate and risk exposure rate They are respectively: ; in, Add back in the formula This is to avoid repeatedly deducting use cases that are both blocked and generate alarms.

[0011] Furthermore, this also includes based on risk exposure rates. The steps to determine the risk level by taking the value of: When When the risk level is low; when At that time, the risk level was medium; when At that time, the risk level was high; when At that time, the risk level was severe.

[0012] Furthermore, the steps for importing the result compressed package into the management terminal also include batch management operations: when selecting to add a new execution batch, the results imported this time are written to the storage as an execution round with an independent number under this task, and the total number of execution rounds of the task is incremented by one; when selecting to overwrite the current round, the execution data of the latest round is replaced with the data imported this time, keeping the round number unchanged.

[0013] Furthermore, the step of generating a structured result compressed package also includes: checking whether a baseline file for the result summary of the previous batch exists in the offline task package directory; if it exists, then traversing all result files in the current batch, calculating the SHA-256 hash value for each file, generating a hash list of files in the current batch, performing a file-by-file hash comparison with the file list array in the baseline file, identifying the set of newly added files, the set of changed files, and the set of deleted files, packaging the incremental result compressed package according to the changed set, and updating the hash list of files in the current batch to the baseline file; if it does not exist, then generating a full result compressed package and generating a baseline file to write to the offline task package directory.

[0014] Furthermore, for text files in the modified file set, the byte sequence of the corresponding files in the previous batch is used as the source file, and the byte sequence of the corresponding files in the current batch is used as the target file. A byte-level binary differential algorithm is applied to calculate differential patch data. The byte-level binary differential algorithm divides the source file and target file into blocks of fixed block length. A rolling hash value is calculated for each block of the source file to construct an index table. The rolling hash value is calculated byte by byte for the target file, and a matching block is searched in the index table. Reference instructions are generated for matching intervals, and literal instructions are generated for non-matching intervals. The reference instructions and literal instructions are combined according to the byte order of the target file to output the differential patch data. For screenshot files in the modified file set, the complete file content is retained, and the byte-level binary differential algorithm is not applied.

[0015] This invention discloses an offline task packet generation and result feedback system for intrusion and attack simulation, comprising: The task encapsulation module is used to detect the offline flag field of the target verification node. When the offline flag field is true, it packages the attack test script, dependency files, task configuration file and client script into a self-contained offline task package. The autonomous execution module is used to read the task configuration file on the offline verification node, execute attack cases according to the case priority and concurrency strategy, collect execution logs and screenshots, and write the blocking status and alarm status of each case into a structured result compressed package. The result parsing module receives the result compressed package, verifies consistency based on the task identifier, calculates security assessment indicators based on the blocking status and alarm status, and updates the task status to complete.

[0016] The beneficial effects of this invention are as follows: This invention solves the technical problem that attack simulation verification cannot be completed when there is no network connectivity between the management end and the execution end by packaging attack use case scripts, dependency files, task configuration files and client scripts into a self-contained offline task package. It achieves the technical effect of enabling the BAS system to complete the complete attack simulation verification process in a physically isolated network environment and to calculate and output structured security protection capability evaluation data through security evaluation indicators. Attached Figure Description

[0017] Figure 1 This is a flowchart of the offline task package generation and result feedback method for intrusion and attack simulation provided in this embodiment of the invention; Figure 2 This is a flowchart of the incremental execution mode of the offline task package generation and result feedback method for intrusion and attack simulation provided in the embodiments of the present invention. Detailed Implementation

[0018] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0019] Example 1 At least one embodiment of the present invention discloses an offline task package generation and result feedback method for intrusion and attack simulation, see [link to relevant documentation]. Figures 1-2 This includes the following steps: Step 1: Generate a self-contained offline task package based on the attack case configuration.

[0020] The BAS management console receives a task creation request, which includes a list of attack cases, a set of attack vector parameters for each case, global execution parameters, and the identifier of the target node. The management console checks the value of the offline flag field (offline_flag) of the target node. When offline_flag is true, the offline task processing flow is activated.

[0021] The management system creates a task record in the task database, assigns a globally unique task identifier (task_id), records the task creation timestamp (created_at), and sets the task status to running (status = running).

[0022] The management system retrieves the execution script files for each use case from the use case library storage directory based on the use case list. The execution scripts are organized in separate subdirectories according to the use case identifier (case_id). Each use case directory contains the main execution script (main.py or main.ps1) and its auxiliary files (such as payload.bin, helper.ps1, etc.).

[0023] Based on the dependency manifest file declared in each use case script, the management end collects all the dependency files required for execution, including portable runtime environment, third-party tool components and shared library files, and places them uniformly in the deps / directory of the offline task package.

[0024] The management system serializes the complete task configuration information into a JSON-formatted task configuration file (task_config.json) and places it in the root directory of the offline task package. task_config.json contains the following core fields: task_id, created_at, node_id, test case execution list (a cases array, each element containing case_id, attack vector parameter set attack_params, and execution priority), global execution parameters (global_params, containing fields such as max_concurrency, timeout_threshold, log_level, and screenshot_policy), and the offline task package format version number (package_version).

[0025] The management system packages the client script and its dependent files into the client / directory of the offline task package, and generates a startup script (run.bat) adapted for Windows system and a startup script (run.sh) adapted for Linux system in the root directory of the offline task package.

[0026] The management system packages all the aforementioned files and directories according to a predetermined structure, generating an offline task package compressed file in .zip format. The compressed file is named offline_task_{task_id}_{export_timestamp}.zip, where export_timestamp is the UTC timestamp of the export operation in the format YYYYMMDDHHmmss. The management system performs integrity verification on the compressed file, generates the SHA-256 hash digest of the offline task package and writes it to the task record, and provides the user with a download link for the compressed file.

[0027] It should be noted that the aforementioned offline flag field (offline_flag) is a boolean field written to the node attribute metadata during the node registration or administrator configuration phase. A value of true indicates that the node is an offline verification node, while a value of false indicates that the node is an online verification node. In the front-end display of the node list, offline nodes are distinguished from online nodes by recognizable visual markers, enabling users to accurately identify the node type when creating tasks.

[0028] It's important to note that the task status is set to "running" (status = running) immediately after creation, rather than "pending execution," because the actual execution of offline tasks occurs asynchronously in a physically isolated environment. The management system cannot perceive the specific execution time. Therefore, the task status is set to "running" as soon as the offline task package is exportable, allowing for a distinction at the status level between the two stages: task creation awaiting offline execution and task completion with result feedback. The status transitions of online tasks are actively controlled by the management system via the network, while the status transitions of offline tasks only occur at two moments: task creation completion and result import completion. This fundamentally differs from the status management logic of online tasks.

[0029] In this embodiment, to ensure the executability of the offline task package in a completely offline environment, the packaging of the offline task package follows the principle of self-containment: the offline task package contains all the content required for the target offline verification node to execute the task, and no additional dependencies need to be downloaded from the external network during execution. Specifically, the portable runtime environment covers the mainstream architectures of Windows (x86_64) and Linux (x86_64 and ARM64), and users do not need to pre-install any runtime environment on the target server. The startup scripts (run.bat and run.sh) both contain automatic detection and configuration logic for the runtime environment, selecting the corresponding runtime for initialization based on the current operating system type.

[0030] Step 2: Execute attack cases autonomously on the offline verification node and generate a result compressed package.

[0031] After the offline task package is transferred to the target server via a mobile storage device and decompressed, the user executes the corresponding startup script according to the operating system type, and the main entry program of the client script (client_main.py) starts immediately.

[0032] `client_main.py` reads `task_config.json` from the root directory of the offline task package, parses the `task_id`, the list of test cases, and execution parameters, and performs an integrity check on the configuration file: it compares the list of test cases recorded in `task_config.json` with the actual test case directory in the offline task package to confirm that they are consistent. If the configuration check fails, `client_main.py` outputs an error message and terminates execution.

[0033] The `scheduler.py` module determines the execution order based on the `priority` field of each test case, and determines the concurrent execution strategy based on the `max_concurrency` field in `global_params`: when `max_concurrency` is 1, all test cases are executed serially; when `max_concurrency` is greater than 1, `scheduler.py` manages concurrent execution using a thread pool, with the maximum number of concurrent executions not exceeding the upper limit of `max_concurrency`. For test cases that declare dependencies through the `depends_on` field in `task_config.json`, `scheduler.py` ensures that the dependent test cases have completed execution before the dependent test cases start.

[0034] For each test case to be executed, the client script switches to the test case directory (cases / {case_id} / ) corresponding to that test case, constructs the command-line arguments for the test case execution script based on the `attack_params` field of that test case in `task_config.json`, and calls the test case execution script (main.py or main.ps1) as a subprocess. The standard output (stdout) and standard error output (stderr) of the subprocess are appended to the test case execution log file ({case_id}_execution.log) in real time. The `result_collector.py` module calls the system screenshot interface to collect screenshots according to the screenshot policy defined by the `screenshot_policy` parameter (taking screenshots periodically at time intervals or triggering screenshots at key operation nodes). The screenshot files are named in the format `{case_id}_{sequence_number}_{timestamp}.png` and stored in the `{case_id} / screenshots / ` directory.

[0035] After the test case execution script exits, the client script captures its exit code (exit_code) and determines the execution result of this test case as one of four states: success, failure, timeout, or error, based on the exit code and the predefined result code mapping table (result_code_map). If the test case execution time exceeds the timeout threshold (in seconds) defined by timeout_threshold, scheduler.py actively terminates the subprocess and marks the execution status as timeout. The client script appends the structured execution result of this test case (containing fields such as case_id, execution_status, exit_code, start_time, end_time, and elapsed_time) in JSON format to the global result summary file (execution_summary.json).

[0036] Once all test cases in the test case list have been executed, scheduler.py records the task-level execution completion timestamp (task_end_time). result_collector.py packages all execution log files, screenshot files, and execution_summary.json into a .zip archive. The archive is named result_{task_id}_{execution_timestamp}.zip, where execution_timestamp is the UTC timestamp of the task completion, in the format YYYYMMDDHHmmss. The archive is stored in the same parent directory as the offline task package decompression directory, and the client script outputs the complete storage path of the archive to the command-line interface.

[0037] Furthermore, `execution_summary.json` contains the following fields: task identifier (`task_id`), task start time (`execution_start_time`, ISO 8601 format), task end time (`execution_end_time`, ISO 8601 format), total execution time (`total_elapsed_time`, floating-point number in seconds), execution environment information (`os_info`, including operating system type `os_type`, version string `os_version`, and processor architecture `arch`), and a list of test case results (an array of `case_results`). Each element in the `case_results` array contains: test case identifier (`case_id`), execution status (`execution_status`), exit code (`exit_code`), start time (`start_time`), end time (`end_time`), execution time (`elapsed_time`), block status (`block_status`), alarm status (`alert_status`), relative path to log file (`log_file`), and relative path to screenshot directory (`screenshot_dir`).

[0038] The block_status and alert_status fields are written to the test case level result file by the test case execution script during execution based on the actual detected system responses (such as firewall blocking, EDR alarms, etc.). result_collector.py extracts and summarizes the results from each test case result file into execution_summary.json.

[0039] It should be noted that the name of the above-mentioned result compressed package includes "execution_timestamp". When there are multiple execution results under the same task_id, this "execution_timestamp" can be used as a reference to distinguish different execution batches. The value of "execution_timestamp" is the UTC timestamp of the time when the task execution is completed. It is independent of "export_timestamp" in the task creation stage. Together, they form a complete time chain from the export of the offline task package to the generation of results.

[0040] In this embodiment, to adapt the client script to heterogeneous isolated environments, the client script is written in Python and is compatible with Python 3.6 and above. The portable Python runtime included in the offline task package covers mainstream architectures such as Windows (x86_64) and Linux (x86_64 and ARM64). The client script does not initiate any external network requests throughout step 2; all files required for execution come from the local offline task package, ensuring the solution's adaptability to completely offline environments.

[0041] Step 3: Import the result compressed package into the management terminal and parse it to generate security assessment indicators.

[0042] After the compressed package is transferred back to the BAS management environment via a mobile storage device, the user finds the corresponding offline task entry in the task list, triggers the import result operation, and the system pops up an import dialog box and provides batch management options.

[0043] After the user selects the processing method (adding a new batch or overwriting the current round's results) and uploads the result compressed file, the BAS management backend's result parsing engine decompresses the result compressed file to the server's temporary working directory, reads the `task_id` field from `execution_summary.json`, and compares it with the `task_id` of the task record corresponding to the current operation to confirm consistency. If the `task_id` does not match, the system returns an error message and terminates the import operation.

[0044] The result parsing engine extracts task-level execution metadata from execution_summary.json, including fields such as execution_start_time, execution_end_time, total_elapsed_time, and os_info, and writes it into the corresponding batch data of the task record.

[0045] The results parsing engine processes each test case result entry in the case_results array one by one. Based on the case_id, it looks up the corresponding test case record in the task test case list, writes the values ​​of fields such as execution_status, exit_code, start_time, end_time, elapsed_time, block_status, and alert_status into the result fields of the corresponding test case record, imports the contents of each test case execution log file into the log storage system, uploads the screenshot files to the file storage system, and establishes associations with the corresponding test case result records.

[0046] After all use case-level data is parsed, the result parsing engine calculates task-level security assessment metrics based on the block_status and alert_status statistics of each use case. Assume the task contains... There are 10 use cases, among which The total number of use cases in the task; the number of use cases with an execution status of success or failure (i.e., having produced a valid execution result) is [number missing]. The number of use cases where `block_status` is "blocked" is [number missing]. The number of test cases where `alert_status` is `alerted` is... The number of use cases that were both blocked and generated alarms is The blocking rate (Block Rate) Alert Rate ) and Risk Exposure Rate The calculation formulas for ) are defined as follows: ; ; ; in, Add back in the formula The purpose is to avoid deducting use cases that are both blocked and generate alarms repeatedly. The results of the above metric calculations are written to the statistics field of the task record as floating-point numbers with two decimal places.

[0047] The result parsing engine is based on The risk level is determined according to the following mapping rules: The risk level is low. The risk level is medium. The risk level is high. The risk level is severe.

[0048] After all parsing and statistical calculations are completed, the result parsing engine updates the task status from running (status = running) to completed (status = completed) and writes the completion timestamp of this import operation into the import_completed_at field of the task record.

[0049] It should be noted that the "Add Execution Batch" option in the batch management settings refers to using the imported results as a uniquely numbered execution round (round_id) for this task. The system increments the total number of execution rounds (execution_round) by one and uses execution_timestamp as the execution time stamp for this batch. "Overwrite Current Round Results" means replacing the existing execution data of the latest round (current_round_id) with the imported data, while maintaining the round number. The "Add Execution Batch" option is suitable for scenarios where the same offline task needs longitudinal comparative analysis after multiple executions at different time points or under different target environments. The "Overwrite Current Round Results" option is suitable for scenarios where corrected results need to be re-uploaded within the same batch due to execution anomalies or corrupted result files.

[0050] In this embodiment, to support longitudinal comparative analysis of execution results across multiple batches, based on step 3, the management task details page supports switching between different batches to view execution results by round, and provides a cross-batch data comparison view to demonstrate the changing trend of security protection capabilities over time. The task-level statistical view displays the risk level assessment results in chart form. , , The system displays security metrics and the distribution of test cases at each execution state, providing multiple batch timeline views. A detailed list of test case-level results is presented in tabular form, row by row, showing the execution status, verification results, blocking status, alarm status, and execution time for each test case. Users can click on any test case row to expand and view the complete execution log and screenshots of the execution process. Furthermore, the management interface supports generating test reports based on the above data, including basic task information, execution environment information, task-level statistical summaries, detailed results for each test case, and security improvement suggestions. These reports can be exported in multiple formats, including PDF and Excel.

[0051] On the other hand, this invention also proposes an offline task package generation and result feedback system for intrusion and attack simulation, including: The task encapsulation module is used to receive task creation requests, detect the offline flag field of the target node, package the attack test script, dependency files, task configuration files and client scripts into a self-contained offline task package, and provide users with a compressed package download link; The autonomous execution module is used to read the task configuration file on the offline verification node, execute all attack cases in sequence according to the test case priority and concurrency strategy, collect execution logs and screenshots, and package the execution results into a structured result compressed package after all test cases have been executed. The result parsing module receives the compressed result package uploaded by the user, verifies the consistency between the result and the task record based on the task_id, maps the structured execution data to the corresponding test case record, and calculates the result based on block_status and alert_status. , , The task status is updated to complete, including safety assessment indicators and risk levels. The batch management module provides two processing modes during the result import process: adding new execution batches and overwriting the current round. It supports independent management and longitudinal comparative analysis of data from multiple executions of the same offline task.

[0052] By way of example, the system proposed in this invention may also include various features and combinations thereof in the method embodiments, which will not be elaborated here.

[0053] This invention integrates attack test case scripts, dependency files, task configuration files, and client scripts into a self-contained compressed package during the task encapsulation phase. This allows offline verification nodes to operate without relying on any external network connection during the execution phase, thus overcoming the fundamental limitation that attack tasks cannot be issued when there is no network connectivity between the management end and the execution end. This enables the BAS system to complete the entire attack simulation verification process in a physically isolated network environment.

[0054] By introducing an offline flag field (offline_flag) into the metadata of the verification node attributes, the task management module automatically identifies offline scenarios and activates differentiated status transition logic during the task creation phase: the task status is directly set to "in execution" when creation is complete, and updated to "complete" when the result import is complete, so that the semantics of the task status are consistent with the actual execution progress throughout the entire lifecycle, avoiding deviations between the task status and the actual progress when the execution time is not perceived.

[0055] Consistency checks are performed based on task_id during the result parsing phase, and based on block_status and alert_status... , , The formula defines and calculates security assessment indicators. After the management end completes the result import, it can directly output structured security protection capability assessment data and present offline test results in an interface format that is completely consistent with online tasks. This eliminates the need for security teams to learn additional operating procedures for offline scenarios and achieves a unified management experience for online and offline tasks.

[0056] Example 2 In the offline BAS execution scenario described in Example 1, the security team needs to repeatedly trigger BAS simulation tasks for the same isolated target environment due to security policy adjustments. Between adjacent execution batches, the execution paths, log contents, and screenshot files of many attack cases are highly similar, but each time a full-result compressed package is generated and transferred via a mobile storage device following step 2 of Example 1, causing the required capacity of the mobile storage device to increase linearly with the number of execution batches. Simultaneously, the management end independently stores the full data for each batch, resulting in redundant storage of a large amount of duplicate content. Furthermore, each time a large-capacity storage device needs to be physically transferred, increasing the frequency of manual operations and the probability of errors.

[0057] Based on Example 1, this implementation introduces a batch difference identification mechanism based on SHA-256 hash comparison and a byte-level binary differential algorithm at the execution end. Only the content that has actually changed in the current batch relative to the previous batch is packaged into an incremental result compressed package and written to the mobile storage device. At the management end, the incremental data is restored to the complete batch record through a patch merging operation, and then the standard security assessment index calculation process is triggered, thereby solving the problem of redundant transmission and redundant storage in the scenario of repeated execution of multiple batches.

[0058] At least one embodiment of the present invention discloses an offline task package generation and result feedback method for intrusion and attack simulation, comprising the following steps: Step 2-1: Generate a self-contained offline task package based on the attack case configuration.

[0059] The same as step 1 in Example 1.

[0060] Step 2-2: Autonomously execute attack cases and detect the baseline files of the preceding batch on the offline verification node.

[0061] Step 2-2 may specifically include: The process is the same as step 2 in Example 1, where client_main.py reads task_config.json, scheduler.py executes all attack cases based on priority and max_concurrency, result_collector.py collects execution logs and screenshot files, and the client script generates execution_summary.json.

[0062] After all test cases have been executed, the client script checks if a previous batch result summary baseline file (previous_round_manifest.json) exists in the offline task package directory. previous_round_manifest.json records a mapping list of relative paths and corresponding SHA-256 hash values ​​for each result file in the previous batch. Its structure includes the following fields: task identifier (task_id), previous batch number (round_id), previous batch execution timestamp (execution_timestamp), and a file manifest array (file_manifest). Each element in the file_manifest array contains the relative path (relative_path) and the corresponding SHA-256 hash value (sha256) of the result file.

[0063] If previous_round_manifest.json does not exist, the current batch is considered to be executed for the first time. The client script generates a full result compressed package (result_{task_id}_{execution_timestamp}.zip) according to the compressed package naming rules in step 2 of Example 1, and synchronously generates previous_round_manifest.json for the current batch and writes it to the offline task package directory, and the execution process terminates.

[0064] It's important to note that the `previous_round_manifest.json` file is written to the offline task package directory rather than inside the result package because it needs to be read by the client script during the next batch execution for inter-batch hash comparison. Once the removable storage device transmits the result package to the management terminal, the next time the task is executed, it will still carry the same removable storage device or the same offline task package directory. The `previous_round_manifest.json` file will then serve as persistent baseline information across batches, remaining in the execution environment.

[0065] Steps 2-3: Calculate the hash list of files in the current batch.

[0066] When previous_round_manifest.json exists, result_collector.py iterates through all result files generated in the current batch, calculates the SHA-256 hash value for each execution log file ({case_id}_execution.log), screenshot file ({case_id}_{sequence_number}_{timestamp}.png), and execution_summary.json, and generates a hash list of files for the current batch (current_round_manifest). Its data structure is the same as the file_manifest array in previous_round_manifest.json. Each record contains the relative path (relative_path) of the result file and the corresponding SHA-256 hash value (sha256).

[0067] In this embodiment of the application, in order to maintain the comparability of relative paths in the hash list between batches, result_collector.py uniformly records the relative paths of each result file with the offline task package decompression directory as the root directory when calculating the hash list, which is consistent with the path representation benchmark of the file_manifest array in previous_round_manifest.json, thereby ensuring the correct correspondence of path indexes during subsequent file-by-file hash comparison.

[0068] Steps 2-4: Identify the set of file changes between batches.

[0069] Perform a file-by-file hash comparison between current_round_manifest and the file_manifest array in previous_round_manifest.json to identify the following three types of file sets: New file collection ( The relative_path contains files that exist in current_round_manifest but not in file_manifest, and usually corresponds to the execution result files or screenshot files of test cases added in the current batch. Change file collection ( The relative path exists in both current_round_manifest and file_manifest, but the SHA-256 hash values ​​are different, i.e., files whose content has changed. Delete file collection ( ): relative_path refers to files that exist in file_manifest but not in current_round_manifest, i.e., files that will no longer be generated in the current batch.

[0070] Files with identical hash values ​​are not included in any change set, and their contents are not written into the transmission data of this batch.

[0071] It should be noted that the relative path matching in the above hash comparison is based on byte-level precise string matching. The directory separator in the path is uniformly standardized to forward slash ( / ) under different operating systems before comparison, so as to avoid misjudgment caused by differences in path representation when executing across platforms.

[0072] Steps 2-5: Generate an incremental result compressed package and update the baseline file.

[0073] right The text files (including execution_summary.json and the execution log files {case_id}_execution.log for each test case) use the byte sequence of the corresponding file in the previous batch as the source file and the byte sequence of the corresponding file in the current batch as the target file. The differential patch data (patch_data) is calculated using a byte-level binary differential algorithm. The patch_data is named with the .patch suffix and the relative path is consistent with the original file.

[0074] right The screenshot binary file ({case_id}_{sequence_number}_{timestamp}.png) retains the complete file content of the current batch and does not apply byte-level binary differential algorithms.

[0075] Generate a file change list (delta_manifest.json) and record it. , , The relative path list of each file in the three file sets, and Each file in the delta_manifest.json file is marked with its processing mode (patch or full, corresponding to text files that have been differentiated and binary files that retain their full content, respectively). The delta_manifest.json file contains the following fields: task identifier (task_id), current batch number (round_id), previous batch number (base_round_id), current batch execution timestamp (execution_timestamp), list of added files (added, each element containing relative_path), list of modified files (modified, each element containing relative_path and processing mode marker mode), and list of deleted files (deleted, each element containing relative_path).

[0076] The differential patch data file, The complete binary file of the Chinese text. The complete contents of all files, including delta_manifest.json, are packaged together into an incremental result compressed package, named delta_result_{task_id}_{round_id}_{execution_timestamp}.zip, and written to a removable storage device.

[0077] After packaging is complete, the client script overwrites the current_round_manifest of the current batch in the previous_round_manifest.json file in the offline task package directory for use in the next batch execution, and updates the round_id and execution_timestamp fields in previous_round_manifest.json to the corresponding values ​​of the current batch.

[0078] In this embodiment of the application, in order to balance patch size and computational overhead in the selection of byte-level binary differential algorithms, a block matching strategy based on sliding window hashing is adopted, and the specific steps are as follows: Step 1: Divide the source file (the file corresponding to the previous batch) and the target file (the file corresponding to the current batch) into blocks of fixed block lengths respectively; Step 2: Calculate the rolling hash value for each block of the source file and construct an index table with the hash value as the key and the block offset and block length as the value; Step 3: Calculate the rolling hash value byte by byte for the target file and search for matching blocks in the index table mentioned above; Step 4: For target file byte ranges that match in the index table, record the offset and block length of the corresponding block in the source file and generate reference instructions; for target file byte segments that cannot be matched in the index table, record their original byte content and generate literal instructions. Step 5: Alternately combine reference instructions and literal instructions according to the byte order of the target file to output the patch_data binary sequence. The management terminal can then reconstruct the complete byte content of the target file based on the patch_data binary sequence.

[0079] Steps 2-6: Import the incremental result compressed package into the management terminal and restore the complete batch data.

[0080] Steps 2-6 may specifically include: Users find the corresponding offline task entry in the task list, trigger the import result operation, and upload an incremental result compressed package (delta_result_{task_id}_{round_id}_{execution_timestamp}.zip).

[0081] The result parsing engine decompresses the incremental result package to a temporary working directory on the server, reads the `task_id` field from `delta_manifest.json`, and compares it with the `task_id` of the task record corresponding to the current operation to confirm consistency. Simultaneously, it reads the `base_round_id` field to confirm the existence of the corresponding complete result data from the previous batch (`base_round_id`) in the management storage system, serving as the source data basis for the patch merging operation. If the `task_id` does not match or the batch data corresponding to `base_round_id` does not exist, the system returns an error message and terminates the import operation.

[0082] The result parsing engine, based on each entry in the modified list of delta_manifest.json, reads the original file byte sequence of the corresponding relative_path under the base_round_id batch from the management storage system for files marked with mode as patch. This sequence is then merged with the corresponding .patch file in the incremental compressed package using the reference and literal instruction sequences defined in steps 2-5 to restore the complete byte content of the corresponding file in the current batch. For files marked with mode as full, the complete file content is directly extracted from the incremental compressed package. For files in the added list, the complete file content is directly extracted from the incremental compressed package and written to the current batch storage area. For files in the deleted list, the corresponding file association is removed from the current batch records.

[0083] After restoring the incremental data to the full batch records, the result parsing engine reads the restored execution_summary.json and processes it according to the definition in step 3 of Example 1. , , The formula and risk level mapping rules calculate the security assessment indicators, update the task status to completed (status = completed), write the import_completed_at field to the task record, and trigger the standard security assessment report generation process.

[0084] It should be noted that the above-mentioned base_round_id field confirmation step requires that the import order of the incremental compressed packages be consistent with the batch generation order, that is, the order of the batch generation order. Incremental compressed packages in batches must be in the first... Batch result data (full or restored complete batch data) can only be imported after it has been written to the management storage system. This is the batch number. If the batch import order is disordered due to manual operation, the system will return a clear error message when the verification based on base_round_id fails, indicating that the result data of the batch corresponding to base_round_id should be imported first.

[0085] In this embodiment of the application, in order to support backtracking verification of multiple batches of incremental import results on the management side, after completing the restoration operation of each batch, the result parsing engine recalculates the SHA-256 hash value of the restored execution_summary.json and compares it with the corresponding hash value recorded in the current_round_manifest of the current batch (identified by the round_id in delta_manifest.json). If they match, the integrity of the restoration result is confirmed.

[0086] On the other hand, this invention also proposes an offline task package generation and result feedback system (incremental mode) for intrusion and attack simulation, including: The task encapsulation module is used to receive task creation requests, detect the offline flag field of the target node, and package the attack test script, dependency files, task configuration files and client scripts into a self-contained offline task package. The autonomous execution module is used to execute all attack cases on the offline verification node, collect execution logs and screenshots, generate execution_summary.json, and check whether previous_round_manifest.json exists in the offline task package directory to determine whether the current batch is the first execution or a subsequent execution. The hash comparison module iterates through all result files in the current batch to calculate the SHA-256 hash list, performs a file-by-file hash comparison with the file_manifest array in previous_round_manifest.json, and outputs the set of newly added files. Change file collection and the collection of deleted files ; Incremental packaging module, used for... The text files in the file are processed using a byte-level binary differential algorithm to generate patch_data. The screenshot files retain their complete content, generate delta_manifest.json, and package the above content into an incremental result compressed package and write it to the mobile storage device, while updating previous_round_manifest.json; The patch restoration module is used to receive the incremental result compressed package on the management side, perform consistency verification based on the task_id and base_round_id in delta_manifest.json, perform patch merging operation to restore the complete file content of the current batch, and trigger the security assessment index calculation and task status update process.

[0087] By way of example, the system proposed in this invention may also include various features and combinations thereof in the method embodiments, which will not be elaborated here.

[0088] This invention introduces a batch-to-batch file change identification mechanism based on SHA-256 hash comparison at the execution end, which accurately distinguishes between the set of files whose content has actually changed and the set of files whose content has not changed between adjacent batches. This ensures that the data written to the mobile storage device only contains the content that has actually changed, thus overcoming the problem that the capacity required by the mobile storage device increases linearly with the number of batches in scenarios of repeated execution in multiple batches.

[0089] for The text-based execution log files in the system use a byte-level binary differential algorithm to extract only the changes relative to the previous batch to generate patch_data. This further compresses the amount of transmitted data corresponding to this type of file to the actual change scale, rather than the complete file size. In typical scenarios where the log content of adjacent batches is highly similar, this can effectively reduce the size of the incremental compressed package.

[0090] On the management side, the complete file content of each batch is restored from the incremental data through patch merging before being written to the batch storage record. This ensures that the data of each batch stored on the management side remains complete and independently searchable. Furthermore, since duplicate content is no longer repeatedly transferred via removable storage devices, the management side does not need to allocate new storage space for any transferred duplicate content, thus avoiding redundant storage. The reduction in storage capacity required for each physical transfer directly reduces reliance on large-capacity storage devices, decreases the frequency of manual handling and operations, and thereby reduces the probability of errors during physical transfer in an isolated environment.

[0091] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A method for generating offline task packages and transmitting results for intrusion and attack simulation, characterized in that, Includes the following steps: The offline flag field of the target verification node is detected. When the offline flag field is true, the attack test script, dependency files, task configuration file and client script are packaged into a self-contained offline task package. Read the task configuration file on the offline verification node, execute attack cases according to the case priority and concurrency strategy, collect execution logs and screenshots, and write the blocking status and alarm status of each case into a structured result compressed package. Import the results package into the management terminal, verify consistency based on the task identifier, calculate security assessment indicators based on the blocking status and alarm status, and update the task status to complete.

2. The method for generating offline task packages and transmitting results for intrusion and attack simulation according to claim 1, wherein, The self-contained offline task package includes the following: a task configuration file, which contains a task identifier, a list of test cases to be executed, and global execution parameters; execution scripts and auxiliary files for each attack test case, organized in independent subdirectories according to the test case identifier; and all dependency files required for execution, placed uniformly in the dependency directory. The client script and the startup script adapted to different operating systems include automatic detection and configuration logic for the runtime environment.

3. The method for generating offline task packages and transmitting results for intrusion and attack simulation according to claim 1, wherein, Attack test cases are executed based on test case priority and concurrency strategy, including: determining the execution order based on the priority field of each test case; determining the execution method based on the maximum concurrency number field in the global execution parameters. When the maximum concurrency is 1, all test cases are executed serially; when the maximum concurrency is greater than 1, concurrent execution is managed by a thread pool, and the concurrency does not exceed the upper limit of the maximum concurrency value; for test cases that declare dependencies, it is ensured that the dependent test cases have been executed before the dependent test cases start.

4. The method for generating offline task packages and transmitting results for intrusion and attack simulation according to claim 1, wherein, The steps of writing the blocking status and alarm status of each test case into the structured result compressed package also include: capturing the exit code of the test case execution script, and determining the execution result as one of four states: success, failure, timeout, or error based on the exit code and the predefined result code mapping table; if the execution time of the test case exceeds the timeout threshold, actively terminating the corresponding subprocess and marking the execution status as timeout; and writing the execution status, exit code, start time, end time, and execution time into the execution result summary file in a structured format.

5. The method for generating offline task packages and transmitting results for intrusion and attack simulation according to claim 1, wherein, Security assessment metrics are calculated based on the blocking and alarm states, including: assuming the total number of use cases in the task is... The number of test cases with execution status of success or failure is The number of use cases with a blocked status is The number of use cases with an alarm status of "alarmed" is The number of use cases that were both blocked and generated alarms was Then the blocking rate Alarm rate and risk exposure rate They are respectively: ； in, Add back in the formula This is to avoid repeatedly deducting use cases that are both blocked and generate alarms.

6. The method for generating offline task packages and transmitting results for intrusion and attack simulation according to claim 5, wherein, This also includes based on risk exposure rate The steps to determine the risk level by taking the value of: When When the risk level is low; when At that time, the risk level was medium; when At that time, the risk level was high; when At that time, the risk level was severe.

7. The method for generating offline task packages and transmitting results for intrusion and attack simulation according to claim 1, wherein, The steps to import the results compressed package into the management terminal also include batch management operations: when selecting to add a new execution batch, the results imported this time are written to the storage as an execution round with an independent number under this task, and the total number of execution rounds of the task is incremented by one; When selecting to overwrite the current round, the data imported this time will replace the execution data of the latest round, while keeping the round number unchanged.

8. The method for generating offline task packages and transmitting results for intrusion and attack simulation according to claim 1, wherein, The step of generating a structured result compressed package also includes: checking whether a baseline file for the result summary of the previous batch exists in the offline task package directory; if it exists, iterating through all result files in the current batch, calculating the SHA-256 hash value for each file, generating a hash list of files in the current batch, performing a file-by-file hash comparison with the file list array in the baseline file, identifying the set of newly added files, the set of changed files, and the set of deleted files, packaging the incremental result compressed package according to the changed set, and updating the hash list of files in the current batch to the baseline file; if it does not exist, generating a full result compressed package and generating a baseline file to write to the offline task package directory.

9. The method for generating offline task packages and transmitting results for intrusion and attack simulation according to claim 8, wherein, For text files in the modified file set, the byte sequence of the corresponding files in the previous batch is used as the source file, and the byte sequence of the corresponding files in the current batch is used as the target file. A byte-level binary differential algorithm is applied to calculate differential patch data. The byte-level binary differential algorithm divides the source file and target file into blocks of fixed block length. A rolling hash value is calculated for each block of the source file to build an index table. The rolling hash value is calculated byte by byte for the target file, and matching blocks are searched in the index table. Reference instructions are generated for matching intervals, and literal instructions are generated for non-matching intervals. The reference instructions and literal instructions are combined according to the byte order of the target file to output the differential patch data. For screenshot files in the modified file set, the complete file content is retained, and the byte-level binary differential algorithm is not applied.

10. An offline task package generation and result feedback system for intrusion and attack simulation, characterized in that, include: The task encapsulation module is used to detect the offline flag field of the target verification node. When the offline flag field is true, it packages the attack test script, dependency files, task configuration file and client script into a self-contained offline task package. The autonomous execution module is used to read the task configuration file on the offline verification node, execute attack cases according to the case priority and concurrency strategy, collect execution logs and screenshots, and write the blocking status and alarm status of each case into a structured result compressed package. The result parsing module receives the result compressed package, verifies consistency based on the task identifier, calculates security assessment indicators based on the blocking status and alarm status, and updates the task status to complete.

Images