An attack behavior active defense method based on a parallel network construction, a server, a product and a medium

Abstract

An attack behavior active defense method based on parallel network construction, a server, a product and a medium, relate to the field of operation and maintenance, the method comprises: detecting a real network asset node to obtain service fingerprints, protocol timing characteristics and business data and other characteristic information. Corresponding simulation nodes are generated in the isolation sandbox, which can produce consistent response, and the parallel simulation network is established according to the real topology. After detecting the attack traffic, the destination address is redirected to the simulation node and forwarded. The simulation node answers the attack according to the configuration characteristics, records the complete interaction sequence to form the attack log. The application can improve the consistency between the decoy environment and the real network in the deception defense system, so that the attacker cannot identify and avoid the decoy system in the detection stage.

Description

Technical Field

[0001] This application relates to the field of operation and maintenance, and in particular to a proactive defense method, server, product and medium for attack behavior based on parallel network construction. Background Technology

[0002] As cyberattacks become increasingly covert and complex, traditional passive protection systems often lag behind in the face of advanced persistent threats. Cyber ​​deception defense technology, as an active defense method, has gradually gained attention in the industry. Its core idea is to deploy decoy environments to lure attackers into controllable areas, thereby protecting real assets and obtaining attack intelligence.

[0003] Existing network deception defense technologies typically employ honeypot systems, deploying independent decoy hosts at designated locations within the network. Each decoy host loads a pre-configured service simulation module, returning simulated data and recording interaction information to external access requests based on predefined static response rules. Each decoy node is distributed as an independent node across different network segments, simulating a single service type based on a common template.

[0004] As offensive and defensive confrontations intensify, attackers typically determine the authenticity of a target environment by cross-referencing the service response characteristics, protocol implementation details, and inter-node relationships of multiple nodes in the target network. Existing honeypots operate independently based on a common static template, and their service responses exhibit identifiable differences from real business systems in terms of protocol interaction timing, business data content, and inter-node network relationships. Attackers can identify and evade decoy systems during the initial probing phase, leaving defenders with only fragmented initial reconnaissance information. Summary of the Invention

[0005] This application provides a proactive defense method, server, product, and medium for attack behavior based on parallel network construction, which is used to improve the consistency between the decoy environment and the real network in the deception defense system, so that attackers cannot identify and avoid the decoy system during the detection phase.

[0006] Firstly, this application provides a proactive defense method for attack behavior based on parallel network construction, applied to a server. The method includes: probing and analyzing the external services of each asset node in the real network to obtain network asset characteristic information for each asset node, including service fingerprints, protocol interaction timing characteristics, and business data content; in a sandbox environment isolated from the real network, generating corresponding simulation nodes for each asset node based on the network asset characteristic information, and configuring each simulation node to generate a response consistent with the network asset characteristic information of the corresponding asset node to the same type of request; networking multiple simulation nodes according to the topology of the real network to form a parallel simulation network; detecting whether attack traffic targeting the target asset node exists in the real network; if so, redirecting the destination address of the attack traffic to the address of the simulation node corresponding to the target asset node in the parallel simulation network, and forwarding the attack traffic to the corresponding simulation node; responding to the attack traffic according to the configured network asset characteristic information, and recording the complete interaction sequence with the attack source to form an attack behavior log.

[0007] In the above embodiments, by performing service probing and traffic parsing on each asset node in the real network, network asset feature information covering service fingerprints, protocol interaction timing characteristics, and business data content is extracted. This feature information serves as the configuration input for the simulation nodes, ensuring that the responses generated by the simulation nodes to the same type of requests are consistent with those of the real asset nodes in terms of protocol handshake sequences, response field formats, and business data structures. Furthermore, each simulation node is networked according to the topology of the real network, so that the routing relationships and service distribution between nodes obtained by the attacker during lateral probing are consistent with those of the real network. The parallel simulation network constructed in this way has anti-fingerprint recognition capabilities at both the service layer and the network layer. After the attack traffic is redirected to this network, it can continue to engage in deep interaction without being interrupted due to environmental differences.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the step of detecting whether there is attack traffic to the target asset node in the real network specifically includes: performing behavioral analysis on the real-time traffic flowing to the target asset node, calculating the deviation between the real-time traffic and a preset normal business behavior baseline; when the deviation exceeds a preset threshold, performing correlation verification by combining the intrusion detection rule base and threat intelligence to obtain the correlation verification result; and determining whether the real-time traffic is attack traffic based on the correlation verification result.

[0009] In the above embodiments, firstly, deviation is calculated on real-time traffic based on a baseline of normal business behavior. This baseline reflects the behavioral characteristics of the target asset node under normal operating conditions, such as access frequency, protocol type distribution, and request parameter range. Deviation calculation can quantitatively detect abnormal access behavior that does not conform to the normal pattern. When the deviation exceeds a preset threshold, the system does not directly determine it as an attack. Instead, it further combines known attack signatures in the intrusion detection rule base with malicious IP reputation and attack tool fingerprints in external threat intelligence for correlation verification. Through cross-confirmation of multi-dimensional evidence, it can suppress misjudgments caused by business fluctuations or legitimate abnormal operations while ensuring effective detection of covert attack behaviors.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the step of redirecting the destination address of the attack traffic to the address of the simulation node corresponding to the target asset node in the parallel simulation network specifically includes: recording the connection state information of the current attack session corresponding to the attack traffic; synchronizing the connection state information to the simulation node, so that the simulation node establishes a mirror session corresponding to the attack session based on the connection state information; after the mirror session is established, switching the destination address of the attack traffic to the address of the simulation node, so that the simulation node continues to interact with the attacker through the mirror session.

[0011] In the above embodiments, before performing traffic redirection, the connection state information of the current attack session is recorded. This connection state information includes parameters such as the Transmission Control Protocol (TCP) sequence number, acknowledgment number, window size, and session layer protocol state. These parameters determine the synchronization state of the two communicating parties. After receiving the connection state information, the emulated node constructs a mirror session with the same sequence number and protocol state. This ensures that, from the attacker's perspective, the sequence number increment, window announcement, and acknowledgment delay remain continuous, and there are no protocol layer anomalies caused by resets or re-handshakes. After the mirror session is established, the destination address is switched. Subsequent data packets from the attacker are directly processed by the emulated node. The entire switching process maintains seamless connection of the session state at the transport layer.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the step of responding to attack traffic according to configured network asset characteristic information and recording the complete interaction sequence with the attack source to form an attack behavior log specifically includes: determining the protocol type and service response strategy matching the attack traffic based on the network asset characteristic information corresponding to the simulation node; dynamically responding to the attack traffic according to the service response strategy, maintaining multiple rounds of interaction with the attack source during the response process; capturing data at the host layer, network layer, and application layer of the simulation node during the multiple rounds of interaction, recording the operation instructions of the attack source, the response content of the simulation node, the interaction timestamp, and the protocol field content; performing time-series correlation based on the timestamps of the captured data at each layer, arranging the behavior data scattered at different layers according to the attack stage to form an attack chain view covering the complete attack process, and outputting the attack chain view as an attack behavior log.

[0013] In the above embodiments, operations such as process creation, file reading and writing, and system calls are captured at the host layer of the simulation node; the source and destination addresses, ports, and protocol fields of data packets are captured at the network layer; and specific business request parameters and response content are captured at the application layer. The data capture at these three levels covers the attacker's system-level operations, network-level communication, and application-level interaction, respectively. Based on the interaction timestamps carried by the data at each layer, a time sequence correlation is established to establish a correspondence between behavioral data belonging to different layers within the same time window. The data is then arranged according to attack stages such as reconnaissance, intrusion, lateral movement, and data acquisition to form a structured attack chain view. This allows security analysts to trace back the attacker's specific operational methods and path selections at each stage from a single view.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of recording the complete interaction sequence between the attacker and the attack source to form an attack behavior log, the method further includes: performing time-series analysis on the attack operation sequence recorded in the attack behavior log to extract behavioral pattern features and payload features from the attack operation sequence; generating new detection rules based on the behavioral pattern features and payload features; and after validating the effectiveness of the new detection rules, supplementing the new detection rules into the attack traffic detection process.

[0015] In the above embodiments, time-series analysis is performed on the attack operation sequences recorded in the attack behavior log. Behavioral pattern features and payload features are extracted from the time interval distribution, instruction combination patterns, and payload encoding characteristics of the operation sequences. These features reflect the identifiable patterns of the toolchain and attack methods used by the attacker. After generating new detection rules based on the extracted features, the system verifies the effectiveness of the rules on historical traffic samples. After confirming that the detection rate and false alarm rate meet the preset indicators, the rules are added to the attack traffic detection process, enabling the defense system to continuously expand its detection capabilities based on the captured attack behaviors, and to identify subsequent attacks of the same type or with the same toolchain at an earlier stage.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of recording the complete interaction sequence between the attacker and the attack source to form an attack behavior log, the method further includes: real-time monitoring of the outbound traffic of the parallel simulation network; blocking connection requests initiated from inside the parallel simulation network to the real network or external network based on a preset outbound access control policy; monitoring the interaction status between the attack source and the simulation nodes; and automatically resetting the operating environment of the parallel simulation network, restoring each simulation node to its initial configuration state, and clearing attack trace data when no new interaction behavior of the attack source is detected within a preset idle time.

