Adaptive network deception system and method based on dynamic honeypot

Abstract

The application discloses a dynamic honey point-based adaptive network decoy system and method, relates to the technical field of network decoy defense, and comprises the following steps: receiving original traffic data and performing traffic splitting; threat feature matching is performed on the split traffic data, and traffic data of different attack types is compared with a model corresponding to the attack type; an optimized honey point deployment structure is generated according to an attack mode label and a current network topology, the deployment position of the honey point node is dynamically changed through a dynamic migration and address switching mechanism; the response probability of the honey point is adjusted based on real-time threat intelligence, and attack traffic is guided to the corresponding honey point by using a strategy mapping rule; and real network resources are isolated and protected. Through parallel traffic decomposition, attack mode label matching, dynamic honey point optimization, decoy strategy distribution and the like, the application improves attack capture efficiency, threat tracing accuracy and the persistence and adaptive ability of the defense system, and realizes the change from passive defense to active decoy capture.

Description

Technical Field

[0001] This invention relates to the field of network deception defense technology, specifically to an adaptive network deception system and method based on dynamic honeypots. Background Technology

[0002] A decoy system is a technology that integrates dynamic honeypots (virtual or physical nodes deployed in a network to deceive attackers), automated policy adjustments, adaptive security mechanisms, and a systematic defense architecture. By deploying flexible and adaptable decoy nodes in the network, combined with real-time threat perception and decision-making mechanisms, the number, type, and location of honeypots are dynamically adjusted. This effectively confuses, delays, and monitors attacker behavior, improving the stealth and persistence of the defense while capturing high-value intelligence early in the attack lifecycle. This transforms the system from passive defense to proactive decoy and threat intelligence gathering.

[0003] However, decoy systems still have some shortcomings in their current use: 1. Existing systems mostly rely on a single data collection point or centralized monitoring platform for traffic analysis, lacking the ability to fine-grained decomposition and parallel processing of multi-entry and multi-session data. This results in significant delays in protocol identification and threat feature extraction when facing high-speed, large-scale attack traffic, making it easy to miss the opportunity to intervene in the early stages of the attack lifecycle; 2. Existing dynamic honeypot / honeynet deployments are mostly homogeneous layouts, lacking a layered structure that isolates across security domains or virtualizations. This means that once attackers identify honeypot features, they may bypass them in batches, causing the defense surface to fail rapidly. Furthermore, deployment adjustments are mostly based on timed or manual triggering, lacking adaptive linkage with the real-time threat situation.

[0004] Based on this, we now provide an adaptive network deception system and method based on dynamic honeypots, which can eliminate the drawbacks of existing technical solutions. Summary of the Invention

[0005] The purpose of this invention is to provide an adaptive network deception system and method based on dynamic honeypots to solve the problems in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] The adaptive network deception method based on dynamic honeypots includes the following steps:

[0008] Step S1: Receive raw traffic data from the network ingress and monitoring nodes, perform protocol identification and threat feature analysis on the raw traffic data, and split the raw traffic data according to the target address, port and session characteristics to obtain multi-channel traffic data;

[0009] Step S2: Perform threat feature matching on the multi-path traffic data after splitting, compare the traffic data of different attack types with the corresponding attack type model, and transform the unclassified attack traffic into specific threat data with attack pattern labels.

[0010] Step S3: Based on the attack mode label and the current network topology, generate an optimized honeypot deployment structure, distribute the honeypot nodes in multiple different security domains or virtualization environments, deploy an equal number of honeypot instances with different service profiles in each domain, and make the deployment location of the honeypot nodes dynamically change through dynamic migration and address switching mechanisms.

[0011] Step S4: While keeping the geometric topology of the honeypot unchanged, adjust the response probability of the honeypot based on real-time threat intelligence so that the response probability of honeypots at different levels conforms to the hierarchical decreasing characteristics of a Maxwell-Boltzmann distribution. Then, use policy mapping rules to guide attack traffic to the corresponding honeypot to achieve the deceptive effect of probability shaping.

[0012] Step S5: After receiving the interaction data from the honeypot, determine the attacker's true intention and location based on the honeypot deployment structure and deception strategy. Use a honeycomb-shaped threat judgment area to determine the honeypot to which the attack belongs, restore the attack chain, isolate and protect the real network resources, map the interaction data back to the original threat signature format, and generate a security event log.

[0013] Further, step S1 specifically includes:

[0014] Step S11: Receive raw traffic data from the network ingress and monitoring nodes;

[0015] Step S12: The raw traffic data is split according to the destination address, port and session characteristics;

[0016] Step S13: Maintain the protocol label stack in each session, adjust the labels according to the arrival of subsequent messages, and record the confidence score and evidence fragment index.

[0017] Step S14: Parallel execution of protocol identification and threat feature analysis, generating threat clue objects based on rule matching and anomaly scoring, and allocating traffic to multiple processing channels through session stickiness and target relevance.

[0018] Further, step S2 specifically includes:

[0019] Step S21: Generate a multi-granularity feature vector for each session, wherein the multi-granularity feature vector includes stream-level statistics, session semantics, sequence features, and intelligence and asset context;

[0020] Step S22: Based on the protocol tag stack, asset type and intelligence signal, select a set of candidate models that are compatible with the protocol and attack type from the registry, and adjust the priority of the candidate models according to the importance of the business and the recent alarm density.

[0021] Step S23: Perform rule matching on each session feature, execute multi-segment site matching, keyword adjacency constraint and state machine tracking, and use fingerprint matching and rule graph matching to perform in-depth analysis of binary load, and output rule hit results;

[0022] Step S24: Score statistical and short sequence features using a lightweight model, then perform time-series inference on the scoring results using a deep model, and perform similarity retrieval based on a known attack family embedding library;

[0023] Step S25: Merge the rule hit results with the deep model's scoring results to form the final label. Generate labels according to the hierarchical threshold strategy, and record the confidence level, evidence citation, and explanatory summary to form the attack label object.

[0024] Furthermore, step S3 specifically includes:

[0025] Step S31: Based on the current network topology and threat situation information, collect information on subnets, switching nodes, routing nodes, computing hosts, policy domains, resource usage, and threat tags, and generate a scenario snapshot;

[0026] Step S32: Based on the collected scene snapshots, generate an optimized honeypot deployment structure, and make the honeypot locations dynamically change through dynamic migration and address switching mechanisms;

