Dynamic updating method and system for network security attack and defense drilling range flag
By monitoring the kernel layer and generating multi-dimensional traceability information in the flag file update method in the network security attack and defense exercise range, the problems of easy leakage and forgery of static management are solved. It realizes dynamic binding of flag file with access behavior and tamper-proof audit records, thereby improving the authenticity and credibility of the exercise.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-02-27
- Publication Date
- 2026-05-15
AI Technical Summary
In existing cybersecurity attack and defense drills, the static management of flag files is easily leaked and forged, lacks correlation with access behavior, resulting in insufficient realism and traceability of the drills. Traditional update mechanisms are easily circumvented, auditing mechanisms lack cross-version correlation and verification, and log systems are easily tampered with.
The system monitors access to the flag file at the target host kernel level, collects multi-dimensional traceability information to generate a new flag, embeds chained verification fields using HMAC or signature hash algorithms, employs temporary file atomic replacement and TLS encrypted channel transmission, and combines chained hash notarization to ensure the integrity and credibility of the update.
Dynamic binding of flag files to access behavior was implemented to prevent forgery and rollback, improve the authenticity and traceability of exercise results, form an immutable audit record system, and enhance the reliability and evidence collection capabilities of the exercise process.
Smart Images
Figure CN122053031A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of network and information security technology, specifically a method and system for dynamically updating flags in a network security attack and defense exercise range. Background Technology
[0002] Network attack and defense drills have become a common method in network security assurance in recent years. During the drills, it is usually necessary to set up verification targets in the target environment to verify whether the attacker has truly completed the penetration path. As a common verification mechanism, flag files are widely used in existing systems. Attackers obtain the flag file in the target host to prove that they have achieved a breakthrough. However, in actual use, the traditional flag file management method has obvious shortcomings.
[0003] First, flag files typically exist with fixed content. Once leaked, attackers can submit results using this content without actually completing the attack process, thus weakening the authenticity and effectiveness of the exercise. Second, the flag file remains unchanged during repeated accesses, lacking a connection with the access behavior or operating environment, and cannot reflect the completeness and traceability of the attack path. Some existing improvement measures attempt to update the flag content through periodic refreshes or manual resets, but the frequency and granularity of updates are low, making it easy for attackers to circumvent checks using forgery or rollback techniques.
[0004] On the other hand, although auditing mechanisms have been applied in relevant systems, they are mostly concentrated at the level of routine log recording and lack direct correlation with the dynamic changes of the flag file. When there are multiple processes accessing the file concurrently, the flag file may experience incomplete overwriting, abnormal writing, or inconsistent status during the update process, resulting in a discrepancy between the log record and the file status, thereby reducing the credibility of the audit. At the same time, traditional log systems are mostly single-point storage and lack cross-version correlation and verification mechanisms, making them easy to be tampered with or deleted afterward, posing a risk to result verification and traceability. Summary of the Invention
[0005] The purpose of this invention is to provide a method and system for dynamically updating flags in a network security attack and defense exercise range, so as to solve the problems mentioned in the background art.
[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for dynamically updating flags in a network security attack and defense exercise range, the specific steps of which are as follows: On the target host, listen for access events to the pre-set flag file used for drill verification in order to detect file read operations; When a read operation is detected, the source information corresponding to the operation is collected. The source information includes at least the access process identifier, the hash value of the executable file, the parent process chain, the call stack call point, and the summary information of the process memory page. The source information is combined with the target host's unique identifier, event timestamp, and incrementing counter and input into an HMAC or signature hash algorithm to generate new flag content bound to the read operation. The hash value of the previous version of the flag is embedded in the flag content to form a chained verification field. The new flag content is written to a temporary file, and after synchronous disk writing, the original flag file is atomically replaced by renaming. At the same time, an audit record containing the old version hash, the new version hash, the traceability signature and the event timestamp is generated and reported to the central control platform through an encrypted channel with TLS two-way authentication. The central control platform verifies the received audit records using signature verification and chain verification, and stores the results in an immutable log system based on a chain hash structure. When rollback or forgery signs are detected, an anomaly alarm is triggered.
[0007] Preferably, the target host needs to listen for access events to the preset flag file. This listening operation is completed at the kernel level to ensure that the access behavior of all processes can be captured in a timely manner. Specifically, in a Linux system environment, the fanotify interface can be called to establish monitoring of file access events, or the open, read and other operations of files can be tracked in kernel mode through an eBPF-based system call probe. In a Windows system environment, the same monitoring effect can be achieved through file system filter drivers or object access auditing mechanisms. When the monitoring module detects a process reading the flag file, it immediately triggers an information collection process. This information collection is not limited to the traditional process ID, but also includes: the process identifier of the accessing process, the hash value of the executable file (such as the SHA256 value, used to uniquely identify the executable file), the parent process chain relationship of the process (recording its call source and inheritance relationship), the call stack entry point that triggered the call (obtainable via kprobe or bpftrace in Linux environment, and via ETW events or debugging API in Windows environment), and the hash digest of the memory pages currently occupied by the process (obtained by calculating the hash value of the memory pages in blocks).
[0008] By jointly collecting the aforementioned multi-dimensional data, the generated flag is not only associated with the reading behavior, but also bound to the actual operating environment that initiated the access. This approach differs from existing technologies that rely solely on a single identifier (such as a PID or username), significantly improving the accuracy of traceability and anti-counterfeiting capabilities.
[0009] Preferably, after the source information collection is completed, the flag generation process is started. This process first combines the source information with the target host's unique identifier (such as host UUID, TPM chip identifier or network card MAC address), the precise timestamp of the event, and an incrementing counter to form complete input data. The incrementing counter is automatically incremented by one each time an access event is triggered to prevent the same flag from being generated repeatedly at the same time. Subsequently, the flag generation unit calls the HMAC algorithm or digital signature hash algorithm (such as ECDSA, RSA-SHA256) to calculate the input data and output a unique new flag content. The hash value of the previous version of the flag is also written into the new flag content to build a continuous chain of verification fields. In this way, the generation of each new flag depends on the hash value of the previous version, thus forming a traceable chain. Existing technologies mostly use timestamps or random numbers to directly generate flags. Although these flags can change, they lack binding to the operating environment and continuity across versions. The generation mechanism of this invention utilizes traceability data, unique device identifiers, counters, and chained verification fields in its design, forming an unforgeable and unskippable flag evolution path.
[0010] Preferably, the newly generated flag is not written directly to the original file, but is updated using a temporary file + atomic replacement method. Specifically, the new flag content is first written to a temporary file in the same directory as the original flag file; after writing is completed, the file system's synchronous disk write operation is called immediately, which calls fsync under Linux and FlushFileBuffers under Windows to ensure that the data is indeed written to the disk. After the disk is written, the temporary file is replaced with the original flag file through the file system renaming operation. In Linux, rename is called and in Windows, MoveFileEx is called and an atomicity flag is set. In order to avoid data inconsistency in a concurrent access environment, this invention combines file locks or process locks during the replacement process to ensure that multiple access threads do not modify the flag file at the same time. After the replacement operation is completed, the system will generate an audit record. The audit record contains the hash value of the old version flag, the hash value of the new version flag, the event signature generated by the traceability information, and the timestamp of the event. The generated audit record is encrypted and transmitted to the central control platform through a two-way certificate authentication channel based on the TLS protocol to ensure the integrity and authenticity of the transmission process. Compared with existing technologies that directly overwrite file updates, this invention adopts a complete chain of temporary file writing + synchronous disk writing + atomic renaming + locking, avoiding problems such as file corruption, rollback, or concurrent conflicts, thereby achieving reliable dynamic flag updates and security auditing.
[0011] Preferably, after receiving the audit record, the central control platform first performs public key verification on the event signature to verify whether the record was generated by a legitimate node; after the verification is successful, it reads the chain verification field carried in the audit record and compares it with the previous version flag hash value saved by the platform to confirm the continuity and integrity of the old and new flags. When the verification is successful, the audit record is written to a log database organized based on a chain hash structure. The log database can adopt a sequential linked list structure or a Merkle tree structure. Each new record contains the hash value of the previous record, thus forming an immutable chain evidence storage system. If a mismatch in chained fields or an invalid event signature is found during the verification process, the platform will immediately generate an exception alarm and trigger a preset security response process. Unlike existing technologies that only store ordinary logs or single signatures, the platform processing method of this invention forms a triple guarantee of signature verification + chain verification + tamper-proof evidence storage, which can effectively prevent rollback attacks and forgery, and ensure the integrity and trustworthiness of the flag update chain.
[0012] This invention also proposes a dynamic flag update system for a network security attack and defense exercise range. This system is based on the above method and includes: The event listening unit is used to monitor the reading operation of the preset flag file on the target host and trigger information collection when the operation is detected. The information acquisition unit is used to collect the access process identifier, the hash value of the executable file, the parent process chain, the call stack call point and the memory page summary after the event listening unit is triggered, and output the information to the generation unit; The flag generation unit is used to receive the data output by the information collection unit, and combine it with the host unique identifier, event timestamp and incrementing counter to generate new flag content through HMAC or signature hash algorithm, and embed the hash value of the previous version flag into the new flag to form a chain verification field. The update and audit unit is used to replace the original flag file by writing and renaming temporary files after receiving the new flag generated by the flag generation unit, and to ensure concurrency consistency by combining file locks or process locks. At the same time, it generates an audit record containing chained hashes and traceability signatures, and reports it to the central control platform through a TLS two-way authentication channel. The platform performs signature verification, chained verification and stores it in an immutable log system based on a chained hash structure.
[0013] Preferably, the event listening unit captures access behavior to the preset flag file in real time through the underlying file system monitoring mechanism. Specifically, in the Linux environment, the event listening unit can call the fanotify interface to intercept open, read and other operation events of the flag file under the specified path. It can also achieve fine-grained tracking of file access through the eBPF-based system call probe. In a Windows environment, kernel-level file access monitoring can be achieved through file system filter drivers, or object access auditing mechanisms can be invoked to capture read requests to the flag file. When a read operation of the flag file is detected, the event listening unit immediately outputs a trigger signal and transmits the signal to the information acquisition unit to ensure that the runtime environment data associated with the operation can be accurately obtained. This design ensures that the entire system can start the tracing link instantly when the file is accessed, rather than relying on delayed log analysis.
[0014] Preferably, after receiving a trigger signal from the event monitoring unit, the information acquisition unit initiates the collection of relevant operational information. The data acquired by this unit includes: The process ID (PID) of the accessing process ensures that the accessing process is uniquely identified; The hash value of the executable file, such as calculating the SHA256 value of the executable file, to ensure that the file identity cannot be forged; Parent process chain relationship: records the parent process of this process and its call relationship, used to trace the source of the call; The call stack entry point can be obtained using kprobe or bpftrace in a Linux environment, and through ETW events or the debugging API in a Windows environment. The memory page hash digest is obtained by performing a block hash calculation on the memory pages currently occupied by the process; The collected traceability information is formatted and then transmitted to the flag generation unit as input for generating new flags. Unlike existing technologies that only collect PIDs or usernames, this unit forms multi-dimensional information input, which significantly improves the accuracy of traceability.
[0015] Preferably, after receiving the data output by the information collection unit, the flag generation unit combines the traceability information with the target host's unique identifier (e.g., host UUID, TPM chip identifier, or network card MAC address), the event occurrence timestamp (accurate to milliseconds), and an incrementing counter (incremented by one each time it is triggered to prevent replay attacks) to form complete input data. This unit calls the HMAC algorithm or digital signature hash algorithm (such as ECDSA, RSA-SHA256) to calculate the input data and outputs a new flag content that uniquely corresponds to the read operation. In the generated new flag content, the hash value of the previous version of the flag is additionally written to form a chain verification field. In this way, the flag files are continuously associated, and each update can be traced back to the previous version, avoiding forgery and rollback. The newly generated flag content is immediately output to the update and audit unit after processing. Compared with the random number or single timestamp method of the existing technology, the flag generated by this unit is bound to the runtime environment and historical version, and has continuity and is not forgery.
[0016] Preferably, after receiving the new flag content output by the flag generation unit, the update and audit unit performs the update according to the following steps: Write to temporary file: Writes the new flag content to a temporary file in the same directory as the original flag file; Synchronous disk writing: After writing is complete, the file system's synchronous disk writing function is called. In Linux systems, fsync is used, and in Windows systems, FlushFileBuffers is used to ensure that the data is truly persisted to the disk. Atomic replacement: Invokes the file system's rename operation, using rename in Linux and MoveFileEx (with atomicity flag) in Windows, to atomically replace the temporary file with the original flag file; Concurrency control: Apply file locks or process locks before and after replacement to prevent multiple processes from accessing the file simultaneously, which could lead to inconsistencies. Generate audit logs: After the replacement is complete, generate audit logs containing the old version flag hash value, the new version flag hash value, the event signature generated from the source information, and the event timestamp; Security reporting: Audit logs are transmitted to the central control platform via an encrypted channel using TLS two-way certificate authentication; After receiving the audit log, the central control platform will verify the event signature with a public key and perform continuity verification on the chained verification field. If the verification passes, the result will be written to an immutable log system based on a chained hash structure (which can be a sequential linked list or a Merkle tree structure). If an verification anomaly is found, an alarm will be generated immediately and a security response will be triggered.
[0017] Unlike existing technologies that simply overwrite files or store ordinary logs, this unit forms a complete update and audit loop through temporary file writing, synchronous disk persistence, atomic replacement, locking mechanism, TLS reporting, and platform chain-based evidence storage.
[0018] The beneficial effects of this invention are as follows: 1. This invention establishes an event listening mechanism at the target host kernel layer, enabling real-time capture of pre-defined flag file reading behavior. Upon triggering, it collects multi-dimensional tracing information, including process identifier, executable file hash, parent process chain, call stack entry point, and memory page hash. Compared with existing technologies that rely solely on process IDs or timestamps, this solution establishes a binding relationship between the flag content and the access behavior before the flag content is generated. This makes the flag no longer an independent static file, but a dynamic product corresponding to the access subject and runtime environment. This avoids the problem of bypassing penetration testing with fixed flag content and improves the authenticity and traceability of the exercise results.
[0019] 2. This invention introduces a chain-based verification and atomic replacement mechanism during the flag generation and update process. By using traceability information, host unique identifier, event timestamp, and incrementing counter as input, the new flag content generated by the encryption algorithm embeds the hash value of the previous version in its structure, forming a continuous chain dependency relationship. The update process adopts temporary file writing, synchronous disk write, and file renaming and replacement, combined with file locks or process locks to ensure consistency under concurrent access conditions. Compared with existing direct overwrite or timed refresh schemes, this mechanism not only ensures the integrity and atomicity of the update process, but also forms a continuous chain between different versions of the flag, preventing forgery and rollback, and improving the reliability of the test environment.
[0020] 3. This invention generates audit logs containing the old version hash, the new version hash, the traceability signature, and the timestamp after the update is completed. These logs are then transmitted to the central control platform via a TLS channel with two-way certificate authentication. The platform performs signature verification and chain verification, writing the results to a log database based on a chain hash structure. When inconsistencies or signs of forgery are detected, the system can immediately issue an anomaly alarm. This design keeps log auditing synchronized with flag updates and ensures the immutability of records at the storage level. Compared with traditional single-point log recording methods, this invention forms a closed-loop system from access monitoring to log evidence storage, which not only improves the credibility of audit results but also enhances the evidence collection capabilities during the exercise process. Attached Figure Description
[0021] Figure 1 This is a flowchart of the method for dynamically updating flags in a network security attack and defense exercise range according to the present invention. Figure 2 This is a flowchart of the network security attack and defense exercise range flag dynamic update system of the present invention. Detailed Implementation
[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0023] like Figures 1 to 2 As shown in the figure, this embodiment of the invention provides a method for dynamically updating flags in a network security attack and defense exercise range. The specific steps of this method are as follows: On the target host, listen for access events to the pre-set flag file used for drill verification in order to detect file read operations; When a read operation is detected, the source information corresponding to the operation is collected. The source information includes at least the access process identifier, the hash value of the executable file, the parent process chain, the call stack call point, and the summary information of the process memory page. The source information is combined with the target host's unique identifier, event timestamp, and incrementing counter and input into the HMAC or signature hash algorithm to generate a new flag content bound to the read operation. The hash value of the previous version of the flag is embedded in the flag content to form a chain of verification fields. The new flag content is written to a temporary file, and after synchronous disk writing, the original flag file is atomically replaced by renaming. At the same time, an audit record containing the old version hash, the new version hash, the traceability signature and the event timestamp is generated and reported to the central control platform through an encrypted channel with TLS two-way authentication. The central control platform verifies the received audit records by signature and performs chain verification, and stores the results in an immutable log system based on a chain hash structure. When rollback or forgery signs are detected, an anomaly alarm is triggered. Example
[0024] In a test range environment of attack and defense exercise, the target host has a pre-set flag file for verifying the breakthrough results. In order to avoid the leakage and forgery problems caused by fixed flags, this embodiment provides a dynamic update mechanism.
[0025] During the system initialization phase, the event listening module is deployed at the host kernel layer. In the Linux environment, it calls the fanotify interface to establish monitoring of the flag file in the specified directory. In the Windows environment, the same listening is achieved through the file system filter driver. When a process is detected reading the flag file, the event listening module immediately sends a trigger signal to the information collection module.
[0026] After receiving the signal, the information collection module collects source data on the access behavior. The collected data includes: the process ID (PID) of the accessing process, the hash value of the executable file corresponding to the process (calculated using the SHA256 algorithm), the parent process chain relationship (recording the source of the call), the call stack entry point (obtained via kprobe or bpftrace on Linux, and captured via ETW events on Windows), and the hash digest of the memory pages occupied by the process (the hash value is calculated block by block after dividing the memory pages). The collected data is formatted and transmitted to the flag generation module.
[0027] After receiving the traceability information, the flag generation module combines it with the target host's unique identifier (such as the host UUID), the event timestamp, and the incrementing counter, and uses this as input to call the HMAC algorithm to calculate the output result. In the generated new flag content, the hash value of the previous version of the flag is additionally written to form a chain verification field. In this way, any version of the flag is closely associated with the historical version and cannot be forged or replaced individually. The generated new flag is then passed to the update and audit module.
[0028] The update and audit module first writes the new flag content to a temporary file in the same directory as the original file. After writing, it calls fsync on Linux and FlushFileBuffers on Windows to ensure that the data is written to disk. Then, it replaces the original flag file with an atomic renaming method (call rename on Linux and MoveFileEx on Windows and set the atomicity flag). File locks or process locks are used before and after the replacement to avoid data inconsistency problems caused by concurrent access.
[0029] After the replacement is completed, the system will generate an audit record, which includes the hash value of the old version flag, the hash value of the new version flag, the event signature calculated from the traceability information, and the event timestamp. This audit record is transmitted to the central control platform in encrypted form through a two-way certificate authentication channel under the TLS protocol. The central platform first verifies the event signature with a public key, and then reads the chain verification field in the audit record and compares it with the hash value of the previous version already stored on the platform. If the verification passes, the platform writes the record to a log database based on a chain hash structure. This database can be organized in a sequential linked list or Merkle tree manner to ensure that the data is immutable. Once a verification anomaly is detected, the platform immediately triggers an alarm and notifies the operations and maintenance personnel.
[0030] This embodiment enables dynamic updating of flag files in the training environment, binding generated content with access behavior. The update process is atomic and concurrently consistent, and the audit records are continuous and tamper-proof, thus ensuring the authenticity and traceability of the training results.
[0031] The target host needs to listen for access events to a predefined flag file. This listening operation is performed at the kernel level to ensure that the access behavior of all processes can be captured in a timely manner. Specifically, in a Linux system environment, the fanotify interface can be called to establish monitoring of file access events, or a system call probe based on eBPF can be used to track file open, read and other operations in kernel mode. In a Windows system environment, the same monitoring effect can be achieved through file system filter drivers or object access auditing mechanisms. When the monitoring module detects a process reading the flag file, it immediately triggers an information collection process. This information collection is not limited to the traditional process ID, but also includes: the process identifier of the accessing process, the hash value of the executable file (such as the SHA256 value, used to uniquely identify the executable file), the parent process chain relationship of the process (recording its call source and inheritance relationship), the call stack entry point that triggered the call (which can be obtained through kprobe or bpftrace in Linux environment, and through ETW events or debugging API in Windows environment), and the hash digest of the memory pages currently occupied by the process (obtained by calculating the hash value of the memory pages in blocks).
[0032] By jointly collecting the aforementioned multi-dimensional data, the generated flag is not only associated with the reading behavior, but also bound to the actual operating environment that initiated the access. This approach differs from existing technologies that rely solely on a single identifier (such as a PID or username), significantly improving the accuracy of traceability and anti-counterfeiting capabilities.
[0033] After the source information collection is completed, the flag generation process is started. This process first combines the source information with the target host's unique identifier (such as host UUID, TPM chip identifier or network card MAC address), the precise timestamp of the event, and an incrementing counter to form complete input data. The incrementing counter is automatically incremented by one each time an access event is triggered to prevent the same flag from being generated repeatedly at the same time. Subsequently, the flag generation unit calls the HMAC algorithm or digital signature hash algorithm (such as ECDSA, RSA-SHA256) to calculate the input data and output a unique new flag content. The hash value of the previous version of the flag is also written into the new flag content to build a continuous chain of verification fields. In this way, the generation of each new flag depends on the hash value of the previous version, thus forming a traceable chain. Existing technologies mostly use timestamps or random numbers to directly generate flags. Although these flags can change, they lack binding to the operating environment and continuity across versions. The generation mechanism of this invention utilizes traceability data, unique device identifiers, counters, and chained verification fields in its design, forming an unforgeable and unskippable flag evolution path.
[0034] The newly generated flag is not written directly to the original file. Instead, it is updated using a temporary file and atomic replacement method. Specifically, the new flag content is first written to a temporary file in the same directory as the original flag file. After writing, the file system's synchronous disk write operation is called immediately. In Linux, fsync is called, and in Windows, FlushFileBuffers is called to ensure that the data is indeed written to the disk. After the disk is written, the temporary file is replaced with the original flag file through the file system renaming operation. In Linux, rename is called and in Windows, MoveFileEx is called and an atomicity flag is set. In order to avoid data inconsistency in a concurrent access environment, this invention combines file locks or process locks during the replacement process to ensure that multiple access threads do not modify the flag file at the same time. After the replacement operation is completed, the system will generate an audit record. The audit record contains the hash value of the old version flag, the hash value of the new version flag, the event signature generated by the traceability information, and the timestamp of the event. The generated audit record is encrypted and transmitted to the central control platform through a two-way certificate authentication channel based on the TLS protocol to ensure the integrity and authenticity of the transmission process. Compared with existing technologies that directly overwrite file updates, this invention adopts a complete chain of temporary file writing + synchronous disk writing + atomic renaming + locking, avoiding problems such as file corruption, rollback, or concurrent conflicts, thereby achieving reliable dynamic flag updates and security auditing.
[0035] After receiving the audit record, the central control platform first performs public key verification on the event signature to verify whether the record was generated by a legitimate node. After the verification is successful, it reads the chain verification field carried in the audit record and compares it with the previous version flag hash value saved by the platform to confirm the continuity and integrity of the old and new flags. When the verification is successful, the audit record is written to a log database organized based on a chain hash structure. The log database can adopt a sequential linked list structure or a Merkle tree structure. Each new record contains the hash value of the previous record, thus forming an immutable chain evidence storage system. If a mismatch in chained fields or an invalid event signature is found during the verification process, the platform will immediately generate an exception alarm and trigger a preset security response process. Unlike existing technologies that only store ordinary logs or single signatures, the platform processing method of this invention forms a triple guarantee of signature verification + chain verification + tamper-proof evidence storage, which can effectively prevent rollback attacks and forgery, and ensure the integrity and trustworthiness of the flag update chain.
[0036] This invention also proposes a dynamic flag update system for a network security attack and defense exercise range. This system is based on the above method and includes: The event listening unit is used to monitor the reading operation of the preset flag file on the target host and trigger information collection when the operation is detected. The information acquisition unit is used to collect the access process identifier, the hash value of the executable file, the parent process chain, the call stack call point, and the memory page summary after the event listening unit is triggered, and output the information to the generation unit; The flag generation unit receives data output from the information collection unit and combines it with the host's unique identifier, event timestamp, and incrementing counter to generate new flag content using HMAC or signature hash algorithm. The new flag also embeds the hash value of the previous version of the flag to form a chained verification field. The update and audit unit is used to replace the original flag file by writing and renaming temporary files after receiving a new flag generated by the flag generation unit. It also combines file locks or process locks to ensure concurrent consistency. At the same time, it generates an audit record containing chained hashes and traceable signatures and reports it to the central control platform through a TLS two-way authentication channel. The platform performs signature verification, chained verification and stores it in an immutable log system based on a chained hash structure.
[0037] Among them, the event listening unit captures access behavior to the preset flag file in real time through the underlying file system monitoring mechanism. Specifically, in the Linux environment, the event listening unit can call the fanotify interface to intercept open, read and other operation events of the flag file under the specified path. It can also achieve fine-grained tracking of file access through the eBPF-based system call probe. In a Windows environment, kernel-level file access monitoring can be achieved through file system filter drivers, or object access auditing mechanisms can be invoked to capture read requests to the flag file. When a read operation of the flag file is detected, the event listening unit immediately outputs a trigger signal and transmits the signal to the information acquisition unit to ensure that the runtime environment data associated with the operation can be accurately obtained. This design ensures that the entire system can start the tracing link instantly when the file is accessed, rather than relying on delayed log analysis.
[0038] Upon receiving a trigger signal from the event monitoring unit, the information acquisition unit initiates the collection of relevant operational information. The data acquired by this unit includes: The process ID (PID) of the accessing process ensures that the accessing process is uniquely identified; The hash value of the executable file, such as calculating the SHA256 value of the executable file, to ensure that the file identity cannot be forged; Parent process chain relationship: records the parent process of this process and its call relationship, used to trace the source of the call; The call stack entry point can be obtained using kprobe or bpftrace in a Linux environment, and through ETW events or the debugging API in a Windows environment. The memory page hash digest is obtained by performing a block hash calculation on the memory pages currently occupied by the process; The collected traceability information is formatted and then transmitted to the flag generation unit as input for generating new flags. Unlike existing technologies that only collect PIDs or usernames, this unit forms multi-dimensional information input, which significantly improves the accuracy of traceability.
[0039] The flag generation unit, after receiving the data output by the information collection unit, combines the traceability information with the target host's unique identifier (such as host UUID, TPM chip identifier, or network card MAC address), the event occurrence timestamp (accurate to milliseconds), and an incrementing counter (incremented by one each time it is triggered to prevent replay attacks) to form complete input data. This unit calls the HMAC algorithm or digital signature hash algorithm (such as ECDSA, RSA-SHA256) to calculate the input data and outputs a new flag content that uniquely corresponds to the read operation. In the generated new flag content, the hash value of the previous version of the flag is additionally written to form a chain verification field. In this way, the flag files are continuously associated, and each update can be traced back to the previous version, avoiding forgery and rollback. The newly generated flag content is immediately output to the update and audit unit after processing. Compared with the random number or single timestamp method of the existing technology, the flag generated by this unit is bound to the runtime environment and historical version, and has continuity and is not forgery.
[0040] Upon receiving the new flag content output by the flag generation unit, the update and audit unit performs the update according to the following steps: Write to temporary file: Writes the new flag content to a temporary file in the same directory as the original flag file; Synchronous disk writing: After writing is complete, the file system's synchronous disk writing function is called. In Linux systems, fsync is used, and in Windows systems, FlushFileBuffers is used to ensure that the data is truly persisted to the disk. Atomic replacement: Invokes the file system's rename operation, using rename in Linux and MoveFileEx (with atomicity flag) in Windows, to atomically replace the temporary file with the original flag file; Concurrency control: Apply file locks or process locks before and after replacement to prevent multiple processes from accessing the file simultaneously, which could lead to inconsistencies. Generate audit logs: After the replacement is complete, generate audit logs containing the old version flag hash value, the new version flag hash value, the event signature generated from the source information, and the event timestamp; Security reporting: Audit logs are transmitted to the central control platform via an encrypted channel using TLS two-way certificate authentication; After receiving the audit log, the central control platform will verify the event signature with a public key and perform continuity verification on the chained verification field. If the verification passes, the result will be written to an immutable log system based on a chained hash structure (which can be a sequential linked list or a Merkle tree structure). If an verification anomaly is found, an alarm will be generated immediately and a security response will be triggered.
[0041] Unlike existing technologies that simply overwrite files or store ordinary logs, this unit forms a complete update and audit loop through temporary file writing, synchronous disk persistence, atomic replacement, locking mechanism, TLS reporting, and platform chain-based evidence storage.
[0042] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.
[0043] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A method for dynamically updating flags in a network security attack and defense exercise range, characterized in that: The specific steps of this method are as follows: On the target host, listen for access events to the pre-set flag file used for drill verification in order to detect file read operations; When a read operation is detected, the source information corresponding to the operation is collected. The source information includes at least the access process identifier, the hash value of the executable file, the parent process chain, the call stack call point, and the summary information of the process memory page. The source information is combined with the target host's unique identifier, event timestamp, and incrementing counter and input into an HMAC or signature hash algorithm to generate new flag content bound to the read operation. The hash value of the previous version of the flag is embedded in the flag content to form a chained verification field. The new flag content is written to a temporary file, and after synchronous disk writing, the original flag file is atomically replaced by renaming. At the same time, an audit record containing the old version hash, the new version hash, the traceability signature and the event timestamp is generated and reported to the central control platform through an encrypted channel using TLS two-way authentication. The central control platform verifies the received audit records using signature verification and chain verification, and stores the results in an immutable log system based on a chain hash structure. When rollback or forgery signs are detected, an anomaly alarm is triggered.
2. The method for dynamically updating flags in a network security attack and defense exercise range according to claim 1, characterized in that: The access event monitoring is implemented in the kernel layer of the target host through the file system monitoring mechanism. In the Linux system environment, the fanotify interface or the eBPF-based system call probe is used. In the Windows system environment, the file system filter driver or object access audit is used. When a read operation on the preset flag file is captured, the source information associated with the read operation is further obtained. The tracing information includes: the process identifier of the accessing process, the hash value of the executable file corresponding to the process, the parent process chain relationship of the process, the call stack entry point that triggered the call, and the hash digest of the memory pages currently occupied by the process.
3. The method for dynamically updating flags in a network security attack and defense exercise range according to claim 2, characterized in that: During the generation of the new flag, the collected traceability information, the unique identifier of the target host, the timestamp of the event, and the incrementing counter are used as input data. The data are calculated using the HMAC algorithm or the signature hash algorithm to obtain the new flag content corresponding to the read operation. The hash value of the previous version of the flag is written into the new flag content to form a continuous chain of verification fields.
4. The method for dynamically updating flags in a network security attack and defense exercise range according to claim 3, characterized in that: The newly generated flag content is written to a temporary file in the same directory as the original flag file. After writing, the file system is invoked to synchronize the write operation to ensure that the data is persisted to disk; After synchronization is complete, the temporary file is atomically replaced with the original flag file by renaming, and file locks or process locks are used before and after the replacement to avoid conflicts caused by concurrent access. An audit log is generated upon completion of the replacement. The audit log includes the hash value of the old version flag, the hash value of the new version flag, the event signature generated based on the source information, and the event timestamp. The audit logs are transmitted to the central control platform by establishing a TLS encrypted channel with two-way certificate authentication.
5. The method for dynamically updating flags in a network security attack and defense exercise range according to claim 4, characterized in that: After receiving the audit records, the central control platform first performs public key verification on the event signatures contained in the audit records. After the signature is verified, the chained verification field carried in the audit record is compared with the previous version's flag hash value saved by the platform to verify continuity. When the verification is successful, the audit record is written to the log database organized based on the chained hash structure, and an anomaly alarm is immediately generated when inconsistency in verification or record forgery is detected.
6. A dynamic flag update system for a network security attack and defense exercise range, characterized in that: The network security attack and defense exercise range flag dynamic update system is based on the method described in claim 5, and the system includes: The event listening unit is used to monitor the reading operation of the preset flag file on the target host and trigger information collection when the operation is detected. The information acquisition unit is used to collect the access process identifier, the hash value of the executable file, the parent process chain, the call stack call point and the memory page summary after the event listening unit is triggered, and output the information to the generation unit; The flag generation unit is used to receive the data output by the information collection unit, and combine it with the host unique identifier, event timestamp and incrementing counter to generate new flag content through HMAC or signature hash algorithm, and embed the hash value of the previous version flag into the new flag to form a chain verification field. The update and audit unit is used to replace the original flag file by writing and renaming temporary files after receiving the new flag generated by the flag generation unit, and to ensure concurrency consistency by combining file locks or process locks. At the same time, it generates an audit record containing chained hashes and traceability signatures, and reports it to the central control platform through a TLS two-way authentication channel. The platform performs signature verification, chained verification and stores it in an immutable log system based on a chained hash structure.
7. A network security attack and defense exercise range flag dynamic update system according to claim 6, characterized in that: The event listening unit is implemented in the kernel layer of the target host through a file system monitoring mechanism. In the Linux system environment, it adopts the fanotify interface or a system call probe based on eBPF. In the Windows system environment, it adopts a file system filter driver or object access audit. It is used to output a trigger signal when a read operation on a preset flag file is detected, and then transmit the trigger signal to the information acquisition unit to start the acquisition of traceability information.
8. The network security attack and defense exercise range flag dynamic update system according to claim 7, characterized in that: After receiving the trigger signal output by the event listening unit, the information acquisition unit obtains the traceability information related to the preset flag file reading operation. The traceability information includes: the process identifier of the accessing process, the hash value of the executable file corresponding to the process, the parent process chain relationship of the process, the call stack entry point of the triggering call, and the hash digest of the memory page currently allocated to the process. The traceability information is then transmitted to the flag generation unit.
9. A network security attack and defense exercise range flag dynamic update system according to claim 8, characterized in that: After receiving the traceability information from the information collection unit, the flag generation unit uses the traceability information, the unique identifier of the target host, the timestamp of the event, and the incrementing counter as input data. It then calls the HMAC algorithm or signature hash algorithm to calculate and generate a new flag content corresponding to the read operation. The unit writes the hash value of the previous version flag into the new flag content to form a chain verification field and outputs the new flag content to the update and audit unit.
10. The method and system for dynamically updating flags in a network security attack and defense exercise range according to claim 9, characterized in that: After receiving the new flag content output by the flag generation unit, the update and audit unit writes the new flag content into a temporary file in the same directory as the original flag file. After writing is completed, it performs a synchronous disk write operation and atomically replaces the original flag file with the temporary file by renaming it. During the replacement process, file locks or process locks are used to ensure data consistency under concurrent access by multiple processes. After the replacement is completed, an audit record is generated. The audit record includes the hash value of the old version flag, the hash value of the new version flag, the event signature generated by the traceability information, and the timestamp of the event. The audit record is transmitted to the central control platform through a TLS encrypted channel with two-way certificate authentication so that the platform can verify the signature and perform chain verification on the audit record and write the verification result into an immutable log system based on a chain hash structure.