[0017] In the above embodiments, outbound traffic of the parallel simulation network is monitored in real time. Based on a preset outbound access control policy, connection requests initiated from inside the simulation network to the real network or external network are blocked. This policy ensures that even if an attacker gains control of a simulation node, they cannot use that node as a springboard to launch attacks or send data back to the outside. At the same time, the system monitors the interaction status between the attack source and the simulation node. When no new interaction behavior is detected within a preset idle time, it is determined that the current attack session has been terminated. Then, the operating environment of the parallel simulation network is reset, each simulation node is restored to its initial configuration state, and the tools, backdoors, and operation traces left by the attacker are cleared, so that the parallel simulation network is restored to a clean initial environment to receive the next towing task.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of networking multiple simulation nodes according to the topology of a real network to form a parallel simulation network, the method further includes: deploying honey bait data in the simulation nodes, the honey bait data including simulated sensitive documents, user credential information, and database records; setting a unique identifier for the honey bait data, and actively presenting the honey bait data to the attack source when the attack source accesses the simulation node; triggering a tracking alarm based on the unique identifier when the honey bait data is accessed or transmitted by the attack source, and associating the access record of the honey bait data with the attack behavior log.

[0019] In the above embodiments, honey bait data is deployed in the simulation node. This honey bait data contains simulated sensitive documents, user credential information, and database records. Its content format and storage path are consistent with similar data in the real business environment, making attackers regard the honey bait data as valuable target information during file traversal or database query. Each piece of honey bait data carries a unique identifier embedded in the data content without affecting the readability of the data. When attackers transmit the honey bait data to external servers, the security team can track the propagation path of the data in network traffic or public channels based on the unique identifier and associate the access and transmission records of the honey bait data with the attack behavior log, enriching the data sources for attacker intent analysis.

[0020] In a second aspect, embodiments of this application provide a server comprising: one or more processors and a memory; the memory is coupled to the one or more processors and is used to store computer program code, the computer program code including computer instructions, wherein the one or more processors invoke the computer instructions to cause the server to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a server, cause the server to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a server, cause the server to execute the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the server provided in the second aspect, the computer storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. By employing a technical solution that uses service probing and traffic analysis on each asset node of the real network to obtain network asset characteristic information including service fingerprints, protocol interaction timing characteristics, and business data content, and generating consistent simulation nodes in an isolated sandbox environment based on this characteristic information, and networking these simulation nodes according to the real network topology to form a parallel simulation network, and redirecting attack traffic to the corresponding simulation node for response and recording upon detection, the parallel simulation network maintains consistency with the real network in terms of service fingerprints, protocol timing, and business content. Attackers cannot identify the simulation environment through feature comparison, effectively solving the problem in existing technologies where honeypot systems operate independently based on general static templates, resulting in identifiable differences between service responses and real business, and allowing attackers to identify and avoid decoy systems in the initial reconnaissance stage. This achieves complete isolation, capture, and in-depth interactive analysis of attack behavior.

[0026] 2. By employing a technical solution that analyzes the behavior of real-time traffic flowing to target asset nodes and calculates its deviation from a preset normal business behavior baseline, and then combines intrusion detection rule base and threat intelligence for correlation verification to determine attack traffic when the deviation exceeds a preset threshold, the identification of attack traffic takes into account both quantitative detection of behavioral deviation and correlation verification of multi-source intelligence. This effectively solves the problem of insufficient identification rate or high false positive rate of covert attack behavior relying on a single detection method in existing technologies, thereby achieving high confidence in the determination of attack traffic and reliable triggering.

[0027] 3. By adopting a technical solution that records the connection state information of the current attack session and synchronizes this connection state information to the simulation node, and then the simulation node establishes a mirror session corresponding to the attack session based on this state information, and then switches the destination address of the attack traffic to the address of the simulation node after the mirror session is established, the connection state synchronization and mirror session establishment in this solution ensure that the transport layer session state remains continuous before and after redirection. The attacker's connection is not interrupted or reset, so the attacker cannot perceive the environment change through network layer behavior. This effectively solves the problem in the existing technology where the discontinuous session state during the traffic redirection process causes the attacker to perceive the environmental change and stop the attack, thereby realizing the seamless migration of attack traffic and subsequent continuous deep interaction. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the overall architecture of the proactive defense system for attack behavior built based on parallel networks in the embodiments of this application;

[0029] Figure 2 This is a flowchart illustrating an active defense method for attack behavior based on parallel network construction in an embodiment of this application.

[0030] Figure 3This is a schematic diagram of the process of traffic learning and automated construction of parallel networks in the embodiments of this application;

[0031] Figure 4 This is a schematic diagram illustrating the principle of the attack detection and traffic redirection mechanism in the embodiments of this application;

[0032] Figure 5 This is a flowchart illustrating the deep deception interaction and attack chain behavior capture process in the embodiments of this application;

[0033] Figure 6 This is another flowchart illustrating the proactive defense method for attack behavior based on parallel network construction in this application embodiment;

[0034] Figure 7 This is a schematic diagram of the physical device structure of a server in an embodiment of this application. Detailed Implementation

[0035] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0036] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0037] To facilitate understanding, the application scenarios of the embodiments of this application are described below.

[0038] As cyberattack methods continue to evolve, attackers are employing increasingly complex and covert techniques, posing a severe challenge to traditional cybersecurity defense systems. Traditional defenses, centered on firewalls, intrusion detection systems, and security gateways, primarily rely on matching known attack signatures for detection. They lack effective identification and response capabilities against attacks exploiting unknown vulnerabilities or employing novel attack methods. Furthermore, traditional defense systems typically block the attack connection immediately upon detection, failing to gain a deeper understanding of the attacker's complete intent, technical methods, and attack paths. This leaves defenders in a perpetually reactive position, hindering the extraction of valuable threat intelligence from attack incidents for iterative improvement of defense capabilities.

[0039] In a real-world enterprise network environment, a typical application scenario is as follows: An enterprise has deployed a business network including web servers, database servers, file servers, and office terminals, running various operating systems and service components. Attackers launch targeted attacks on this enterprise network via the internet. First, they perform port scanning and service probing on the enterprise's exposed network assets to obtain information about the operating system versions and service components of each server. Then, they exploit discovered vulnerabilities to attempt to gain control of the servers, and subsequently move laterally within the internal network to obtain sensitive data. Under traditional defense systems, if the attacker's exploit methods are not covered by existing detection rules, the attack traffic will directly reach the actual business servers, posing a risk of data leakage and business interruption to the enterprise. Even if some attack behaviors are captured and blocked by the detection system, the defender can only obtain a single alert and cannot reconstruct the attacker's complete attack chain and underlying objectives.

[0040] When the network attack trapping method provided in this application is applied to the above scenario, the system first collects network asset characteristic information of each asset node in the enterprise's real network, including the operating system type, open ports, service versions, and protocol interaction characteristics of each server. Based on this characteristic information, high-fidelity simulation nodes are generated, and the simulation nodes are assembled into a parallel simulation network according to the topology of the real network. When an attacker launches an attack on the enterprise network, the system performs behavioral analysis and correlation verification on the real-time traffic flowing to the target asset node. After identifying the attack traffic, it transparently forwards it to the corresponding simulation node in the parallel simulation network. The simulation node dynamically responds to the attacker's requests according to the service characteristics consistent with the real assets, allowing the attacker to continue to perform attack operations without realizing that they have entered the simulation environment. The system completely records the attacker's operation instructions, tools used, and attack paths throughout the entire interaction process, forming a behavior log covering the complete attack chain. The system further analyzes the attack behavior log, extracts the attacker's behavioral pattern characteristics and payload characteristics, automatically generates new detection rules, and supplements them into the detection engine to achieve dynamic enhancement of defense capabilities. Meanwhile, the system ensures that attacks are strictly confined to the parallel simulation network and do not affect the real business network through outbound traffic control and automatic environment reset mechanisms.

[0041] Through the above methods, this application embodiment transforms the traditional passive blocking defense into an active trapping defense, which protects real business assets from harm while fully acquiring technical intelligence of attackers and continuously enhancing its own detection capabilities, forming a positive cycle of improvement in defense capabilities.

[0042] To facilitate understanding of the overall system architecture of the embodiments of this application, please refer to... Figure 1 , Figure 1This is a schematic diagram of the overall architecture of the proactive defense system against attacks built on a parallel network in this application embodiment.

[0043] like Figure 1 As shown, the proactive defense system for attack behavior provided in this application includes three parts in its overall architecture: a real network environment, a defense system core, and a parallel deception network. The three parts work together through traffic data transmission and traffic traction.

[0044] The real network environment includes actual business asset nodes such as web servers, database servers, file servers, and core switches. The traffic data generated by each asset node during normal operation is aggregated by the core switch and then transmitted to the core of the defense system.