[0027] Step S33: Select a honeypot instance profile that matches the target domain from the predefined service profile library;

[0028] Step S34: Based on the network topology diagram and resource list, filter candidate hosts and allocate honeypot instances according to capacity constraints and resource health indicators;

[0029] Step S35: Based on the attack traffic heat map and network topology, adjust the distribution of honeypot instances, increase honeypot instances in high-attack areas, maintain equal quantity constraints across all domains, and adjust the instance configuration of other domains according to the security limit.

[0030] Furthermore, step S3 also includes:

[0031] During honeypot deployment and migration, mutations are injected to simulate the behavior of real assets within the domain, ensuring that the honeypots are consistent with the real assets within the domain. The behavior of the real assets within the domain includes the fingerprint, response pattern, and timing behavior of the honeypot instance.

[0032] Continuously monitor the health status and behavior patterns of honeypot instances, and calibrate honeypot fingerprints and behaviors in real time. If the actual fingerprints and behaviors of a honeypot deviate from the preset security policies, a calibration operation is performed to revert the honeypot fingerprints and behaviors to an acceptable security configuration.

[0033] Furthermore, in step S4, while maintaining the honeypot's geometric topology, the honeypot response probability is adjusted based on real-time threat intelligence, specifically including:

[0034] Based on the context of the attack traffic and combined with the honeypot level metadata, the health and capacity reserves of the honeypot instance are read, and the priority of each session is calculated. The priority is determined by the threat intensity factor, asset-related factor, and resource security factor.

[0035] Based on the hierarchical decreasing characteristic of the Maxwell-Boltzmann distribution, a target response probability is set for honeypots at different levels, and normalization is performed within each level according to the factor weights of the honeypot instances to obtain the target response probability for each honeypot instance.

[0036] Furthermore, in step S4, the attack traffic is directed to the corresponding honeypot using policy mapping rules, specifically including:

[0037] Verify whether the request rate corresponding to the target response probability exceeds the capacity threshold of the honeypot instance. If it exceeds the capacity threshold, adjust the request rate and ensure that it complies with the isolation strategy and micro-segmentation rules. At the same time, introduce random jitter and smoothing to prevent attackers from detecting a fixed probability.

[0038] Traffic is randomized by generating deterministic pseudo-random seeds and directed to the target honeypot based on the execution probability.

[0039] The acceptance probability and interaction depth of the instance for new connections are determined based on the target response probability. In risky scenarios, latency and error perturbation are added. For requests that are not accepted, a silent response or a general rejection is returned.

[0040] Within the time window, probability changes are smoothly controlled, and jitter is injected to prevent long-term observations from fitting a fixed probability.

[0041] Furthermore, step S5 specifically includes:

[0042] Step S51: Receive raw interactive data from the honeypot and network boundary devices;

[0043] Step S52: Assign a global event ID to each interaction event and align the time baselines.

[0044] Step S53: For each interaction event, cluster the interaction facts according to the session key and connection direction, sort them by time within the session, sort the commands, file operations and error events to form an action sequence, establish suspicious dependency edges across sessions, and generate an interaction graph.

[0045] Step S54: Based on the location of honeycomb instances and defense boundaries, divide the threat judgment area into honeycomb-shaped regions using reachable path costs;

[0046] Step S55: Calculate the honeypot ID of each interaction event, select the honeypot with the lowest path cost and the policy allowed as the honeypot, output the attribution result object, and mark the confidence level and evidence summary.

[0047] Step S56: Combining the semantics of the MITREATT&CK framework with the context of the decoy script, the attributed interactive events are reconstructed into a phased attack chain. Constraints are established before and after the attack stage dependency table, and topological sorting is performed according to the strength of evidence and time order.

[0048] Furthermore, the raw interaction data in step S51 includes connection metadata, application logs, command traces, file forensics, kernel audit events, and traffic slices.

[0049] An adaptive network deception system based on dynamic honeypots is used to implement an adaptive network deception method based on dynamic honeypots, including:

[0050] The perception and tagging unit is used to receive raw traffic data, complete protocol identification, threat feature analysis and fingerprint extraction, and perform multi-path splitting according to target address, port and session 5-tuple, and perform attack behavior feature matching and attack pattern tag generation operations for each traffic path.

[0051] The dynamic deception orchestration unit is used to generate honeypot deployment structures based on attack mode tags and the current network topology, and then distribute them to the virtualization environment for execution. It combines real-time threat intelligence to calculate probabilistic deception strategies and generate traffic redirection rules and response strategy tables.

[0052] The interactive decision and handling unit is used to apply honeycomb geometry-like decision-making to determine the attribution of the honeycomb and the stage of the attack path based on the honeycomb deployment structure and deception strategy, and to reconstruct the attack chain accordingly. It then performs handling actions on production network resources and generates security event logs and indicator assessments.

[0053] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0054] 1. This invention splits the raw traffic data into multiple paths according to the target address, port and session characteristics, and performs protocol identification and threat analysis in parallel through multiple processing channels to achieve high-speed parallel processing and shorten the time from traffic reception to threat identification;

[0055] 2. This invention features multi-granularity feature vectors covering flow-level statistics, conversation semantics, sequence features, and asset context. By combining rule-based hit results with deep model collaborative analysis, it ensures accurate hits on known threats and enhances the identification of unknown threats through similarity retrieval and temporal inference. Through a tag fusion mechanism, it effectively reduces false positive and false negative rates.

[0056] 3. This invention effectively improves the anti-identification capability and overall defense durability of honey spots by deploying honey spots with different service profiles in equal numbers in different security domains and virtualization environments, and by combining dynamic migration and address switching mechanisms, while reducing the risk of attackers bypassing single-point defenses.

[0057] 4. This invention uses a Maxwell-Boltzmann distribution-like response probability design, combined with session priority evaluation, to dynamically adjust the response probability of honeypots at different levels, guiding attackers to core honeypots, achieving optimal allocation of decoy resources, improving the capture rate of high-value intelligence, and also features a honeycomb-shaped threat judgment area based on reachable path cost, which can clearly define the defense boundaries between honeypots, making it more suitable for complex network topologies and multi-domain isolation scenarios. Attached Figure Description

[0058] Figure 1 This is a schematic diagram illustrating the steps of the adaptive network deception method of the present invention.

[0059] Figure 2 This is a schematic diagram of the adaptive network deception system of the present invention.