[0045] The core of the defense system includes a traffic analysis module, a parallel network construction module, an attack detection and judgment module, and a traffic redirection and control module. The traffic analysis module performs deep packet inspection and protocol analysis on traffic data from the real network environment, extracting network asset characteristic information such as service fingerprints, protocol interaction timing characteristics, and business data content for each asset node. The parallel network construction module automatically generates simulated nodes in an isolated sandbox environment based on the network asset characteristic information output by the traffic analysis module and networks them according to the topology of the real network to form a parallel deception network. The attack detection and judgment module performs behavioral analysis and threat assessment on real-time traffic flowing to each asset node in the real network. After the attack detection and judgment module confirms an attack, the traffic redirection and control module redirects the destination address of the attack traffic to the corresponding simulated node in the parallel deception network.

[0046] The parallel deception network comprises shadow servers, shadow databases, behavioral sensors, and a monitoring and analysis platform. The shadow servers and shadow databases act as simulation nodes of corresponding asset nodes in the real network, responding to redirected attack traffic according to configured network asset characteristics. Behavioral sensors, deployed in each simulation node, are responsible for capturing holographic data at the host, network, and application layers, recording the complete interaction sequence between the attack source and the simulation node. The monitoring and analysis platform performs time-series correlation and attack phase orchestration on the behavioral data collected by the sensors, forming an attack chain view covering the entire attack process and generating attack behavior logs. Simultaneously, it transmits the behavioral data back to the core of the defense system for iterative updates to detection rules.

[0047] Through the above architecture, the core of the defense system directs attack traffic to the parallel deception network through traffic redirection. The parallel deception network then transmits the captured behavioral data back to the core of the defense system for analysis, forming a complete closed-loop defense system from perception, construction, redirection to capture and analysis.

[0048] To facilitate understanding, the method provided in this implementation will be described in detail below, using the above scenario as an example. Please refer to [link / reference]. Figure 2 This is a flowchart illustrating an active defense method for attack behavior based on parallel network construction in this application embodiment.

[0049] S201. Probe and analyze the external services of each asset node in the real network to obtain the network asset characteristic information of each asset node.

[0050] In this context, "real network" refers to the actual network environment currently protected for business operations, including physical or virtual devices such as servers, switches, and routers, and their interconnections. "Asset node" refers to an independent network device or host instance in the real network capable of providing services externally. Each asset node has an independent network address and one or more open service ports. "External service" refers to the accessible service processes offered by the asset node to other network entities, including but not limited to Hypertext Transfer Protocol (HTTP) services, Secure Shell (SAPP) services, File Transfer Protocol (LTP) services, and database services. "Probing" refers to obtaining the service status and response information of the asset node by actively sending protocol request packets or passively monitoring network communications. "Traffic analysis" refers to the process of decoding and extracting content from network data packets sent and received by the asset node. "Network asset characteristic information" refers to a set of data that uniquely characterizes the external service behavior of the asset node, including service fingerprints, protocol interaction timing characteristics, and business data content. "Service fingerprint" refers to the identifying field information returned by the server when responding to a request, including the service software name, version number, operating system type, and message format specific to the protocol implementation. "Protocol interaction timing characteristics" refers to the time interval distribution, message order, and retransmission mode between request and response messages during a complete protocol interaction. Business data content refers to information with business semantics, such as page structure, interface fields, and database query result format returned by the service during normal response.

[0051] Specifically, the system deploys a traffic acquisition device at the mirror port or network egress of the core switch. This device copies all network data packets passing through the specified network segment in a bypass manner, without injecting any additional data packets into the real network. The traffic acquisition device passes the copied data packets to the protocol parsing engine, which decodes them layer by layer from bottom to top according to the Open Systems Interconnection (OSI) model. It extracts the source and destination addresses from the network layer, the port number and connection status flags from the transport layer, and the protocol payload content from the application layer. For each identified asset node, the system simultaneously initiates an active probing program. This program sends standard protocol handshake requests to each open port of the target node and extracts service fingerprint information based on the flag field, option parameters, and feature strings in the returned response message. The system merges the passively parsed protocol interaction timing data with the actively probing service fingerprint data, categorizes and organizes them according to the network address of the asset node, and records the protocol type, response template, typical response latency distribution, and business data structure for each port service, ultimately forming a complete record of network asset characteristic information for each asset node.

[0052] In some embodiments, the external service detection and traffic parsing of each asset node in the real network can be achieved in multiple ways: Optionally, a passive traffic mirroring method can be adopted. A port mirroring policy is configured on the core switch to copy all traffic of a specified virtual LAN to the collection interface. The traffic collection device decodes the mirrored traffic layer by layer of the protocol stack, extracts the five-tuple information and application layer payload of each session, and then performs service fingerprint matching on the application layer payload. The matching results are aggregated and stored according to the asset node address to form the network asset characteristic information of each node. Optionally, a combination of active detection and passive parsing can be adopted. The system first obtains the list of live addresses and open ports in the real network through passive listening. Then, it sequentially sends the standard handshake request sequence of the corresponding protocol to each open port, records the complete request-response interaction process, and extracts the version field, protocol options, and feature strings from the response message. Simultaneously, the response delay distribution of multiple probes is statistically analyzed as the protocol interaction timing feature. The active detection results are merged with the business data content obtained by passive parsing to generate the network asset characteristic information of each asset node. It is understood that other methods can also be used to detect and parse the external services of each asset node; these are not limited here.

[0053] S202. In a sandbox environment isolated from the real network, generate corresponding simulation nodes for each asset node based on the network asset characteristic information, and configure each simulation node to generate a response consistent with the network asset characteristic information of the corresponding asset node to the same type of request.

[0054] In this context, a sandbox environment refers to a controlled virtualized operating space that is completely isolated from the real network in terms of physical links or logical network segments. Any operation within this space will not affect the operational status of the real network. Isolation means that there is no reachable network routing path between the sandbox environment and the real network; data transmission between them is only conducted through a controlled management channel. A simulation node is a virtual host instance created in the sandbox environment. Each simulation node corresponds to an asset node in the real network and is configured to present the same service response characteristics as that asset node. Generation refers to the process of creating a virtual host and loading the corresponding service simulation module in the sandbox environment based on the service type, protocol parameters, and response template recorded in the network asset characteristic information. Configuration refers to writing the service fingerprint parameters, protocol interaction timing parameters, and business data templates from the network asset characteristic information into the service simulation module of the simulation node, enabling it to generate response messages according to these parameters. Response refers to the response data packet generated and returned by the simulation node after receiving an external request, based on the configuration parameters. This response data packet is consistent with the response generated by the real asset node to the same request in terms of protocol field format, service identification information, and business content structure.

[0055] Specifically, the system creates an independent lightweight virtual machine instance or container instance for each asset node requiring simulation in the sandbox environment, assigning the instance the same operating system type identifier as the real asset node. For each open port service of the real asset node, the system loads a simulation module for that service type on the corresponding simulation node. This simulation module reads the service fingerprint parameters recorded in the network asset characteristic information, including the service software name string, version number field, protocol implementation-specific option flags, and response header format template, and writes these parameters into the simulation module's response generation configuration. The simulation module also loads protocol interaction timing parameters, which define the response latency range for different types of requests and the distribution of sending intervals for each response message during multi-round interactions. The simulation module introduces the corresponding latency according to these timing parameters when generating responses. The simulation module also loads a business data template, which defines the page structure, data fields, and content format included in a normal response. The simulation module fills in the payload portion of the response message accordingly. After configuration, the system performs verification tests on the simulation node, sending requests of the same type as those of the real asset node to each of its ports, and comparing the simulation node's response with the real response characteristics recorded in the network asset characteristic information.

[0056] In some embodiments, the generation and configuration of simulation nodes can be achieved in several ways: Optionally, a containerized deployment method is adopted. The system selects the corresponding basic container image based on the operating system type recorded in the network asset characteristic information. A simulation engine for the corresponding service type is installed and configured in this image. Service fingerprint parameters are injected into the container in the form of a configuration file. Protocol interaction timing parameters are written into the latency control module of the simulation engine. The business data template is mounted as the content response directory of the simulation engine. After the container starts, each port provides service responses consistent with those of the real asset node. Optionally, a lightweight virtual machine method is adopted. The system creates an independent virtual machine instance for each asset node, deploys a complete operating system environment in the virtual machine, and configures the same network protocol stack parameters as the real node. A service simulation program is installed in the operating system, and all fingerprint data and timing data from the network asset characteristic information are loaded through startup parameters. The service simulation program takes over all port listening and generates responses to requests according to the loaded parameters. It is understood that other methods can also be used to achieve the generation and configuration of simulation nodes, which are not limited here.

[0057] S203. Connect multiple simulation nodes according to the topology of the real network to form a parallel simulation network.

[0058] In this context, topology refers to the network connection structure between asset nodes in a real network, including the subnetting of each node, routing paths between nodes, the location of gateway devices, and virtual LAN isolation relationships. Networking refers to the process of configuring network interconnection between simulated nodes in a sandbox environment according to the topology of a real network. This includes assigning network addresses to each simulated node consistent with the real network, configuring subnet masks and gateway parameters, establishing virtual switching links between simulated nodes, and configuring routing tables between nodes. A parallel simulation network refers to a complete simulation network environment in a sandbox environment composed of multiple simulated nodes interconnected according to the topology of a real network. This network maintains consistency with the real network in terms of the number of nodes, address planning, subnetting, and routing reachability, but all nodes are simulation instances and do not carry real business data.

[0059] Specifically, the system first obtains the complete topology information of the real network from the network management system of the real network or through routing protocol parsing. This topology information includes the address allocation table of each asset node, subnetting scheme, virtual LAN identifier allocation, and routing relationships between nodes. The system creates virtual switch and virtual router instances in the sandbox environment, creating corresponding virtual LAN segments for each subnet according to the subnetting of the real network. The system connects simulated nodes belonging to the same subnet to the same virtual switch, configuring each simulated node with the same network address, subnet mask, and default gateway as its corresponding real asset node. The system configures routing table entries on the virtual routers consistent with the real network, ensuring that the reachability relationships between simulated nodes in different subnets are the same as in the real network. The system also configures link bandwidth limits and propagation delay parameters between simulated nodes consistent with the real network, ensuring that the network layer characteristics of communication between simulated nodes are consistent with the real network. After network formation, the system performs connectivity verification on the parallel simulated network, initiating probe requests from each simulated node to other simulated nodes to confirm that route reachability and response characteristics meet expectations.

[0060] In some embodiments, the networking of simulated nodes can be achieved in several ways: Optionally, a software-defined networking (SDN) approach can be used. The system deploys a SDN controller in a sandbox environment. The controller automatically distributes flow table rules to virtual switches based on the real network topology information. The network interfaces of each simulated node are connected to the virtual switch ports. The controller configures forwarding rules according to the virtual LAN partitioning and routing policies of the real network, ensuring that the data forwarding behavior of the parallel simulated network is consistent with the real network. Optionally, the native network functions of the virtualization platform can be used. Virtual network segments corresponding to the real network subnets are created in the virtualization management platform. The virtual network cards of each simulated node are connected to the corresponding virtual network segments. Virtual router instances are configured at the platform level, and static routing table entries are set to reproduce the routing relationships of the real network. Bandwidth and latency parameters are configured for each virtual link using traffic shaping. It is understood that other methods can also be used to achieve the networking process of multiple simulated nodes, which are not limited here.

[0061] To better understand the specific implementation process of real asset feature learning and parallel simulation network construction in steps S101 to S103 above, please refer to [link / reference]. Figure 3 , Figure 3 This is a schematic diagram of the process of traffic learning and automated construction of parallel networks in the embodiments of this application.

[0062] like Figure 3 As shown, the process of traffic learning and automated construction of parallel networks specifically includes the following steps:

[0063] First, the system acquires network traffic by deploying traffic acquisition devices at the mirror port of the core switch or at the network egress point. This process copies all network data packets flowing through the specified network segment in a bypass manner, without injecting any additional data packets into the real business environment.

[0064] The system performs traffic detection and protocol parsing on the collected network traffic, and extracts asset fingerprint information for each asset node, including feature data such as open ports, running service types, operating system fingerprints, and web page content.

[0065] The system records the interaction sequence and response logic of each service. By analyzing the time interval distribution, message order and business data structure between each request and response message during multiple rounds of protocol interaction, it learns the normal response behavior pattern of each asset node to external services.

[0066] The system determines whether the learning cycle has ended. If the learning cycle has not ended, it returns to continue acquiring network traffic and iteratively accumulating protocol parsing and timing learning; if the learning cycle has ended, it enters the parallel network construction phase.

[0067] After the learning cycle ends, the system generates a real network feature snapshot file. This snapshot file contains complete network asset feature information records for each asset node, covering service fingerprints, protocol interaction timing features, and business data content, which serve as the configuration input for the generation of subsequent simulation nodes.

[0068] The system initializes the network structure in the parallel network, creates virtual switch and virtual router instances according to the subnetting and topology of the real network, and establishes a network interconnection architecture consistent with the real network.

[0069] The system creates containers corresponding to real nodes, and creates independent lightweight virtual machine instances or container instances for each asset node that needs to be simulated in an isolated sandbox environment, assigning each instance the same operating system type identifier as the real asset node.

[0070] The system configures the service port, version, and system fingerprint parameters, and writes the service fingerprint parameters, protocol interaction timing parameters, and business data templates recorded in the network asset characteristic information into the service simulation module of each simulation node, so that the simulation node generates a response consistent with the corresponding real asset node to the same type of request.

[0071] The system reproduces the business logic, loading business data such as page structure, interface response format, and database content that are consistent with the real asset nodes onto each simulation node, so that the parallel simulation network also has a high-fidelity deception capability at the business level, and the process ends.

[0072] In some embodiments, after the step of networking multiple simulation nodes according to the topology of a real network to form a parallel simulation network, the method further includes: deploying honey bait data in the simulation nodes, the honey bait data including simulated sensitive documents, user credential information and database records, setting a unique identifier for the honey bait data, actively presenting the honey bait data to the attack source when the attack source accesses the simulation node, triggering a tracking alarm based on the unique identifier when the honey bait data is accessed or transmitted by the attack source, and associating the access record of the honey bait data with the attack behavior log.

[0073] Honey bait data refers to pre-constructed and embedded fake sensitive information in emulation nodes to induce deep interaction with the attack source. This includes simulated sensitive documents, user credentials, and database records, such as a document file named "Salary Summary Table.xlsx," a credential file containing fictitious usernames and passwords, and a database table populated with fake customer information. A unique identifier is an invisible tracking identifier embedded in the honey bait data. This identifier is bound to the honey bait data and remains identifiable even after the data is copied or transmitted. Examples include a unique encoded string embedded in a document's metadata field or a specific tag field value inserted into a database record. Active presentation refers to the process by which the emulation node places the honey bait data into the attack source's reachable path when the attack source performs directory browsing, file enumeration, or database query operations, making it discoverable. Tracking alerts are security notification events automatically generated when the system detects that the unique identifier of the honey bait data has been triggered.

[0074] Specifically, after the parallel simulation network is established, the system implants corresponding types of honeypot data into the file system, service directory, and database of each simulation node. Sensitive document honeypots are deployed in directory paths that attackers typically traverse within the simulation node's file system, such as the desktop directory, shared folders, and backup directories; user credential honeypots are placed in the user directory of the simulation node's operating system as configuration files or browser storage records; and database record honeypots are inserted into the database service running on the simulation node as data table row records. The system generates a globally unique identifier for each honeypot data, embedding this identifier in the document's metadata attribute fields using steganography, in the credential text as invisible characters, and in the database record as a tag field. When the attack source performs file enumeration or database query operations on the simulation node, the simulation node's service simulation module includes honeypot data entries in the returned directory list and query results, allowing the attack source to obtain the honeypot data during the normal attack process. The system sets up an access monitoring hook for the storage location of the bait data. When the bait data is read, copied, or sent over the network, the monitoring hook detects the access event and extracts a unique identifier from the accessed bait data. Based on this identifier, a tracking alarm is immediately generated. The alarm content includes the identifier of the accessed bait data, the access time, the access source address, and the access method. The system writes this alarm event and the complete access record of the bait data to the corresponding attack behavior log with a timestamp as the association key, marking the specific stage and operation method by which the attacker obtained the bait data in the attack chain.

[0075] S204. Detect whether there is attack traffic targeting the target asset node in the real network.

[0076] In this context, a target asset node refers to one or more monitored and protected asset nodes in a real network. These nodes carry critical business services or store sensitive data, making them potential targets for attackers. Attack traffic refers to network traffic that accesses the services of a target asset node without authorization or attempts to exploit its vulnerabilities; its behavior patterns differ significantly from normal business access. Detection involves continuously monitoring and analyzing real-time network traffic flowing to the target asset node, identifying whether it contains traffic with malicious intent based on pre-defined criteria. The normal business behavior baseline refers to the statistical model of normal access behavior accumulated by the target asset node over a learning period, including parameters such as access frequency distribution, request type ratio, protocol field value range, and access source address distribution. Deviation is the quantitative difference between the behavioral characteristics of real-time traffic and the normal business behavior baseline; a larger value indicates a more significant difference between the behavioral patterns of real-time traffic and normal business behavior.

[0077] Specifically, the system deploys a traffic detection probe on the upstream network link of the target asset node. This probe mirrors and parses all real-time traffic flowing to the target asset node. The detection probe extracts behavioral characteristics of the real-time traffic, including request frequency per unit time, distribution of request protocol types, request parameter formats, and the set of access source addresses. The system compares the extracted real-time behavioral characteristics with a pre-established baseline of normal business behavior dimension by dimension, calculates the deviation value for each dimension, and performs a weighted sum to obtain a comprehensive deviation value. When the comprehensive deviation value exceeds a preset threshold, the system marks the traffic as potentially abnormal and submits its source address, request content, and protocol characteristics to the correlation verification module. The correlation verification module performs pattern matching between the characteristics of the potentially abnormal traffic and known attack signatures stored in the intrusion detection rule base, and simultaneously compares the traffic's source address with a malicious address reputation database in external threat intelligence. The system outputs a correlation verification conclusion based on the combined pattern matching and intelligence comparison results. When the correlation verification conclusion confirms that the traffic possesses attack characteristics, the system determines that the real-time traffic is attack traffic.