[0060] Figure labeling: Perception and labeling unit 10, dynamic deception arrangement unit 20, interactive judgment and processing unit 30. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0062] Example 1

[0063] In this embodiment, as Figure 1 As shown, this invention provides an adaptive network deception method based on dynamic honeypots, specifically including the following steps:

[0064] Step S1: Receive raw traffic data from the network ingress and monitoring nodes, perform protocol identification and threat feature analysis on the raw traffic data, and split the raw traffic data according to the target address, port and session characteristics to obtain multi-channel traffic data;

[0065] Step S2: Perform threat feature matching on the multi-path traffic data after splitting, compare the traffic data of different attack types with the corresponding attack type model, and transform the unclassified attack traffic into specific threat data with attack pattern labels.

[0066] Step S3: Based on the attack mode label and the current network topology, generate an optimized honeypot deployment structure, distribute the honeypot nodes in multiple different security domains or virtualization environments, deploy an equal number of honeypot instances with different service profiles in each domain, and make the deployment location of the honeypot nodes dynamically change through dynamic migration and address switching mechanisms.

[0067] Step S4: While keeping the geometric topology of the honeypot unchanged, adjust the response probability of the honeypot based on real-time threat intelligence so that the response probability of honeypots at different levels conforms to the hierarchical decreasing characteristics of a Maxwell-Boltzmann distribution. Then, use policy mapping rules to guide attack traffic to the corresponding honeypot to achieve the deceptive effect of probability shaping.

[0068] Step S5: After receiving the interaction data from the honeypot, determine the attacker's true intention and location based on the honeypot deployment structure and deception strategy. Use a honeycomb-shaped threat judgment area (based on the defense boundary between adjacent honeypots) to determine the honeypot to which the attack belongs, restore the attack chain, isolate and protect the real network resources, map the interaction data back to the original threat feature format, and generate a security event log.

[0069] The construction of a honeycomb-shaped threat decision region includes: using each honey point instance as a seed, reading its network location (subnet, routing cost, ACL) and security domain label; for any network point, defining the cost metric as: the minimum reachable path cost from that point to the honey point; if it is unreachable, it is considered invalid; using the perpendicular bisector of the equal cost of adjacent honey points as the boundary to form partition units; and outputting a honeycomb region table: each region is bound to a unique standard honey point, valid path characteristics, and policy label.

[0070] In this embodiment, step S1 specifically includes:

[0071] Step S11: Receive raw traffic data from network entry points (such as routers, firewalls, IDS / IPS devices) and monitoring nodes (such as distributed sensors). The raw traffic data typically includes the header information and payload of network packets.

[0072] Step S12: The raw traffic data is split according to the destination address, port and session characteristics;

[0073] Specifically, an initial candidate set is established based on Ethernet type, IP version, transport layer number, and port whitelist. Lightweight features such as magic string / start byte sequence, length and direction pattern, JA3 / JA4 fingerprint (TLS), HTTP start line and key header, and DNS message structure legality flags are extracted from the first messages in the first few directions. Multi-segment position matching and state machine tracking (such as Aho-Corasick style multi-pattern matching or finite state machine) are performed on each candidate protocol set. When a conflict occurs, the priority is adjusted according to feature coverage and false trigger cost.

[0074] In multi-segment position matching, for the HTTP protocol, the first segment matching position is selected from the first 64 bytes of the starting line, the starting position of the Host header field, and the starting position of the Content-Type header field. The matching pattern adopts the Aho-Corasick automaton, and the corresponding pattern set consists of known HTTP specification keywords and common attack payloads.

[0075] For protocols that are difficult to distinguish by rules (such as custom binary / private RPC), enable a lightweight classifier (such as a gradient model based on message length sequence, direction sequence, first packet byte distribution and arrival time) to provide alternative labels and confidence scores;

[0076] Step S13: Maintain the protocol label stack in each session, adjust the labels according to the arrival of subsequent messages, and record the confidence score and evidence fragment index.

[0077] As more messages arrive, the label can be upgraded or downgraded, and a confidence score and evidence fragment index can be recorded for the current label (for auditing and backtracking). The protocol label stack is a data structure that records the session protocol identification results. It supports the coexistence of "outer label" and "inner inferred label" for subsequent threat analysis.

[0078] Step S14: Parallel execution of protocol identification and threat feature analysis. Threat clue objects are generated based on rule matching and anomaly scoring. Traffic is distributed to multiple processing channels through session stickiness and target relevance. When decryption is not possible, protocol identification is labeled with handshake fingerprint and traffic timing. Threat feature analysis focuses on anomaly measurement and intelligence hit.

[0079] For example: If an HTTP traffic packet is received, which contains the source IP (e.g., 192.168.1.100) and destination IP (e.g., 10.0.0.5) of the request message, as well as the corresponding HTTP request content (e.g., GET request), and the original traffic data contains multiple sessions, the system will allocate traffic according to the destination IP (e.g., 10.0.0.5) and port (e.g., port 80, representing HTTP traffic) in the session;

[0080] Traffic 1: Destination is 10.0.0.5, port 80 (HTTP), this session is assigned to the HTTP processing channel;

[0081] Traffic 2: Destination is 10.0.0.7, port 443 (HTTPS), this session is assigned to the HTTPS processing channel;

[0082] Session 1 (destination IP: 10.0.0.5, port 80) received an HTTP request message. The system marked the session with the "HTTP" protocol in the protocol tag stack with an initial confidence level of 0.85. Subsequently, when more messages (such as HTTP response messages) were received, the system analyzed the characteristics of these messages and confirmed that the traffic was indeed HTTP traffic. Therefore, the confidence level of the "HTTP" tag in the tag stack was increased to 0.95.

[0083] Rule matching was performed on Session 1 (HTTP traffic), and it was found that the URL of the traffic contained characteristic words of known SQL injection attacks (such as "UNION"). Therefore, the system matched the SQL injection rule and generated a threat clue object. Anomaly scoring was performed on Session 2 (HTTPS traffic), and it was found that the packet size of the session was abnormal (for example, a small HTTPS request was followed by a huge data packet). The system gave it a high anomaly score and generated a related threat clue object.

[0084] HTTP traffic in Session 1 will be continuously allocated to the HTTP channel to ensure the continuity of subsequent processing. Since the target of HTTPS traffic in Session 2 is the same server (10.0.0.5), even if the traffic comes from different sources, the system will still allocate it to the adjacent HTTPS processing channel for analysis.