[0078] In some embodiments, attack traffic can be detected in multiple ways: Optionally, a detection method based on statistical deviation can be used. During the learning period, the system statistically analyzes the mean and variance of various behavioral parameters of the normal traffic of the target asset node to form a baseline of normal business behavior. During the detection phase, the system calculates the standardized deviation between the parameters of each dimension of the real-time traffic and the baseline mean, and takes the weighted average of the standardized deviations of each dimension as the comprehensive deviation. When the comprehensive deviation exceeds a preset threshold, the correlation verification process is triggered. Optionally, a parallel approach using multiple detection engines can be adopted. The system simultaneously runs an intrusion detection engine based on signature matching and an anomaly detection engine based on behavioral analysis. The intrusion detection engine performs known attack pattern matching on the payload content of the real-time traffic, and the anomaly detection engine calculates the baseline deviation on the behavioral pattern of the real-time traffic. When either engine outputs a detection alarm, the system correlates the results of the two engines and determines whether it is attack traffic based on the comprehensive score of the alarm confidence. It is understood that other methods can also be used to detect attack traffic in real networks, which are not limited here.

[0079] In some embodiments, this step specifically includes:

[0080] Behavioral analysis is performed on real-time traffic flowing to the target asset node. The deviation between the real-time traffic and the preset normal business behavior baseline is calculated. When the deviation exceeds the preset threshold, correlation verification is performed in combination with the intrusion detection rule base and threat intelligence to obtain the correlation verification result. Based on the correlation verification result, it is determined whether the real-time traffic is attack traffic.

[0081] Real-time traffic refers to the sequence of network data packets flowing to the target asset node at the current moment. Normal business behavior baseline refers to the set of behavioral parameters obtained by statistically modeling the historical business traffic of the target asset node, including quantitative indicators such as average request frequency, protocol type distribution ratio, access time distribution, and payload length range. Deviation refers to the quantitative difference between the behavioral parameters of real-time traffic and the corresponding parameters of the normal business behavior baseline. Intrusion detection rule base refers to the set of matching rules composed of known attack signatures. Threat intelligence refers to the set of threat identification information provided externally, such as known malicious IP addresses, domain names, and attack tool fingerprints. Correlation verification refers to the process of simultaneously matching and comparing traffic with excessive deviation against both the intrusion detection rule base and the threat intelligence.

[0082] Specifically, the system aggregates and statistically analyzes real-time traffic flowing to target asset nodes within fixed time windows, extracting behavioral parameters such as request frequency, protocol type distribution, source address dispersion, average payload length, and request method ratio within the current window. The system compares each behavioral parameter with its corresponding parameter in the normal business behavior baseline, calculating the deviation using weighted Euclidean distance. The calculation method is as follows: the difference between the current value and the baseline value of each parameter is divided by the standard deviation of that parameter to obtain a standardized difference. The squares of each standardized difference are then summed according to preset weights, and the arithmetic square root is taken to obtain the comprehensive deviation value. When the comprehensive deviation value exceeds a preset threshold, the system extracts the traffic data that triggered the deviation within that time window, matches its source address with the malicious IP address database in the threat intelligence, and performs pattern matching of its payload content with the attack signature in the intrusion detection rule base to obtain the association verification result. When at least one of the following conditions is met: threat intelligence match or intrusion detection rule match, the correlation verification result is confirmed as an attack, and the system determines that the real-time traffic is attack traffic; when neither of the two matches is met, the correlation verification result is suspected anomaly, and the system marks the traffic as pending observation and continuously monitors it in subsequent windows.

[0083] S205. If it exists, redirect the destination address of the attack traffic to the address of the simulation node corresponding to the target asset node in the parallel simulation network, and forward the attack traffic to the corresponding simulation node.

[0084] In this context, "destination address" refers to the network address entered in the destination address field of the attack traffic's network data packet, which originally pointed to the address of the target asset node in the real network. "Redirection" refers to rewriting the destination address field of the attack traffic data packet along the network data forwarding path, changing it from the address of the target asset node to the address of the corresponding simulated node in the parallel simulation network, so that subsequent data packets are forwarded to the simulated node for processing. "Connection state information" refers to the synchronization state parameters established at the Transmission Control Protocol (TCP) layer for the current session of the attack traffic, including the current sequence number, acknowledgment number, sliding window size, maximum segment length negotiation value, and the current state of the session layer protocol state machine. "Mirror session" refers to a TCP connection instance established locally by the simulated node based on the received connection state information, completely identical to the attack session state. The sequence number, acknowledgment number, and window parameters of this connection instance remain continuous with the original attack session, allowing subsequent data packets to be directly sent and received on this connection. "Forwarding" refers to sending the attack traffic data packet with its destination address rewritten to the network interface of the simulated node through network layer routing.

[0085] Specifically, when the system determines that a certain traffic is attack traffic, the traffic redirection module first obtains the status information of the current Transmission Control Protocol (TCP) connection corresponding to the attack traffic, including the current sending sequence number, expected receiving acknowledgment number, announcement window size, and negotiated protocol option parameters. The system transmits this connection status information through the management channel to the simulation node corresponding to the target asset node in the parallel simulation network. After receiving this status information, the simulation node constructs a mirror connection instance with the same sequence number and protocol status in its local TCP stack. The state machine of this mirror connection instance is directly set to the established state, and all parameter values ​​remain consistent with the original connection. After the simulation node confirms the establishment of the mirror session, the traffic redirection module modifies the forwarding rules on the network forwarding device, rewriting the destination address field of the data packet matching the attack traffic five-tuple from the target asset node address to the simulation node address, and routes the rewritten data packet to the simulation node in the sandbox environment. Upon receiving the data packet, the simulation node processes it through the mirror session and generates a response. The source address of the response message is reverse-rewritten and returned to the attacker, ensuring that the attacker perceives the communication peer address as the target asset node address.

[0086] In some embodiments, the redirection and forwarding of attack traffic can be achieved in several ways: Optionally, a network address translation (NAT) method can be used. The traffic redirection module configures destination address translation rules for the attack traffic on the network egress device. These rules match the source address and destination port of the attack traffic, rewriting the destination address of the matching data packets to the actual address of the emulator node in the sandbox environment. Simultaneously, the translation mapping relationship is recorded for reverse source address rewriting of the emulator node's response packets. Before configuring the translation rules, the current connection state is synchronized to the emulator node to establish a mirror session. Optionally, a software-defined network (SDN) flow table injection method can be used. The traffic redirection module issues new flow table rules to the virtual switches through which the attack traffic passes via the SDN controller. These rules rewrite the destination address of data packets matching the attack session's five-tuple and modify the output port to the port connected to the emulator node. Before issuing the flow table, the system transmits connection state information to the emulator node through the control channel to establish the mirror session. After the flow table takes effect, the attack traffic is forwarded to the emulator node for processing. It is understood that other methods can also be used to achieve the redirection and forwarding of the attack traffic's destination address; these are not limited here.

[0087] In some embodiments, when no attack traffic to the target asset node is detected, the method further includes: determining the real-time traffic flowing to the target asset node as normal business traffic, maintaining the normal business traffic to be forwarded to the target asset node according to the original routing path, and having the target asset node process and respond according to normal business logic, while continuously monitoring subsequent traffic in real time.

[0088] Normal business traffic refers to a sequence of network data packets flowing towards the target asset node whose deviation does not exceed a preset threshold or which, after correlation verification, is not identified as an attack. The original routing path refers to the network links that real-time traffic traverses according to network routing rules to reach the target asset node without system intervention for forwarding. Continuous real-time monitoring refers to the process by which the system, after determining that the traffic within the current time window is normal business traffic, continues to perform behavioral analysis and deviation calculations on the traffic in subsequent time windows without interrupting the detection process.

[0089] Specifically, the system extracts behavioral parameters and calculates deviations for real-time traffic flowing to the target asset node within fixed time windows. When the calculated overall deviation value does not exceed a preset threshold, the system determines that the traffic within the current time window does not contain attack behavior, and maintains normal forwarding of all data packets within that time window on the original routing path without modifying the destination address of the data packets. The target asset node receives and processes the service request normally and returns a service response to the requester. When the overall deviation exceeds the preset threshold but fails to match threat intelligence matching and intrusion detection rule matching after correlation verification, the system marks the traffic as pending observation. It also maintains normal forwarding without interception or redirection, and focuses on monitoring traffic from that source address in subsequent consecutive time windows to improve the granularity of analysis of that source traffic. The system runs continuously throughout the monitoring process, executing the above detection process for traffic arriving in each time window to ensure that attack traffic can be identified and forwarded promptly once it appears. In the absence of attack traffic, the simulation nodes in the parallel simulation network remain in standby mode. The service simulation modules of each simulation node continue to run but do not generate interactive activities. The system resource consumption is at a minimum level and does not affect the normal business performance of the real network.

[0090] In some embodiments, this step specifically includes: recording the connection state information of the current attack session corresponding to the attack traffic, synchronizing the connection state information to the simulation node, enabling the simulation node to establish a mirror session corresponding to the attack session based on the connection state information, and after the mirror session is established, switching the destination address of the attack traffic to the address of the simulation node, so that the simulation node can continue to interact with the attacker through the mirror session.

[0091] Connection state information refers to the real-time parameter set of established network connections in the current attack session, including TCP sequence number, acknowledgment number, window size, protocol state stage of the connection, and exchanged application layer protocol negotiation parameters. A mirror session is a copy of a network connection with the same protocol state as the current attack session, reconstructed locally by the emulator node based on synchronized connection state information. The attack source is unaware that the session has been transferred from the target asset node to the emulator node. Destination address switching refers to the operation at the network forwarding layer that replaces the destination address of attack traffic packets from the target asset node's address to the emulator node's address.

[0092] Specifically, after determining that the real-time traffic is attack traffic, the system immediately reads the connection state information of the current attack session from the session tracking table of the traffic detection engine. This includes the current sequence number and acknowledgment number of the TCP connection, sliding window parameters, completed TLS handshake key materials, and authentication tokens and session identifiers exchanged by the application layer protocol. The system encapsulates the above connection state information into a state synchronization message and sends it to the target emulation node. Upon receiving the message, the emulation node creates a new socket connection in its local protocol stack, sets the TCP sequence number, acknowledgment number, and window parameters of this connection to the same values ​​as the original attack session, loads the same TLS session key, and restores the exchanged protocol negotiation state at the application layer, thus completing the establishment of the mirror session. After the mirror session is established, the system modifies the destination address field of the corresponding flow table entry for this attack session in the flow table of the network forwarding device, replacing the destination address from the IP address of the target asset node with the IP address of the emulation node. Subsequent packets belonging to this attack session are forwarded to the emulation node. The emulation node continues to interact with the attacker using the same protocol state as the original session through the mirror session. The sequence number and protocol state in the response messages received by the attacker remain continuous, making it impossible for the attacker to detect that the session has been migrated.

[0093] To better understand the specific mechanisms of attack traffic detection and redirection in steps S104 and S105 above, please refer to [link / reference needed]. Figure 4 , Figure 4 This is a schematic diagram illustrating the principle of the attack detection and traffic redirection mechanism in the embodiments of this application.

[0094] like Figure 4 As shown, the attack detection and traffic redirection mechanism includes two layers: the detection and decision layer and the traffic redirection execution layer.

[0095] In the detection and decision layer, the system integrates three detection dimensions—a feature matching engine, an anomaly analysis engine, and threat intelligence—to perform multi-dimensional evaluation of real-time traffic. The detection results from each dimension are then input into a comprehensive decision-maker for correlation verification. Specifically, the feature matching engine performs pattern matching between the payload content of real-time traffic and known attack signatures in the intrusion detection rule base; the anomaly analysis engine calculates the deviation of the behavioral characteristics of real-time traffic from a preset baseline of normal business behavior, quantifying and detecting abnormal access behaviors that do not conform to normal patterns; and threat intelligence provides threat identification information such as the reputation of known malicious IP addresses and attack tool fingerprints for correlation comparison. The comprehensive decision-maker performs multi-source evidence cross-verification based on the detection results from these three dimensions. When the correlation verification conclusion confirms that the traffic possesses attack characteristics, it outputs an attack decision command to trigger traffic-driven execution.

[0096] In the traction execution layer, once the integrated decision unit confirms that the traffic is attack traffic, the traffic traction control module performs traction operations according to the following sequence of actions: Action A is to disconnect the existing connection, that is, to record the connection status information of the current attack session, including parameters such as the transmission control protocol sequence number, acknowledgment number, window size, and session layer protocol status, and synchronize this connection status information to the simulation node corresponding to the target asset node in the parallel simulation network. The simulation node then establishes a mirror session corresponding to the attack session based on this connection status information. Action B is to modify the IP header information of the new connection, that is, after the simulation node confirms that the mirror session has been established, to rewrite the destination address field of the attack traffic data packet from the address of the target asset node to the address of the simulation node. Action C is to send the modified traffic into the parallel network, that is, to forward the attack traffic data packet with the rewritten destination address to the simulation node in the parallel simulation network through network layer routing for processing. The simulation node continues to interact with the attacker through the mirror session using the same protocol status as the original session, completing the seamless migration of attack traffic from the real network to the parallel simulation network. The attacker cannot perceive the environment switch through network layer behavior.

[0097] S206. Respond to attack traffic according to the configured network asset characteristic information, and record the complete interaction sequence between the attacker and the attack source to form an attack behavior log.

[0098] The configured network asset characteristic information refers to the set of service fingerprint parameters, protocol interaction timing parameters, and business data templates loaded into the simulation module of the simulation node service. Response refers to the process by which the simulation node generates a response data packet conforming to the corresponding protocol specification based on this set and returns it to the attack source. The attack source refers to the network communication terminal that sends the attack traffic. The complete interaction sequence refers to the ordered record of all request and response messages between the attack source and the simulation node. The attack behavior log refers to the structured attack chain view record formed by sequentially associating and arranging the behavioral data captured at the host layer, network layer, and application layer according to the attack stages. The service response strategy refers to the set of rules by which the simulation node selects the corresponding response template and interaction logic from the configuration information based on the protocol type of the request.

[0099] Specifically, after the simulated node receives the request data packet from the attack traffic, the service simulation module identifies its protocol type, queries the configured network asset characteristic information based on the identification result, and matches the corresponding service response strategy. The service simulation module generates a response message according to the response template, filling in the service identifier field in the header that is consistent with the real asset node, filling in the content format defined by the business data template in the payload, and introducing a response delay according to timing parameters before sending it to the attack source, maintaining multiple rounds of interaction. Throughout the interaction process, the system records process creation and file operations at the host layer, data packet metadata at the network layer, and request parameters and response content at the application layer, with each layer's record appended with a millisecond-level timestamp. Based on the timestamps, the system performs time-series correlation on the data from the three layers, arranging the behavioral data according to attack stages such as reconnaissance and detection, vulnerability exploitation, lateral movement, and data acquisition, forming an attack chain view as the attack behavior log output.

[0100] In some embodiments, response to attack traffic and interaction recording can be achieved in several ways: Optionally, a layered proxy response method can be adopted, where a protocol proxy layer is deployed within the simulation node to intercept all requests and forward them to the service simulation engine to generate responses. During the forwarding process, the proxy layer writes the complete packet and timestamp to the log cache. Simultaneously, the host monitoring module and network capture module write their respective records to the same cache. The log aggregation program then outputs the attack behavior log after associating and sorting the records of each layer based on the timestamp. Optionally, a bypass full capture method can be adopted, where all incoming and outgoing data packets are fully stored at the virtual network interface of the simulation node. A kernel-level monitoring proxy is deployed within the node to record system call events, and log hooks are deployed at the application layer to record interaction content. After the interaction ends, the analysis engine aligns the data of each layer according to the timestamp and arranges them into an attack chain view. It is understood that other methods can also be used to achieve response and log generation, which are not limited here.

[0101] In some embodiments, this step specifically includes: determining the protocol type and service response strategy matching the attack traffic based on the network asset characteristic information corresponding to the simulation node; dynamically responding to the attack traffic according to the service response strategy; maintaining multiple rounds of interaction with the attack source during the response process; capturing data at the host layer, network layer, and application layer of the simulation node during the multiple rounds of interaction; recording the operation instructions of the attack source, the response content of the simulation node, the interaction timestamp, and the protocol field content; performing time-series correlation based on the timestamps of the captured data at each layer; arranging the behavioral data scattered at different layers according to the attack stages to form an attack chain view covering the complete attack process; and outputting the attack chain view as an attack behavior log.

[0102] The service response strategy refers to a set of predefined response rules for specific protocol types and request methods by the simulation node, including response message templates, payload content generation logic, and response latency parameters. Dynamic response refers to the process by which the simulation node selects the corresponding response template and generates a targeted response message in real time based on the specific content of each request from the attack source, unlike static responses that always return the same content. The attack chain view is a structured record of the entire attack process formed by integrating multi-layered behavioral data in chronological order and attack stages. Attack stages include reconnaissance and detection, vulnerability exploitation, privilege acquisition, lateral movement, and data acquisition.

[0103] Specifically, after the simulated node receives attack traffic data packets, the service simulation module parses the protocol header fields of the data packets to determine the protocol type, and loads the corresponding service response strategy from the network asset characteristic information based on the protocol type. The service simulation module parses the method field and parameter content of the request message, matches the response template corresponding to the request method from the response strategy, fills in the service version identifier, protocol option field, and business data content consistent with the real asset according to the template, introduces the response time interval according to the delay parameter, and sends the response message. The above matching and response process is repeated for subsequent requests from the attack source, maintaining multiple rounds of interaction. During the interaction process, the system executes three layers of data capture in parallel: the host layer records operation instructions and their timestamps, such as process creation, file operation, and registry modification, through system call monitoring hooks; the network layer records the source and destination addresses, ports, protocol flags, payload content, and their timestamps for each sent and received data packet through the packet capture program of the virtual network interface; and the application layer records request parameters, response content, and session state changes and their timestamps through the interaction log interface of the service simulation module. The three-layer capture data uses timestamps generated by a unified clock source. The system uses the timestamps as an alignment benchmark to establish a relationship between records of the same operation action in the three-layer data within the same time interval. According to the attack stage classification rules, the associated behavioral data is sequentially arranged into the reconnaissance and detection, vulnerability exploitation, privilege acquisition, lateral movement and data acquisition stage groups to form an attack chain view and output as an attack behavior log.