[0085] Suppose that the traffic of Session 1 contains the following characteristics: Source IP: 192.168.1.100; Destination IP: 10.0.0.5; Port: 80 (HTTP); The request content contains SQL injection characteristics (such as "UNIONSELECT").

[0086] The calculation process includes: traffic is matched against predefined SQL injection rules, matching items are found, and an SQL injection threat clue object is generated based on the rule matching results. This object includes the attack type (SQL injection), confidence level (0.95), matching rule ID, and key features (such as the SQL keyword "UNION"). The traffic of this session is evaluated as high abnormal traffic (such as the SQL keyword "UNION" appearing in the URL), with a score of 0.9.

[0087] Suppose that the traffic of Session 2 has the following characteristics: Source IP: 192.168.2.200; Destination IP: 10.0.0.7; Port: 443 (HTTPS); Packet size: Large;

[0088] Calculation process: At the start of the session, the system identifies port 443 and initially marks it as "HTTPS". After in-depth analysis, it is found that the traffic may contain non-standard HTTPS traffic (such as requests with abnormally high load). The system further evaluates the traffic based on known HTTPS characteristics. Due to the abnormality of the traffic, the system may reduce its confidence level to 0.75, but still keep it labeled as HTTPS.

[0089] In this embodiment, step S2 specifically includes:

[0090] Step S21: Generate a multi-granularity feature vector for each session. The multi-granularity feature vector includes flow-level statistics, session semantics, sequence features, and intelligence and asset context. For example, if an HTTP traffic session is received, after feature extraction, the features include: the flow-level statistics direction ratio is 1:2, the average packet length is 300 bytes, the session semantics contain the SQL keywords "DROP" and "SELECT", the sequence features contain the error code "404", and the intelligence and asset context IP is a malicious IP on the blacklist.

[0091] Flow-level statistics include direction ratio (send / receive ratio), first packet size, average packet length, burstiness, arrival time jitter, repetition rate, RST / ICMP anomalies, and TLS fingerprint rarity. For example, if the average packet length of a session is 200 bytes and the RST anomaly rate is 10%, it may indicate a TCP connection problem or a scanning attack. Session semantics include protocol methods, status code sequences, field out-of-bounds indications, frequency of key parameters (such as SQL keywords, PowerShell fragments, compression and packing indicators), and authentication failure sequences. For example, excessive SQL keywords in an HTTP session may be a sign of an SQL injection attack. Sequence features are extracted from time series, including length-direction-time triple sequences, field change trajectories, and error code patterns. For example, a combination of DNS query requests and abnormally large packets can indicate a DNS tunnel. Intelligence and asset context include source autonomous system reputation, IOC (Indicator of Compromise) hits, target asset exposure surface, and business sensitivity. For example, if the target asset has a high level of business importance and the source IP is a malicious IP on a blacklist, the traffic is more threatening.

[0092] Step S22: Based on the protocol tag stack, asset type, and intelligence signals, the system filters a set of candidate models that match the protocol and attack type from the registry. The priority of the candidate models is adjusted according to business importance and recent alarm density. For example, for HTTP traffic, models such as Web injection, cross-site scripting (XSS), and malicious file upload might be selected. Based on business importance (such as core assets and sensitive data) and recent alarm density (alarm frequency and urgency), the system adjusts the priority of the candidate models. For example, if core assets frequently trigger abnormal traffic, the traffic from that asset will be given higher priority for analysis.

[0093] Step S23: Perform rule matching on each session feature, execute multi-segment site matching, keyword adjacency constraint and state machine tracking, and use fingerprint matching and rule graph matching to perform in-depth analysis of binary payload, and output rule hit results, including the matched rule ID, the reference of the hit segment, severity level and confidence suggestion;

[0094] The specific rules matching includes: matching specific patterns in key fields (such as Host, User-Agent, etc.) in the HTTP request header using multi-segment site matching technology; when checking for SQL injection, the system will detect whether SQL keywords (such as SELECT, DROP, etc.) are adjacent; if multiple keywords are close together, it may indicate a malicious request.

[0095] State machine technology is used to track protocol parsing. For example, in the SMB protocol, the system checks for abnormal behavior based on the state machine model of requests and responses. Fingerprint matching and rule graph matching are performed on binary payloads (such as malicious files and compressed packages) to check whether they contain known malicious payloads. For example, if a file contains a known virus fingerprint, it indicates that it may be a malicious file upload attack.

[0096] Step S24: Score statistical and short sequence features using a lightweight model, then perform time-series inference on the scoring results using a deep model, and perform similarity retrieval based on a known attack family embedding library. Output a model score table (one score channel for each attack type) and an important feature explanation list (such as Shapley order or feature contribution ranking, for easy auditing).

[0097] The scoring process specifically includes: if a session scores in the model as (SQL Injection: 0.7, XSS: 0.3, Normal: 0.05), the score is based on statistics and short sequence features for rapid evaluation. If the lightweight model has high uncertainty or there are unknown attack patterns, the system will trigger deep models such as RNN or Transformer to perform time series inference, analyze the time series patterns in the traffic, such as command input based on time sequence, and identify typical features of lateral movement attacks.

[0098] The similarity retrieval process specifically includes: if a traffic item is similar to a known BruteForce attack pattern, the model will output the relevant attack type based on the similarity score;

[0099] Step S25: Merge the rule hit results with the deep model's scoring results to form the final label. Generate labels according to the hierarchical threshold strategy, and record the confidence level, evidence citation, and explanatory summary to form an attack label object. The attack label object includes an attack type enumeration, confidence level, evidence list, attack label generation time, and version stamp. To cope with business changes and attack evolution, the system has a built-in online calibration and backfeed mechanism. It receives the judgment and sample citation from step S5, performs survival analysis on the rule hit results statistics, and records the version number and effective time of all changes to ensure that the audit can be replayed.

[0100] The rule-hitting results (high-weighted evidence) are fused with the scoring results of the deep model (medium-weighted results) to generate the final label. The fusion method is as follows:

[0101] During the fusion process, each piece of evidence is weighted, and the weights are adjusted based on business importance: For the same attack type, if the rule hit result has a higher weight, the system will prioritize rule evidence; if the rule hit result has a weaker weight, the system will focus on the inference from the deep model; if the rule evidence is strong or the deep model score is consistent, the final label will be directly output. For example: if the SQL injection rule hits and the deep model score is high, it will be directly labeled as "SQL injection"; if the rule is weak but the deep model score is high, a provisional label of "suspected + type" will be output; if the deep model score is high but the rule does not match perfectly, it will be labeled as "suspected Web injection"; if both the rule and deep model scores are insufficient, the label "unclassified but abnormal" will be output, and the evidence will be retained for subsequent analysis.