[0104] To better understand the specific process of the simulated node performing deceptive responses to attack traffic and capturing attack chain behavior in step S106 above, please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic diagram of the deep deception interaction and attack chain behavior capture process in the embodiments of this application.

[0105] like Figure 5 As shown, the process of deep deception interaction and attack chain behavior capture specifically includes the following steps:

[0106] First, the attack traffic enters the parallel network. The traffic is then redirected and routed by the traffic redirection control module to reach the simulation node in the parallel simulation network that corresponds to the target asset node.

[0107] Then, the shadow node responds. The service simulation module of the simulated node identifies the protocol type and parses the request method of the received attack traffic. It matches the corresponding protocol type and service response strategy from the configured network asset feature information, generates a response message with the same service version identifier, protocol option field and business data content as the real asset node according to the response template, and returns the source of the attack after introducing the delay defined by the timing parameter.

[0108] Next, the response carries decoy information, files, credentials, and other data. During the response process, the emulated node actively presents the honey bait data, which is pre-deployed in the file system, service directory, and database, to the attack source. The honey bait data includes simulated sensitive documents, user credential information, and database records. Each piece of honey bait data carries a unique identifier to induce attackers to carry out deep attack operations such as lateral movement or data theft.

[0109] During the ongoing multi-round interactions, the system executes data acquisition at three levels in parallel through a parallel multi-dimensional holographic capture layer: the host layer records process creation, file reading and writing, and system calls, along with their timestamps, via system call monitoring hooks; the network layer captures all raw data packets through the packet capture program of the virtual network interface, recording the source and destination addresses, ports, protocol flags, payload content, and timestamps of each sent and received data packet; and the application layer records interaction logs, including commands, files, and return content, along with their timestamps, through the interaction log interface of the service simulation module. The system continuously determines whether the interaction is still ongoing. If the attack source continues to send new requests, the simulation node continuously responds dynamically to the attack traffic according to the service response strategy and maintains multi-round interactions, while the capture modules at each layer continue to perform data acquisition.

[0110] Once sufficient interactive data has been accumulated, the system performs multi-source log aggregation, aligns and associates the data with sessions based on the unified clock source timestamp carried by the captured data from each layer, and establishes a corresponding relationship between behavioral data belonging to the host layer, network layer and application layer within the same time window.

[0111] Then, the system generates an attack chain report, which categorizes and arranges the associated behavioral data according to attack stages such as reconnaissance and detection, vulnerability exploitation, privilege acquisition, lateral movement, and data acquisition, forming an attack chain view that covers the entire attack process. The attack chain view is output as an attack behavior log, allowing security analysts to trace back the attacker's specific operating methods and path choices at each stage from a single view.

[0112] Finally, the system determines whether the attack has stopped or needs to be reset. The system monitors the interaction status between the attack source and the simulation nodes. When no new interaction behavior from the attack source is detected within a preset idle time, the current attack session is determined to have terminated. The system automatically resets the operating environment of the parallel simulation network, restores the parallel network to its initial snapshot state, restores each simulation node to its initial configuration state, and clears interaction trace data such as tools, backdoors, and operation traces left by the attacker. This restores the parallel simulation network to a clean initial environment to receive the next traction task, and the process ends.

[0113] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the proactive defense method for attack behavior based on parallel network construction in this application embodiment.

[0114] S601. Respond to attack traffic according to the configured network asset characteristic information, and record the complete interaction sequence between the attacker and the attack source to form an attack behavior log.

[0115] The configured network asset characteristic information refers to the set of service fingerprint parameters, protocol interaction templates, and business data structures loaded into the simulation node. This set determines the simulation node's response method and content format to requests. The attack source refers to the network communication endpoint that sends the attack traffic, identified by its source IP address and port. The complete interaction sequence is an ordered record of all sent and received messages between the attack source and the simulation node from the initial request to the termination of communication. The attack behavior log is a structured record file formed by associating the behavioral data at each layer of the interaction sequence according to timestamps.

[0116] Specifically, after the simulated node receives a request packet from the attack traffic, the service simulation module identifies its protocol type and request method, matches the corresponding response template from the configured network asset feature information, generates a response message carrying the real service identifier field according to the template, introduces a delay defined by timing parameters, and returns the response to the attack source, maintaining multiple rounds of interaction. Throughout the interaction process, the system synchronously performs three-layer data capture: the host layer records process creation, file read / write, and system calls; the network layer records the packet address, port, and payload digest; and the application layer records request parameters and response content. Each layer's record is appended with a millisecond-level timestamp. The system aligns and correlates the three layers of data based on the timestamps, classifies and arranges the correlated behavioral data according to attack stages such as reconnaissance and detection, vulnerability exploitation, lateral movement, and data acquisition, and outputs a structured attack behavior log.

[0117] S602. Perform time-series analysis on the attack operation sequences recorded in the attack behavior log, and extract the behavioral pattern features and payload features from the attack operation sequences.

[0118] The attack operation sequence refers to all attack action records arranged chronologically in the attack behavior log, with each record containing the operation type, target object, and execution time. Time sequence analysis refers to the process of statistically analyzing and identifying the sequential relationships, time intervals, and repetition patterns of actions within the operation sequence along a time dimension. Behavioral pattern features refer to structured descriptions extracted from the operation sequence, such as combinations of operation types, the order of operations, and the frequency distribution of operations, like a fixed action chain of "port scanning → vulnerability detection → command execution." Payload features refer to malicious identification information extracted from the request message payload content, including specific byte sequences, encoding patterns, and instruction keywords, such as the "UNION SELECT" string pattern appearing in an SQL injection payload.

[0119] Specifically, the system reads attack behavior logs and constructs an ordered time series of all operation records using timestamps as the sorting key. A sliding window scan is performed on this time series, with the window length set to a fixed time interval. Within each window, the frequency of each operation type is counted, and the average time interval between adjacent operations is calculated. The system establishes a state transition matrix for the transition relationships of operation types within the window. Each element in the matrix records the transition probability from operation type A to operation type B, and transition paths exceeding a preset threshold are extracted as behavioral pattern features. Simultaneously, the system performs regular expression pattern matching and N-gram segmentation on the payload field of each request message in the operation sequence, extracting byte sequences, encoding features, and instruction fragments that appear more than a preset number of times and are not present in normal traffic as payload features. Behavioral pattern features and payload features are output in structured field format for subsequent detection rule generation.

[0120] S603. Generate new detection rules based on behavioral pattern features and load features.

[0121] Among them, behavioral pattern features refer to the structured description of the combination of operation types, the sequence of actions, and the frequency distribution extracted in the previous step. Payload features refer to the specific byte sequences, encoding patterns, and instruction keywords in the malicious payload extracted in the previous step. New detection rules refer to matching condition statements generated based on the above features, used to identify similar attack behaviors during traffic detection. Their format is consistent with the rule syntax of the traffic detection engine. For example, the Snort rule format contains a complete rule entry with protocol, port, content matching fields, and triggering actions.

[0122] Specifically, the system converts extracted behavioral pattern features into temporal matching conditions, maps operation type transition paths to flow state matching fields in rules, and maps time interval ranges to flow timeout parameters in rules. The system converts byte sequences in payload features into content matching fields in rules, encoding patterns into regular expression matching conditions, and instruction keywords into precise string matching items. Following the rule syntax template of the detection engine, the system assembles the above matching conditions into complete detection rule entries, setting the protocol scope, direction, matching logic, and triggering action of the rules. For rules generated from behavioral pattern features, an ordered multi-condition joint matching method is used, requiring all operation type conditions to be matched sequentially within a specified time window before triggering; for rules generated from payload features, a single-packet content matching method is used, triggering an alarm when the feature string is matched in a single data packet payload.

[0123] S604. After validating the new detection rules, add them to the attack traffic detection process.

[0124] Validation refers to the process of testing and evaluating the detection capabilities and false positive rate of newly added detection rules before their formal deployment. A false positive occurs when a detection rule incorrectly identifies normal traffic as attack traffic. A false negative occurs when a detection rule fails to identify known attack traffic. Adding validated rules to the detection process involves loading the validated rules into the traffic detection engine's runtime rule library for real-time traffic matching.

[0125] Specifically, the system loads new detection rules into a separate test detection engine, and performs replay tests on the rules using both attack sample sets and normal traffic sample sets. The attack sample set consists of raw attack traffic recorded in the attack behavior log, while the normal traffic sample set consists of business traffic collected from the real network. After performing rule matching on the two sets of samples, the test detection engine outputs the detection results. The system calculates the hit rate of the rule for attack samples and the false positive rate for normal samples. The hit rate is calculated as the number of hit attack samples divided by the total number of attack samples; the false positive rate is calculated as the number of falsely reported normal samples divided by the total number of normal samples. When the hit rate is higher than a preset hit rate threshold and the false positive rate is lower than a preset false positive rate threshold, the rule validity verification is passed, and the system writes the rule into the running rule library of the traffic detection engine. The detection engine uses the updated rule library to perform real-time matching on traffic during subsequent traffic detection processes.