[0102] In this embodiment, step S3 specifically includes:

[0103] Step S31: Based on the current network topology and threat situation information, collect information on subnets, switching nodes, routing nodes, compute hosts, policy domains, resource usage, and threat tags to generate a scenario snapshot. Collect three types of statuses: First, a topology map, where nodes include subnets, switching / routing nodes, compute hosts, and policy domains, and edges include reachability, ACL / routing policies, and latency jitter; second, a resource list, including the CPU / memory / storage / acceleration resource usage and availability of hosts, as well as virtualization / container platform quotas and image distribution status; and third, a threat situation derived from attack pattern tag distribution (type, intensity, target concentration, and recent window trend) and asset importance classification. All of this information is standardized into a unified scenario snapshot.

[0104] Step S32: Based on the collected scene snapshots, generate an optimized honeypot deployment structure, and make the honeypot locations dynamically change through dynamic migration and address switching mechanisms;

[0105] Step S33: Select honey spot instance images that match the target domain from the predefined service image library. In the similarity matrix calculation, the similarity score between each image and the candidate images consists of three parts: fingerprint feature similarity, port combination similarity, and application semantic similarity. The final similarity is the weighted sum result.

[0106] Step S34: Based on the network topology diagram and resource list, filter candidate hosts and allocate honeypot instances according to capacity constraints and resource health indicators;

[0107] Step S35: Based on the heat matrix of attack traffic and the network topology map, adjust the distribution of honeypot instances, increase honeypot instances in high attack areas, while maintaining equal quantity constraints across the entire domain, and adjust the instance configuration of other domains according to the security limit.

[0108] Specifically, for example: Suppose there are three subnets in the current network, namely subnet A, subnet B, and subnet C. Subnet A is the production subnet, subnet B is the office subnet, and subnet C is the DMZ zone. The system will collect the network topology, switch nodes, router nodes, host resources, and current threat status of each subnet (such as high-risk traffic in subnet A and abnormal traffic behavior in subnet C). It will select the honeypot instance profile that matches the target domain from the predefined service profile library. For example, the honeypot instance for the production subnet should have high interaction capabilities, while the honeypot instance for the office subnet may have a lighter interaction load. The system selects the honeypot profile that meets the requirements and avoids deploying similar instance profiles in the same domain, thereby enhancing the trustworthiness of the honeypot.

[0109] In the network topology diagram, subnet A has two host nodes, such as host 1 and host 2. The CPU utilization of host 1 is 85%, and the CPU utilization of host 2 is 40%. The system will prioritize host 2 to deploy honeypot instances, avoiding deploying honeypots to the resource-constrained host 1.

[0110] If it is detected that subnet A (production subnet) has been subjected to a large number of scanning attacks in the past 30 minutes, while subnet B (office subnet) has not had much attack activity, the honeypot deployment in subnet A will be increased to ensure that there are more honeypot instances in that area to attract attack traffic, while keeping the number of honeypot instances in subnet B unchanged or decreasing to optimize resource utilization.

[0111] If the heatmap of subnet A shows that it received 1,000 attack requests in the past hour and subnet B received 300, then the system will decide to increase the number of honeypot instances in subnet A to 10, while the number of honeypot instances in subnet B will remain unchanged at 5. The system will allocate honeypot instances between host node 1 and host node 2 based on the host's resource health and capacity constraints.

[0112] In this embodiment, step S3 further includes: injecting mutations during honeypot deployment and migration to simulate the behavior of real assets within the domain, so that the honeypot is consistent with the real assets within the domain. The behavior of the real assets within the domain includes the fingerprint, response pattern, and timing behavior of the honeypot instance.

[0113] Continuously monitor the health status and behavior patterns of honeypot instances, and calibrate honeypot fingerprints and behaviors in real time. If the actual fingerprints and behaviors of a honeypot deviate from the preset security policies, a calibration operation is performed to revert the honeypot fingerprints and behaviors to an acceptable security configuration.

[0114] Specifically, in order to ensure that honeypot instances cannot be located by attackers through simple feature identification, this invention injects mutations during the deployment and migration of honeypots to simulate the behavior of real assets in the domain. This includes making appropriate adjustments to the fingerprints, response patterns, and timing behaviors of honeypot instances to make them appear consistent with real assets in the domain, thereby preventing them from being identified as honeypots by attackers.

[0115] By making minor adjustments to the operating system fingerprint (such as the Server field in the HTTP response header) and server version information (such as the version number of the database or web server) of the honeypot, the banner of the honeypot does not appear abnormal. It simulates the normal traffic pattern of real assets in the domain and adds appropriate delays, retries, and error code frequency to avoid the behavior pattern of the honeypot being too rigid. For example, in a production network, server A uses nginx / 1.18.0 as a web server and often responds with a normal HTTP 200 status. Honeypot server B also uses nginx / 1.18.0, but its behavior is too mechanical. Attackers may discover that it is a honeypot through meticulous network monitoring. Therefore, this invention will inject mutations into honeypot B to randomly select a server response pattern similar to that of real server A, such as simulating a 200 status code and occasionally returning a 404 status code, or making minor changes to the Server field in the HTTP header information to make it look more like a real server.

[0116] Once the honeypoint is deployed and begins receiving traffic, the system will continuously monitor its health status (e.g., CPU and memory usage) and behavioral patterns (e.g., response speed and traffic characteristics). If the honeypoint's actual behavior or fingerprint deviates from the preset security policy, the system will automatically calibrate. Health status monitoring includes monitoring indicators such as the honeypoint's resource utilization, response time, and number of connections to ensure that the honeypoint is not overloaded or failing. If anomalies are detected, such as CPU resource overload or excessively long response times, the system will consider reallocating resources or migrating the honeypoint instance. During monitoring, the system analyzes the honeypoint's traffic and response data in real time and compares it with the preset normal business model. If the honeypoint's behavior is found to be inconsistent with expectations (e.g., honeypoint...), the system will take corrective action. If a honeypot frequently generates error responses or its communication pattern is too mechanical, the system will automatically adjust. Adjustments include, but are not limited to, reconfiguring the honeypot's behavior pattern or restoring it to an acceptable security configuration. For example, honeypot A was initially set to simulate normal web application behavior, including generating responses periodically and minor failures (such as occasionally returning a 404). However, after a period of time, attackers began to detect its behavior pattern and found that its error code return frequency was too high, leading them to suspect that it was a honeypot. This invention detects this deviation through real-time monitoring and automatically adjusts the response strategy of honeypot A, reducing the return frequency of 404 errors and introducing more diversity of normal responses, making its behavior closer to real business traffic.

[0117] During monitoring, if the health status of a honeypot is found to be below a preset threshold, or its behavior pattern deviates significantly from normal traffic, the system will automatically initiate an adjustment mechanism. When a deviation is detected, the system will restore the honeypot to the preset behavior specifications. For example, if a honeypot frequently returns error codes, the system may increase the response time of the honeypot instance to simulate more real network latency, or introduce a certain proportion of successful responses to restore the normal traffic behavior pattern. Taking the example of honeypot A's error rate exceeding the error threshold, honeypot A is deployed in subnet X. The normal behavior pattern of the honeypot requires it to return an HTTP 200 response within 30 seconds, with an error response rate not exceeding 5%. However, during monitoring, it was found that the error response rate of honeypot A rose to 15%. The system recorded this behavior and triggered a calibration mechanism to adjust the error response of honeypot A, reducing the frequency of error responses (e.g., setting a new ratio of successful responses to error responses of 90:10), and re-analyzing the behavior data of honeypot A to ensure that it returns to the normal response pattern.

[0118] In this embodiment, step S4 specifically includes:

[0119] Based on the context of the attack traffic and combined with the honeypot level metadata, the health and capacity of the honeypot instance are read, and the priority of each session is calculated. The priority is determined by the threat intensity factor, asset-related factor, and resource security factor.

[0120] Based on the hierarchical decreasing characteristics of the Maxwell-Boltzmann distribution, a target response probability is set for honeypots at different levels, and normalization is performed within each level according to the factor weights of the honeypot instances to obtain the target response probability for each honeypot instance.

[0121] Verify whether the request rate corresponding to the target response probability exceeds the capacity threshold of the honeypot instance. If it exceeds the capacity threshold, adjust the request rate and ensure that it complies with the isolation strategy and micro-segmentation rules. At the same time, introduce random jitter and smoothing to prevent attackers from detecting a fixed probability.

[0122] Traffic is randomized by generating deterministic pseudo-random seeds and directed to the target honeypot based on the execution probability.

[0123] The acceptance probability and interaction depth of an instance for a new connection are determined based on the target response probability. In risky scenarios, latency and error perturbation are added. For requests that are not accepted, a silent or general rejection is returned. If the target response probability of a honeypot instance is 0.56, but the instance cannot handle a request rate exceeding 0.4 due to network bandwidth limitations, the system will automatically adjust and reduce the target response probability of the instance.

[0124] Within the time window, probability changes are smoothed and jitter is injected to prevent long-term observations from fitting a fixed probability. For example, if the response probability of a certain honeypot is 0.56 within the time window, the system will smooth this probability to avoid large fluctuations in a short period of time. The smoothed response probability may become 0.58, and the system adds a small jitter (such as ±0.02) to keep its fluctuation range between 0.56 and 0.6.

[0125] Specifically, the threat intensity factor is obtained by calculating the degree of deviation from the historical baseline based on the statistical characteristics of network traffic; the asset-related factor is obtained by calculating the number of ports exposed by the asset; and the resource security factor is obtained by monitoring the network bandwidth usage in real time and taking the packet loss rate. After obtaining the threat intensity factor, asset-related factor, and resource security factor, they are normalized to their maximum and minimum values.

[0126] For example: When each attack traffic reaches the honeypot, the priority of each session is calculated. The priority is determined by the three factors mentioned above and is calculated by weighted average. The factor weights are set as follows: threat intensity factor weight is 0.4, asset-related factor weight is 0.3, and resource security factor weight is 0.3. Then the priority = (threat intensity factor * 0.4) + (asset-related factor * 0.3) + (resource security factor * 0.3). If the threat intensity factor of a certain traffic is 0.9 (very high), the asset-related factor is 0.6 (medium sensitivity), and the resource security factor is 0.8 (good health), then the priority of this traffic is calculated as: priority = (0.9 * 0.4) + (0.6 * 0.3) + (0.8 * 0.3) = 0.72.

[0127] Based on the priority of attack traffic and the level of honeypot instances, the system sets response probability targets for honeypots at different levels. The allocation of response probability targets follows a hierarchy-decreasing characteristic similar to a Maxwell-Boltzmann distribution: high-priority traffic (high threat intensity) is allocated to core honeypots, which have a higher response probability; low-priority traffic or high-latency requests are directed to peripheral honeypots, which have a lower response probability. According to the hierarchy-decreasing characteristic, the response probability of core honeypots is 0.8, that of intermediate honeypots is 0.5, and that of peripheral honeypots is 0.2. Traffic is allocated within this level and normalized according to the instance weight. For example, if there is a core honeypot instance with a weight of 0.7 based on its health status and attack priority, its response probability target is: Response Probability = Base Target Probability * Weight = 0.8 * 0.7 = 0.56. If there is a peripheral honeypot instance with a weight of 0.5 based on its health status and attack priority, its response probability target is: Response Probability = 0.2 * 0.5 = 0.1.

[0128] In this embodiment, step S5 specifically includes:

[0129] Step S51: Receive raw interaction data from the honeypot and network boundary devices (such as firewalls, IDS / IPS). The raw interaction data includes connection metadata, application logs, command traces, file forensics, kernel audit events, and traffic slices. The connection metadata includes, but is not limited to, source IP, destination IP, source port, destination port, and protocol type. The application logs include, but are not limited to, protocol data such as HTTP requests and DNS queries. The command traces include input commands and control instructions. The file forensics includes, but is not limited to, downloaded files and executed scripts. The kernel audit events include, but are not limited to, system calls and permission changes.

[0130] Step S52: Assign a global event ID to each interaction event and unify the time baseline alignment to facilitate subsequent tracking and correlation. All events are aligned to a unified time baseline, including time zone and clock drift correction.