[0126] S605. Monitor the outbound traffic of the parallel simulation network in real time, and based on the preset outbound access control policy, block connection requests initiated from inside the parallel simulation network to the real network or external network.

[0127] Outbound traffic refers to all data packets sent from each simulation node within the parallel simulation network to the outside of the parallel simulation network. Preset outbound access control policies refer to a pre-configured set of outbound traffic filtering rules, which defines the allowed and prohibited destination address ranges, port ranges, and protocol types. Blocking means directly discarding data packets that match a blocking rule without forwarding them.

[0128] Specifically, the system deploys an outbound traffic filtering module at the virtual gateway egress of the parallel simulation network. This module performs packet-by-packet inspection on all data packets originating from simulation nodes whose destination addresses do not belong to the internal address range of the parallel simulation network. The filtering module extracts the destination address, destination port, and protocol type of each data packet and matches them against the rules in the preset outbound access control policy. The default rule of the preset outbound access control policy is to deny all outbound connections and only allow specific control channel traffic necessary for communication between nodes within the parallel simulation network and for system management. When an attacker implants malicious programs inside a simulation node and attempts to initiate reverse connections, data backhauls, or lateral movement to the real network or external networks, the filtering module detects that the destination address of the data packet is within the prohibited range, immediately discards the data packet, and records the source address, destination address, port, and time information of the blocked connection in the security log, ensuring that the attack is restricted to the scope of the parallel simulation network.

[0129] S606. Monitor the interaction status between the attack source and the simulation nodes. When no new interaction behavior of the attack source is detected within a preset idle time, automatically reset the running environment of the parallel simulation network, restore each simulation node to its initial configuration state, and clear the attack trace data.

[0130] The interaction status refers to the real-time status of the current communication activity between the attack source and the emulator node, including the existence of active connections and the time of the most recent data packet reception. The preset idle time is a pre-set threshold for determining when the interaction will terminate, for example, set to 300 seconds. The initial configuration status refers to the baseline state of the operating system snapshot and service configuration loaded when the emulator node first starts. Attack trace data refers to all residual data generated by the attacker on the emulator node during the interaction process, including implanted files, created accounts, modified configurations, and generated logs.

[0131] Specifically, the system maintains the last active timestamp of each simulation node, updating this timestamp to the current time whenever a simulation node receives a data packet from an attack source. The system reads the last active timestamp of each simulation node at fixed intervals and calculates the difference between the current time and the last active timestamp. When this difference exceeds a preset idle time, the system determines that the attack interaction of that simulation node has terminated and triggers an environment reset process. The reset process first terminates all currently running processes and network connections of the simulation node, then rolls back the disk state of the simulation node to a pre-saved initial operating system snapshot, reloads the initial service configuration and network asset characteristic information, clears attack trace data such as temporary files, newly added accounts, and system logs generated during operation, and finally restarts each service simulation module to restore the simulation node to a ready state to receive new attack traffic.

[0132] The server in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference]. Figure 7 This is a schematic diagram of the physical device structure of a server in an embodiment of this application.

[0133] It should be noted that, Figure 7 The server structure shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0134] like Figure 7 As shown, the server includes a CPU 701, which can perform various appropriate actions and processes according to a program stored in ROM 702 or a program loaded into RAM 703 from storage section 708, such as performing the methods described in the above embodiments. RAM 703 also stores various programs and data required for system operation. CPU 701, ROM 702, and RAM 703 are interconnected via bus 704. I / O interface 705 is also connected to bus 704.

[0135] The following components are connected to I / O interface 705: input section 706 including audio input devices, push-button switches, etc.; output section 707 including liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 708 including hard disks, etc.; and communication section 709 including network interface cards such as LAN (Local Area Network) cards, modems, etc. Communication section 709 performs communication processing via a network such as the Internet. Drive 710 is also connected to I / O interface 705 as needed. Removable media 711, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 710 as needed so that computer programs read from them can be installed into storage section 708 as needed.

[0136] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by CPU 301, it performs the various functions defined in the present invention.

[0137] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0138] Specifically, the server in this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the proactive defense method for attack behavior based on parallel network construction provided in the above embodiment.

[0139] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the server described in the above embodiments; or it may exist independently and not assembled into the server. The storage medium carries one or more computer programs that, when executed by a processor of the server, cause the server to implement the proactive attack defense method based on parallel network construction provided in the above embodiments.

[0140] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0141] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

Claims

1. A proactive defense method for attack behaviors based on parallel network construction, characterized in that, Applied to a server, the method includes: The external services of each asset node in the real network are probed and traffic is analyzed to obtain the network asset characteristic information of each asset node. The network asset characteristic information includes service fingerprint, protocol interaction timing characteristics and business data content. In a sandbox environment isolated from the real network, corresponding simulation nodes are generated for each asset node based on the network asset characteristic information, and each simulation node is configured to generate a response consistent with the network asset characteristic information of the corresponding asset node to the same type of request. Multiple simulation nodes are networked according to the topology of the real network to form a parallel simulation network; Detect whether there is any attack traffic targeting the target asset node in the real network; If present, the destination address of the attack traffic is redirected to the address of the simulation node in the parallel simulation network corresponding to the target asset node, and the attack traffic is forwarded to the corresponding simulation node; The system responds to the attack traffic according to the configured network asset characteristic information and records the complete interaction sequence between the attacker and the attack source, forming an attack behavior log.

2. The method according to claim 1, characterized in that, The step of detecting whether there is attack traffic targeting the target asset node in the real network specifically includes: Behavioral analysis is performed on the real-time traffic flowing to the target asset node to calculate the deviation between the real-time traffic and the preset normal business behavior baseline; When the deviation exceeds a preset threshold, the association verification is performed by combining the intrusion detection rule base and threat intelligence to obtain the association verification result; Based on the correlation verification results, it is determined whether the real-time traffic is attack traffic.

3. The method according to claim 1, characterized in that, The step of redirecting the destination address of the attack traffic to the address of the simulation node in the parallel simulation network corresponding to the target asset node specifically includes: Record the connection status information of the current attack session corresponding to the attack traffic; The connection status information is synchronized to the simulation node, enabling the simulation node to establish a mirror session corresponding to the attack session based on the connection status information. After the mirror session is established, the destination address of the attack traffic is switched to the address of the emulator node, and the emulator node continues to interact with the attacker through the mirror session.

4. The method according to claim 1, characterized in that, The step of responding to the attack traffic according to the configured network asset characteristic information and recording the complete interaction sequence with the attack source to form an attack behavior log specifically includes: Based on the network asset characteristic information corresponding to the simulation node, determine the protocol type and service response strategy that match the attack traffic; The attack traffic is dynamically responded to according to the service response strategy, and multiple rounds of interaction with the attack source are maintained during the response process. During the multiple rounds of interaction, data is captured at the host layer, network layer, and application layer of the simulation node, respectively, and the operation instructions from the attack source, the response content of the simulation node, the interaction timestamp, and the protocol field content are recorded. Based on the timestamps of the captured data at each layer, the time-series correlation is performed, and the behavioral data scattered at different layers are arranged according to the attack stage to form an attack chain view covering the complete attack process. The attack chain view is then output as an attack behavior log.

5. The method according to claim 1, characterized in that, After the step of forming an attack behavior log by recording the complete sequence of interactions between the record and the attack source, the method further includes: A time-series analysis is performed on the attack operation sequences recorded in the attack behavior log to extract behavioral pattern features and payload features from the attack operation sequences; New detection rules are generated based on the behavioral pattern features and the load features; After validating the new detection rule, the new detection rule is added to the attack traffic detection process.

6. The method according to claim 1, characterized in that, After the step of forming an attack behavior log by recording the complete sequence of interactions between the record and the attack source, the method further includes: Real-time monitoring of outbound traffic of the parallel simulation network; blocking connection requests initiated from within the parallel simulation network to the real network or external network based on a preset outbound access control policy. The system monitors the interaction status between the attack source and the simulation node. When no new interaction behavior of the attack source is detected within a preset idle time, the system automatically resets the operating environment of the parallel simulation network, restores each simulation node to its initial configuration state, and clears attack trace data.

7. The method according to claim 1, characterized in that, After the step of networking multiple simulation nodes according to the topology of the real network to form a parallel simulation network, the method further includes: Deploy honey bait data in the simulation node; the honey bait data includes simulated sensitive documents, user credential information, and database records. A unique identifier is set for the bait data, and when the attack source accesses the simulation node, the bait data is actively presented to the attack source. When the bait data is accessed or transmitted by the attack source, a tracking alarm is triggered based on the unique identifier, and the access record of the bait data is associated with the attack behavior log.

8. A server, characterized in that, The server includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the server to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the server, the server causes the server to perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the server, the server performs the method as described in any one of claims 1-7.

Images