[0131] Step S53: For each interaction event, cluster the interaction facts according to the session key (such as the five-tuple: source IP, source port, destination IP, destination port, protocol) and connection direction, sort them by time within the session, and sort the commands, file operations and error events to form an action sequence. If there is a close temporal dependency between multiple sessions (such as the source IP accessing multiple honey spots in a short period of time), establish a suspicious dependency edge across sessions and generate an interaction graph.

[0132] Step S54: Based on the location of honeypot instances and defense boundaries (such as ACL rules, policy restrictions, etc.), the threat judgment area is divided into a honeycomb shape using reachable path cost. Reachable path cost is used to measure the network cost from a certain observation point to a honeypot, taking into account factors such as network topology, routing hop count, bandwidth, and latency. This division method is more suitable for complex networks and multi-domain environments than the traditional geometric distance division. For example: If there are two honeypots M1 and M2, which are located in different subnets, and the path cost from an attack source to M1 is 10, while the path cost to M2 is 15, then the system will assign the attack source to the nearest honeypot M1.

[0133] Step S55: Calculate the honeypot ID of each interaction event, select the honeypot with the lowest path cost and the policy allowance as the honeypot. If there are multiple candidate honeypots, use the secondary criterion disambiguation point. If the seed of traffic sampling is consistent with the honeypot, select the honeypot and output the attribution result object, including indicating which honeypot the interaction event belongs to, and marking the confidence and evidence summary, such as path cost, latency, etc.

[0134] Step S56: Combining the semantics of the MITREATT&CK framework with the context of the decoy script, the attributed interaction events are reconstructed into a phased attack chain. Constraints are established according to the attack stage dependency table, dividing the attack chain into multiple stages, such as: initial access → execution → persistence → privilege escalation → defense and evasion → credential access → lateral movement → collection → command and control → transmission. Topological sorting is then performed based on the strength of evidence and chronological order. For example, in the MITREATT&CK framework, an attacker exploits a vulnerability for initial access, then enters the system via RDP and executes malicious code. Next, they lateral move to other servers. The system will sequentially link these events to form an attack chain. If the attacker frequently sends requests to the honeypot, the system detects this pattern and automatically redirects traffic to shadow honeypots. These honeypots simulate normal behavior, attracting the attacker to further probe and delaying the attacker's identification of the system.

[0135] Example 2

[0136] The difference from Example 1 is that, as in Example 2, ... Figure 2 As shown, the present invention also provides an adaptive network deception system based on dynamic honeypots, used to implement an adaptive network deception method based on dynamic honeypots, including:

[0137] The perception and tagging unit 10 is used to receive raw traffic data, complete protocol identification, threat feature analysis and fingerprint extraction, and perform multi-path splitting according to target address, port and session 5-tuple, and perform attack behavior feature matching and attack mode tag generation operations for each traffic path.

[0138] The dynamic decoy orchestration unit 20 is used to generate a honeypot deployment structure and distribute it to the virtualization environment for execution based on the attack mode label (provided by the perception and labeling unit 10) and the current network topology. It combines real-time threat intelligence to calculate probabilistic decoy strategies (such as higher interaction probability for core ring honeypots and reduced response probability for peripheral honeypots, fitting a Maxwell-Boltzmann distribution), and produces a traffic redirection rule and response strategy table.

[0139] The interactive judgment and handling unit 30 aggregates session records, command trajectories, and file forensics generated by honeypot interactions. Based on the honeypot deployment structure and deception strategy (provided by the dynamic deception orchestration unit 20), it applies honeycomb geometry-like judgment (constructing a judgment area with the defense boundary of adjacent honeypots as the vertical line) to complete the attribution of the honeypot and the stage location, and reconstructs the attack chain (timeline / node sequence / technical means) accordingly. It then performs handling actions on production network resources (isolation, blocking, access degradation, deception escalation) and generates security event logs and indicator evaluations (capture rate, false positive rate, resource consumption).

[0140] The present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described adaptive network deception method and steps. The present invention also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program is executed by the processor to implement the above-described adaptive network deception method.

[0141] In summary, this invention overcomes the shortcomings of existing technologies in terms of real-time performance, accuracy, adaptability, and closed-loop optimization of network deception by using parallel traffic decomposition and attack pattern label matching, cross-domain layered dynamic honeypot optimization, deception strategy allocation, and geometric decision closed loop. It also improves attack capture efficiency, threat tracing accuracy, and the persistence and adaptability of the defense system, realizing a shift from passive defense to active deception and intelligent optimization.

[0142] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An adaptive network deception method based on dynamic honeypots, characterized in that, Specifically, the following steps are included: Step S1: Receive raw traffic data from the network ingress and monitoring nodes, perform protocol identification and threat feature analysis on the raw traffic data, and split the raw traffic data according to the target address, port and session characteristics to obtain multi-channel traffic data; Step S2: Perform threat feature matching on the multi-path traffic data after splitting, compare the traffic data of different attack types with the corresponding attack type model, and transform the unclassified attack traffic into specific threat data with attack pattern labels. Step S3: Based on the attack mode label and the current network topology, generate an optimized honeypot deployment structure, distribute the honeypot nodes in multiple different security domains or virtualization environments, deploy an equal number of honeypot instances with different service profiles in each domain, and make the deployment location of the honeypot nodes dynamically change through dynamic migration and address switching mechanisms. Step S4: While keeping the geometric topology of the honeypot unchanged, adjust the response probability of the honeypot based on real-time threat intelligence so that the response probability of honeypots at different levels conforms to the hierarchical decreasing characteristics of a Maxwell-Boltzmann distribution. Then, use policy mapping rules to guide attack traffic to the corresponding honeypot to achieve the deceptive effect of probability shaping. Step S5: After receiving the interaction data from the honeypot, determine the attacker's true intention and location based on the honeypot deployment structure and deception strategy. Use a honeycomb-shaped threat judgment area to determine the honeypot to which the attack belongs, restore the attack chain, isolate and protect the real network resources, map the interaction data back to the original threat feature format, and generate a security event log. Step S4, while maintaining the honeypot's geometric topology, adjusts the honeypot response probability based on real-time threat intelligence, specifically including: Based on the context of the attack traffic and combined with the honeypot level metadata, the health and capacity reserves of the honeypot instance are read, and the priority of each session is calculated. The priority is determined by the threat intensity factor, asset-related factor, and resource security factor. Based on the hierarchical decreasing characteristic of the Maxwell-Boltzmann distribution, a target response probability is set for honeypots at different levels, and normalization is performed within each level according to the factor weights of the honeypot instances to obtain the target response probability for each honeypot instance.

2. The adaptive network deception method based on dynamic honeypots according to claim 1, characterized in that, Step S1 specifically includes: Step S11: Receive raw traffic data from the network ingress and monitoring nodes; Step S12: The raw traffic data is split according to the destination address, port and session characteristics; Step S13: Maintain the protocol label stack in each session, adjust the labels according to the arrival of subsequent messages, and record the confidence score and evidence fragment index. Step S14: Parallel execution of protocol identification and threat feature analysis, generating threat clue objects based on rule matching and anomaly scoring, and allocating traffic to multiple processing channels through session stickiness and target relevance.

3. The adaptive network deception method based on dynamic honeypots according to claim 1, characterized in that, Step S2 specifically includes: Step S21: Generate a multi-granularity feature vector for each session, wherein the multi-granularity feature vector includes stream-level statistics, session semantics, sequence features, and intelligence and asset context; Step S22: Based on the protocol tag stack, asset type and intelligence signal, select a set of candidate models that are compatible with the protocol and attack type from the registry, and adjust the priority of the candidate models according to the importance of the business and the recent alarm density. Step S23: Perform rule matching on each session feature, execute multi-segment site matching, keyword adjacency constraint and state machine tracking, and use fingerprint matching and rule graph matching to perform in-depth analysis of binary load, and output rule hit results; Step S24: Score statistical and short sequence features using a lightweight model, then perform time-series inference on the scoring results using a deep model, and perform similarity retrieval based on a known attack family embedding library; Step S25: Merge the rule hit results with the deep model's scoring results to form the final label. Generate labels according to the hierarchical threshold strategy, and record the confidence level, evidence citation, and explanatory summary to form the attack label object.

4. The adaptive network deception method based on dynamic honeypots according to claim 1, characterized in that, Step S3 specifically includes: Step S31: Based on the current network topology and threat situation information, collect information on subnets, switching nodes, routing nodes, computing hosts, policy domains, resource usage, and threat tags, and generate a scenario snapshot; Step S32: Based on the collected scene snapshots, generate an optimized honeypot deployment structure, and make the honeypot locations dynamically change through dynamic migration and address switching mechanisms; Step S33: Select a honeypot instance profile that matches the target domain from the predefined service profile library; Step S34: Based on the network topology diagram and resource list, filter candidate hosts and allocate honeypot instances according to capacity constraints and resource health indicators; Step S35: Based on the attack traffic heat map and network topology, adjust the distribution of honeypot instances, increase honeypot instances in high-attack areas, maintain equal quantity constraints across all domains, and adjust the instance configuration of other domains according to the security limit.

5. The adaptive network deception method based on dynamic honeypots according to claim 4, characterized in that, Step S3 further includes: During honeypot deployment and migration, mutations are injected to simulate the behavior of real assets within the domain, ensuring that the honeypots are consistent with the real assets within the domain. The behavior of the real assets within the domain includes the fingerprint, response pattern, and timing behavior of the honeypot instance. Continuously monitor the health status and behavior patterns of honeypot instances, and calibrate honeypot fingerprints and behaviors in real time. If the actual fingerprints and behaviors of a honeypot deviate from the preset security policies, a calibration operation is performed to revert the honeypot fingerprints and behaviors to an acceptable security configuration.

6. The adaptive network deception method based on dynamic honeypots according to claim 1, characterized in that, Step S4 uses policy mapping rules to direct attack traffic to the corresponding honeypot, specifically including: Verify whether the request rate corresponding to the target response probability exceeds the capacity threshold of the honeypot instance. If it exceeds the capacity threshold, adjust the request rate and ensure that it complies with the isolation strategy and micro-segmentation rules. At the same time, introduce random jitter and smoothing to prevent attackers from detecting a fixed probability. Traffic is randomized by generating deterministic pseudo-random seeds and directed to the target honeypot based on the execution probability. The acceptance probability and interaction depth of the instance for new connections are determined based on the target response probability. In risky scenarios, latency and error perturbation are added. For requests that are not accepted, a silent response or a general rejection is returned. Within the time window, probability changes are smoothly controlled, and jitter is injected to prevent long-term observations from fitting a fixed probability.

7. The adaptive network deception method based on dynamic honeypots according to claim 1, characterized in that, Step S5 specifically includes: Step S51: Receive raw interactive data from the honeypot and network boundary devices; Step S52: Assign a global event ID to each interaction event and align the time baselines. Step S53: For each interaction event, cluster the interaction facts according to the session key and connection direction, sort them by time within the session, sort the commands, file operations and error events to form an action sequence, establish suspicious dependency edges across sessions, and generate an interaction graph. Step S54: Based on the location of honeycomb instances and defense boundaries, divide the threat judgment area into honeycomb-shaped regions using reachable path costs; Step S55: Calculate the honeypot ID of each interaction event, select the honeypot with the lowest path cost and the policy allowed as the honeypot, output the attribution result object, and mark the confidence level and evidence summary. Step S56: Combining the semantics of the MITREATT&CK framework with the context of the decoy script, the attributed interactive events are reconstructed into a phased attack chain. Constraints are established before and after the attack stage dependency table, and topological sorting is performed according to the strength of evidence and time order.

8. The adaptive network deception method based on dynamic honeypots according to claim 7, characterized in that, The raw interaction data in step S51 includes connection metadata, application logs, command traces, file forensics, kernel audit events, and traffic slices.

9. An adaptive network deception system based on dynamic honeypots, used to implement the adaptive network deception method based on dynamic honeypots as described in any one of claims 1-8, characterized in that, include: The perception and tagging unit is used to receive raw traffic data, complete protocol identification, threat feature analysis and fingerprint extraction, and perform multi-path splitting according to target address, port and session 5-tuple, and perform attack behavior feature matching and attack pattern tag generation operations for each traffic path. The dynamic deception orchestration unit is used to generate honeypot deployment structures based on attack mode tags and the current network topology, and then distribute them to the virtualization environment for execution. It combines real-time threat intelligence to calculate probabilistic deception strategies and generate traffic redirection rules and response strategy tables. The interactive decision and handling unit is used to apply honeycomb geometry-like decision-making to determine the attribution of the honeycomb and the stage of the attack path based on the honeycomb deployment structure and deception strategy, and to reconstruct the attack chain accordingly. It then performs handling actions on production network resources and generates security event logs and indicator assessments.

Images