A general network service simulation honeypot construction method based on a large language model
By constructing network service simulation honeypots based on a large language model, the problems of high resource consumption and low automation of the rule base in the existing system are solved, and effective response to malformed messages and unknown protocols is achieved, thereby enhancing the adaptability and responsiveness of the defense system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGZHOU UNIVERSITY
- Filing Date
- 2026-04-30
- Publication Date
- 2026-06-05
Smart Images
Figure CN122160182A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network security technology, and in particular to a method for constructing honeypots for general network service simulation based on a large language model. Background Technology
[0002] With the rapid development of network information technology, cybersecurity threats are becoming increasingly severe, and the technical confrontation between attackers and defenders is constantly escalating. The proliferation of advanced persistent threats (APS), zero-day exploits, and automated attack tools makes traditional passive defense methods based on feature matching (such as firewalls and intrusion detection systems) ineffective in dealing with unknown attack behaviors. Against this backdrop, proactive deception defense technology has become a research hotspot in the field of cybersecurity. Its core idea is to actively lure attackers into a controllable trap by constructing a simulation environment highly similar to real business systems, thereby shifting the attack target, recording attack behavior, and consuming attack resources. Honeypots, as a typical representative of deception defense, have evolved into various implementation forms, including low-interaction and high-interaction models. With the development of container technology and artificial intelligence, honeydove technology, which combines lightweight deployment with highly realistic interactive capabilities, has emerged. Meanwhile, deep learning technology, represented by large language models, has shown broad application prospects in the field of cybersecurity. Its powerful content generation and semantic understanding capabilities provide a new technical path for building intelligent and dynamic service simulation deception systems.
[0003] However, existing network service simulation deception defense systems still have the following shortcomings: (1) Low-interaction honeypots based on rule matching have limited response content and limited ability to respond to complex probe requests; while high-interaction honeypots based on real services require the deployment of a complete operating system environment, which consumes a lot of resources and poses a security risk that the real service program can be used by attackers to break through the isolation. (2) The construction of the rule base depends on security personnel manually analyzing traffic, writing regular expressions and state transition logic, which has a long update cycle and is difficult to adapt to rapidly changing attack methods. (3) Existing simulation systems that introduce large language models mostly adopt word-level models. The processing of binary protocols requires a front-end protocol parser to convert the raw byte stream into text; when attackers send malformed messages or use unknown private protocols, the protocol parser often fails to parse them, causing the system to be unable to return a response or directly disconnect. (4) In resource-constrained deployment environments, defenders can usually only pre-configure a limited number of service instances, which is difficult to cover the diverse service types in the intranet. Attackers may hide themselves when they do not find any usable services, thereby reducing the probability of being captured by the defender. Therefore, it is urgent to develop a solution to solve the above problems. Summary of the Invention
[0004] The purpose of this invention is to provide a general network service simulation honeypot construction method based on a large language model, which improves the problems of the contradiction between resource consumption and deception capability, low degree of automation in rule base construction, and inability to effectively respond to malformed packets or unknown binary protocols in existing network service simulation deception defense systems.
[0005] The present invention provides a method for constructing honeypots for simulating general network services based on a large language model, which adopts the following technical solution:
[0006] A general method for constructing simulated honeypots for network services based on a large language model, specifically including:
[0007] Obtain network interaction traffic, and construct a structured matching rule base and fine-tune a byte-level large language model respectively;
[0008] Upon receiving a network request, the system identifies the application layer protocol type based on the target port number of the network request, decrypts the encryption protocol to obtain the plaintext request, extracts a session token from the plaintext request, manages the session interaction history, calculates the hash value of the original binary block of the plaintext request, and compares it with the cache database; if a matching record exists, the system directly reads the response message.
[0009] If no matching record exists, the application layer payload of the plaintext request is parsed. If parsing fails, the original binary block of the current request is concatenated with the historical interaction binary block of the session in chronological order to construct the first input prompt word. A response message is generated based on the fine-tuned byte-level large language model. If parsing succeeds, the parsed formatted data is matched with the structured matching rule base. If a match is found, a response message is synthesized according to the rules. If no match is found, a second input prompt word is constructed, and a response message is generated based on the sub-word-level large language model.
[0010] If the original request is an encrypted protocol, the response message is encrypted and returned to the attacker; otherwise, it is returned directly. The plaintext request and the corresponding response message are stored as a traffic pair in the cache database and the session database.
[0011] The beneficial effect of the general network service simulation honeypot construction method based on a large language model provided by this invention is that it generates a structured matching rule base using unified network interaction traffic and efficiently fine-tunes the parameters of the byte-level large language model. After receiving an attacker's request, it first performs cache matching. If a match is found, the response message is read directly. If no match is found, protocol parsing is performed. If the parsing is successful, the formatted data is matched with the rule base and a response is synthesized according to the rules or a sub-word-level language model is called to generate a response. If the parsing fails, the original binary block is concatenated with the session history and the fine-tuned byte-level large language model is called to generate a binary response. This effectively improves the technical problems of existing service simulation systems, such as the contradiction between resource consumption and deception capability, low automation of rule base construction, and inability to generate effective responses to malformed messages or unknown binary protocols.
[0012] Optionally, when acquiring network interaction traffic, the following are included:
[0013] For application layer protocols that have publicly available traffic datasets, obtain the open-source traffic dataset;
[0014] For application layer protocols that do not have publicly available traffic datasets, a traffic dataset is synthesized independently. The independent synthesis process includes: deploying the application layer protocol server in an isolated environment and disabling the encrypted transmission mechanism of the server; using automated operation tools to send normal business operation request messages and abnormal operation request messages to the server; during the sending of request messages, capturing messages on the communication port of the server through a bypass listening program, generating and saving them as a data packet capture file; and obtaining the independently generated traffic dataset based on the data packet capture file.
[0015] Optionally, when building a structured matching rule base, the following are included:
[0016] The network interaction traffic is preprocessed to obtain preprocessed network interaction traffic; the preprocessed network interaction traffic is grouped according to the application layer protocol type; for the request payload data in each group, a feature vector is calculated based on the term frequency-inverse document frequency algorithm; and the feature vector is clustered based on the density-based spatial clustering algorithm.
[0017] The request-response pairs from the clustering results are input into a pre-trained large language model, which outputs structured matching rules in YAML format based on preset prompt word templates. Each rule contains metadata, matching conditions, and a response template.
[0018] Conflict detection is performed on the structured matching rules. When different structured matching rules are detected to match the same request message, their priority parameters or matching condition expressions are adjusted. The coverage and semantic accuracy of the structured matching rules are statistically analyzed using verification traffic data. Structured matching rules whose coverage and semantic accuracy are both higher than a preset threshold are retained to obtain a structured matching rule library.
[0019] Optionally, when fine-tuning a byte-level large language model, the following may be included:
[0020] The application layer payload is extracted from the network interaction traffic, and session reassembly, denoising and truncation are performed to obtain a cleaned payload byte stream.
[0021] The requests and corresponding responses in the cleaned payload byte stream are saved as binary byte sequences, special control flags are injected and concatenated in time to construct a fine-tuning data template. The fine-tuning data template includes a request start flag, a request byte sequence, a request end flag, a response start flag, a response byte sequence, and a response end flag. For stateful application layer protocols, a sliding window mechanism is used to concatenate the history of multiple rounds of interaction in the same session as a context prefix before the current request.
[0022] The fine-tuning data template is used as a training sample to input into a byte-level large language model, and fine-tuning is performed based on low-rank adaptation technology; during fine-tuning, a masked causal language modeling strategy is adopted, and the prediction loss is calculated only for the response byte sequence portion;
[0023] After fine-tuning, the low-rank matrix parameters obtained from training are merged into the original weights of the byte-level large language model, and cross-validation is performed using test traffic data that was not involved in fine-tuning, retaining the model that meets the preset performance indicators.
[0024] Optionally, when extracting a session token from the plaintext request and managing the session interaction history, the process includes:
[0025] For application layer protocols that support session state, extract the session tag from the application layer message and compare it with the existing session tag. If the same session tag exists, the current request is added to the corresponding session interaction history; otherwise, a new session record is created.
[0026] For application layer protocols or unknown protocols that do not support session state, the attacker's IP address is used as the session identifier, and requests with the same IP address are grouped into the same session interaction history.
[0027] Optionally, when generating a response message based on the fine-tuned byte-level large language model, the following steps are included:
[0028] The first input prompt is input into the fine-tuned byte-level large language model, and a binary response stream is generated autoregressively after the preset response start marker, which serves as the response message; the first input prompt includes a history session start marker, a history request-response pair, a separator marker, a history session end marker, a request start marker, a request byte sequence, and a request end marker.
[0029] Optionally, if parsing is successful, the parsed formatted data is matched against the structured matching rule base. If a match is found, the response message is synthesized according to the rules, including:
[0030] The parsed formatted data is matched with rules of the same application layer protocol type in the structured matching rule base, and all matching rules are recorded.
[0031] If at least one rule is matched, the rule with the highest priority is selected; based on the response template of the selected rule, the content required for the response message is obtained; if the response template contains placeholders, the corresponding information is extracted from the plaintext request according to the semantics of the placeholders and replaced; the protocol parser is called to construct the response message based on the content in the response template.
[0032] Optionally, if no match is found, a second input prompt word is constructed, which, when generating the response message based on the sub-word-level large language model, includes:
[0033] The second input prompt includes system instructions, protocol knowledge and RAG examples, virtual system status, relevant historical interaction records, current structured request, and output constraints; wherein, the system instructions include the network protocol type and output format constraints of the current simulation, and the protocol knowledge and RAG examples include example request-response pairs recalled by the vector database based on the semantic similarity of the current request;
[0034] The second input prompt word is input into the sub-word level large language model to generate a structured response text that conforms to the output constraints; the structured response text is serialized into a binary response message according to the application layer protocol type.
[0035] Optionally, the methods for obtaining the relevant historical interaction records and virtual system status in the second input prompt include:
[0036] Obtain the historical interaction records of the current session and calculate their total length; if the total length does not exceed the preset threshold, directly fill the historical interaction records as the relevant historical interaction records into the second input prompt words, and set the virtual system status to empty;
[0037] If the total length exceeds the preset threshold, the historical interaction records will be divided into preset segments in chronological order. The sub-word level large language model will be called sequentially to filter the relevance of each segment, extract the interaction pairs that have logical dependence, state dependence or contextual association with the current request, and merge them in chronological order to obtain the relevant historical interaction records.
[0038] If the total length of the merged related historical interaction records still exceeds the preset threshold, the related historical interaction records are again divided into a preset number of segments in chronological order. Starting from the current virtual system state, the sub-word level large language model is called segment by segment. The virtual system state generated in the previous round is combined with the current historical segment as input to generate the virtual system state after the interaction of the segment. The generated virtual system state is used as the input for the next round of iteration to finally obtain the compressed virtual system state. The related historical interaction records are cleared or only the latest round of interaction pairs are retained. The compressed virtual system state is then filled into the second input prompt word.
[0039] Optionally, the following deployment steps may also be included:
[0040] The structured matching rule base, the fine-tuned byte-level large language model, and the program code required to run the method are packaged and built into a container image; the container image is then instantiated as a simulated honeypot by assigning a specified network address and listening port to it. Attached Figure Description
[0041] Figure 1 A flowchart illustrating a method for constructing honeypots for general network service simulation based on a large language model, provided in an embodiment of the present invention. Detailed Implementation
[0042] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art. The terms "comprising" and similar expressions used herein mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but does not exclude other elements or objects.
[0043] See Figure 1 This invention provides a security analysis method based on distributed data sandboxes and large models, comprising the following steps:
[0044] S1. Obtain network interaction traffic, and construct a structured matching rule base and fine-tune the byte-level large language model respectively;
[0045] S2. Receive network requests, identify the application layer protocol type based on the target port number of the network request, decrypt the encryption protocol to obtain the plaintext request; extract the session token from the plaintext request and manage the session interaction history; calculate the hash value of the original binary block of the plaintext request and compare it with the cache database; if a matching record exists, directly read the response message.
[0046] S3. If no matching record exists, the application layer payload of the plaintext request is parsed according to the protocol. If the parsing fails, the original binary block of the current request is concatenated with the historical interaction binary block of the session in chronological order to construct the first input prompt word. The response message is generated based on the fine-tuned byte-level large language model. If the parsing is successful, the formatted data obtained by parsing is matched with the structured matching rule base. If a match is found, the response message is synthesized according to the rules. If no match is found, the second input prompt word is constructed, and the response message is generated based on the sub-word-level large language model.
[0047] S4. If the original request is an encrypted protocol, the response message is encrypted and returned to the attacker; otherwise, it is returned directly. The plaintext request and the corresponding response message are stored as a traffic pair in the cache database and the session database.
[0048] In some embodiments, different traffic acquisition methods are used depending on the type of application layer protocol being simulated when acquiring network interaction traffic in step S1. For application layer protocols with publicly available traffic datasets, open-source traffic datasets are acquired. For example, the HTTP protocol, as the most widely used network protocol, has a large number of available open-source traffic datasets, including public data released by the Archive organization and the MACCDC dataset. Similarly, the SSH protocol has rich open-source terminal interaction log resources; for example, the SSH_Honeypot_Dataset contains complete interaction records between attackers and SSH honeypots. For application layer protocols without publicly available traffic datasets, traffic datasets are generated by self-synthesis. This invention selects the MySQL protocol as an example for illustration. The self-synthesis process is as follows:
[0049] S101. Build a MySQL database server within a sandbox or isolated virtual machine or container, and forcibly disable encrypted communication. For example, set `require_secure_transport=OFF` and leave `tls_version` empty, causing the handshake, authentication, and subsequent interactions between the client and server to degrade to plaintext transmission. Simultaneously, import structured benchmark test data into the server to ensure that the subsequently generated server response result set possesses realistic business characteristics.
[0050] S102. Use automated tools to trigger bidirectional traffic: On the one hand, use automated load testing tools (such as Sysbench) to initiate standard service requests that conform to protocol specifications (such as regular SELECT, INSERT, UPDATE read and write operations) to generate a large number of normal request and response messages; on the other hand, use penetration testing tools (such as Hydra, SQLMap) and network packet construction tools (such as Scapy) to actively inject abnormal data packets with authentication errors, malformed SQL statements, unauthorized access, and incorrect length or sequence number into the server to capture the server's real error responses and underlying state machine disconnection behavior;
[0051] S103. During the traffic generation process described above, deploy a bypass listening program (such as tcpdump), configure BPF (Berkeley Packet Filter) filtering rules to precisely target the standard or custom port of the database service (such as MySQL's port 3306), and disable packet cutoff limits (such as setting the parameter -s 0) to ensure complete capture of all underlying TCP byte streams interacting between the client and the server. Save the captured data stream in real time as a PCAP (Packet Capture) format file as the original network interaction traffic.
[0052] Through the above methods, the system obtains a diverse raw traffic dataset covering normal business and anomaly detection, which can be used for subsequent rule construction and model fine-tuning.
[0053] In some embodiments, when constructing the structured matching rule base in step S1, the network interaction traffic is preprocessed to obtain preprocessed network interaction traffic; the preprocessed network interaction traffic is grouped based on the application layer protocol type, and for the request payload data in each group, feature vectors are calculated based on the word frequency-inverse document frequency algorithm, and the feature vectors are clustered based on the density-based spatial clustering algorithm; the request-response pairs in the clustering results are input into a pre-trained large language model, and structured matching rules in YAML format are output based on preset prompt word templates. Each rule contains metadata, matching conditions, and response templates. The pre-trained large language model called in this invention is a large language model API provided by a third party, such as the GPT-5.4 model API provided by OpenAI, or the Gemini model API provided by Google; conflict detection is performed on the structured matching rules. When different structured matching rules are detected to match the same request message, their priority parameters or matching condition expressions are adjusted, and the coverage and semantic accuracy of the structured matching rules are statistically analyzed using verification traffic data. Structured matching rules with coverage and semantic accuracy both higher than preset thresholds are retained to obtain the structured matching rule base. This step automates the construction of a deployable YAML rule base from raw network traffic, eliminating the need for manual writing of regular expressions or state transition code. The specific process is as follows:
[0054] S111. Clean and standardize the acquired network traffic. First, use network traffic analysis tools (such as the command-line version of Wireshark, TShark, Zeek, etc.) or dedicated application layer protocol parsing scripts to read the PCAP traffic files collected and persistently stored in the previous stage. During the parsing process, the system automatically removes useless headers from the underlying TCP / IP layer (such as Ethernet frame headers, IP headers, TCP headers, etc.), extracting only the application layer payload. Then, based on the application layer protocol type (HTTP, MySQL, SSH, etc.), the requests and responses in each session are converted into unified JSON objects, each representing a complete request-response pair. Specifically, for the HTTP protocol, the JSON object must at least contain the request method, request path, request headers, request body, and response status code, response headers, and response body; for the MySQL protocol, the JSON object must at least contain the command type, SQL text, and response data; for the SSH protocol, the JSON object must at least contain the interactive command text and command output. Finally, hash the generated JSON objects to remove duplicate records.
[0055] S112. First, coarse-grained grouping is performed based on high-level features of application layer protocol types. Specifically, for the HTTP protocol, grouping is based on protocol type, request method, and static prefixes of the URL path; for the MySQL protocol, grouping is based on protocol type and command type (e.g., COM_QUERY); and for the SSH protocol, grouping is based on basic command keywords. For the request payload text within each group, the Term Frequency-Inverse Document Frequency (TF-IDF) algorithm is used to convert the text into a high-dimensional feature vector to highlight static patterns in the text and weaken the weight of dynamic parameters. Then, a density-based spatial clustering algorithm (DBSCAN) is used to cluster the feature vectors. Without pre-specifying the number of clusters, data with similar request patterns are automatically grouped into the same cluster, and irregular noise traffic (such as abnormal attack packets) is isolated. After clustering, each cluster contains multiple highly similar request-response pairs;
[0056] S113. Using the request-response pairs in each cluster as input, construct a prompt word template and output structured rules conforming to YAML format based on the prompt word template. Specifically, the prompt word template content includes: "Currently, we are providing JSON data of multiple network requests and their corresponding responses belonging to the same business logic. Please analyze the common characteristics of these requests, extract the static parts of the request content, and represent the dynamically changing parts (such as IDs and hash values) using named capture groups of regular expressions. At the same time, find the fixed template in the response message and accurately map the variables captured in the request to the placeholders in the response body."
[0057] Specifically, the structured rules based on YAML format comprise three aspects: metadata, matching conditions, and response templates. Metadata includes rule ID, protocol type, priority, etc. Matching conditions are feature matching fields designed according to different network protocols; this part is usually represented by regular expressions to depict content patterns. The response template describes the content of the response message. While the metadata content is the same, the matching conditions and response template need to be designed according to the specific network protocol. This invention will use HTTP, SSH, and MySQL protocols as examples. Details are as follows:
[0058] The matching criteria for the HTTP protocol include the request method, request path, request parameters, request headers, and request body content. The response template consists of three fields: the response status code, the response headers, and the response body. The response body contains not only fixed characters but also placeholders. Placeholders represent response time, user ID, or session tokens, etc., which need to be dynamically populated based on the context. This content can be extracted from the network request itself or randomly generated by the system. Table 1 details the field structure and technical meaning of the YAML format rules under the HTTP protocol.
[0059] Table 1. Description of Configuration Fields for Request Matching and Response Rules under HTTP Protocol
[0060]
[0061] The matching criteria for the SSH protocol include the command pattern. The response template includes the response type and response data. Table 2 details the field structure and technical meaning of the YAML format rules under the SSH protocol.
[0062] Table 2. Description of Request Matching and Response Rule Configuration Fields under SSH Protocol
[0063]
[0064] The matching criteria for the MySQL protocol include the command type and the character pattern of the payload. The response template includes the response action and the response data. Table 3 details the field structure and technical meaning of the YAML format rules under the MySQL protocol.
[0065] Table 3. Description of SSH Protocol Request Matching and Response Rule Configuration Fields
[0066]
[0067] S114. Load the initially generated YAML-formatted rule set into the offline testing engine and perform replay testing using training set traffic. If multiple rules are found to match the same request message, indicating rule overlap, eliminate the conflict by adjusting the rule priority field or guiding the large language model to tighten the regular expression (e.g., replacing .* with a specific character set [a-zA-Z0-9]+). Then, use reserved test set traffic to evaluate the coverage (the proportion of successfully matching similar traffic) and semantic accuracy (the semantic consistency between the response content and the actual response) of each rule. Discard rules with low coverage or accuracy below a preset threshold, and retain rules that meet the quality requirements to form the final structured matching rule library.
[0068] In some embodiments, during the fine-tuning of the byte-level large language model in step S1, application layer payloads are extracted from network interaction traffic, and session reassembly, denoising, and truncation are performed to obtain a cleaned payload byte stream. The requests and corresponding responses in the cleaned payload byte stream are saved as binary byte sequences, special control flags are injected, and the sequences are concatenated in time to construct a fine-tuning data template. The fine-tuning data template includes a request start flag, a request byte sequence, a request end flag, a response start flag, a response byte sequence, and a response end flag. For stateful application layer protocols, a sliding window mechanism is used to concatenate the history of multiple rounds of interaction within the same session as a context prefix before the current request. The fine-tuning data template is used as a training sample input to the byte-level large language model, and fine-tuning is performed based on low-rank adaptation techniques. During fine-tuning, a masked causal language modeling strategy is used, calculating only the prediction loss of the response byte sequence portion. After fine-tuning, the low-rank matrix parameters obtained from the training are merged into the original weights of the byte-level large language model, and cross-validation is performed using test traffic data that did not participate in the fine-tuning, retaining models that meet preset performance indicators. Through this fine-tuning process, the byte-level large language model gained the ability to directly read, understand, and deduce binary network traffic at the underlying protocol level, and is particularly adept at handling malformed packets and unknown proprietary binary protocols. The specific process is as follows:
[0069] S121. Extract the TCP / UDP application layer payload from the original network interaction traffic. Use a network underlying processing library (such as Scapy or dpkt) to reassemble the session according to the five-tuple information to solve the fragmentation and packet reassembly problems. Strip all network layer and transport layer headers, retaining only the application layer payload. Produce an acknowledgment message with an empty payload (zero length), and use information entropy filtering and truncation strategies to remove large segments of meaningless duplicate data. For single messages exceeding a preset context length threshold (e.g., 16384 bytes), truncate them, retaining the handshake, authentication, and core control command parts, to obtain the cleaned payload byte stream.
[0070] S122. Convert the cleaned request byte stream and corresponding response byte stream into pure binary block representations and inject custom special control flags. For a single request-response pair, construct a fine-tuning data template: <|request_start|>[byte stream sequence of client request]<|request_end|><|response_start|>[byte stream sequence of server response]<|response_end|>. Where <|request_start|> represents the request start flag, <|request_end|> represents the request end flag, <|response_start|> represents the response start flag, and <|response_end|> represents the response end flag. For binary protocols with strong state dependencies (such as the handshake authentication phase of MySQL or the key exchange phase of SSH), a sliding window mechanism is used. The previous N rounds of interaction history in the same session are appended as a context prefix before the current request to construct a fine-tuned data template for the interaction history: <|history_start|>[request-response pair 1]<|comma|>[request-response pair 2]<|comma|>…[request-response pair n]<|history_end|><|request_start|>[byte stream sequence of client request]<|request_end|><|response_start|>[byte stream sequence of server response]<|response_end|>. Here, <|history_start|> represents the start marker of the historical session, <|comma|> represents the separator marker, and <|history_end|> represents the end marker of the historical session.
[0071] S123. Select an open-source, byte-level large language model (such as bGPT) as the base model. Freeze all the original weight parameters of this model and fine-tune only the linear projection layer. Specifically, inject a low-rank matrix A and an increased-dimensional matrix B into the bypass of this linear projection layer. For the input... Its forward propagation process is as follows ,in, For the frozen pre-trained weights, the matrix The dimension is ,matrix The dimension is (rank Set appropriate low-rank adaptation (LoRA) hyperparameters, such as rank. Set to 64, and the scaling factor α to rank. The learning rate was set to twice the standard value, and the dropout rate was set to 0.1. The fine-tuned data template constructed in step S122 was used as the training sample input to the model. The learning rate was set to 5.0e-5, and the number of training epochs was set to 4. During training, a masked causal language modeling strategy was adopted, that is, only the cross-entropy loss of the response byte sequence portion from the <|response_start|> tag to the <|response_end|> tag was calculated, and the loss calculation of the request portion and the historical interaction portion was masked; the loss function used was... The formula is as follows:
[0072] ,
[0073] in, Indicates model parameters; This represents the total length of the byte sequence in the training samples; Indicates the first position in the sequence Bytes at each position; This represents the predicted probability distribution of the possible next byte;
[0074] S124. After fine-tuning, the low-rank matrix products obtained from training are statically merged back into the original weight matrix of the base model. This process ensures that fine-tuning does not introduce additional computational latency to the large language model. Then, the fine-tuned model is cross-validated using a test traffic dataset (including normal business handshakes and constructed malformed protocol attack packets) that was not involved in the fine-tuning. Evaluation metrics include perplexity and protocol structure validity rate (by reverse-parsening the binary response blocks generated by the model using a standard protocol parser and testing whether it can successfully parse without errors). The model with the preset performance metrics is retained as the final fine-tuned byte-level large language model.
[0075] In some embodiments, in step S2, a network request is received, the application layer protocol type is identified based on the target port number of the network request, and the encrypted protocol is decrypted to obtain the plaintext request. When managing the session interaction history by extracting a session marker from the plaintext request, the system first listens on a preset simulation service port on the deceiving host. After the attacker completes the TCP three-way handshake, the system receives the application layer packet and determines the protocol type based on the target port number. If the port is not within the preset range, it is marked as an unknown protocol. For encrypted protocols, the corresponding decryption module is called to obtain the plaintext request; for non-encrypted protocols, the original payload is used directly. Subsequently, the session marker is extracted from the plaintext request. For application layer protocols that support session states, the session marker is extracted from the application layer packet and compared with existing session markers. If the same session marker exists, the current request is added to the corresponding session interaction history; otherwise, a new session record is created. For application layer protocols that do not support session states or unknown protocols, the attacker's IP address is used as the session marker, and requests with the same IP address are added to the same session interaction history. Through the above steps, the system achieves protocol identification, decryption, and session management for multi-protocol requests, providing necessary context information for subsequent cache matching, protocol parsing, and large model invocation. The specific process is as follows:
[0076] S21. The system pre-listens on the deception host for the TCP ports corresponding to the network services to be simulated. For example, target port 80 corresponds to the HTTP protocol, target port 3306 corresponds to the MySQL protocol, and target port 22 corresponds to the SSH protocol. When the attacker initiates a TCP connection request and completes the three-way handshake, the system receives the application layer packets in the TCP payload and determines the application layer protocol type based on the target port number mapping. If the target port is not a preset common port, it is marked as an unknown protocol.
[0077] S22. If the identified application layer protocol is an encrypted protocol, such as SSH and HTTPS, the system calls the corresponding encryption module (such as the SSH key exchange and decryption engine, TLS decryption library) to decrypt the request payload and obtain the request content in plaintext. For non-encrypted protocols, such as HTTP and MySQL, the original payload is used directly as the plaintext request.
[0078] S23. The system extracts a session tag from the plaintext request to distinguish between sessions of different attackers and to associate historical interaction records within the same session. Specifically, for application layer protocols that support session states, the system extracts the corresponding session tag field from the application layer message and compares it with existing session records in the system; if the same session tag exists, the current request is assigned to the corresponding session history; otherwise, a new session tag is generated and a session record is created. For application layer protocols that do not support session states or unknown protocols, the system uses the attacker's source IP address as the session tag.
[0079] S24. The system stores the interaction records of each session in chronological order in the session database. Each session record contains at least a session tag, the original binary block of the request, the formatted text of the request, the corresponding response message, and a timestamp. When a subsequent request arrives, the system retrieves the historical interaction records of that session from the database based on the session tag, which are used for binary history concatenation of byte-level large language models or state deduction of word-level large language models.
[0080] In some embodiments, in step S2, the hash value of the original binary block of the plaintext request is calculated and compared with the cache database. If a matching record exists, the system directly reads the response message. When reading the response message directly, the system uses a hash function to calculate the hash value of the original binary block of the plaintext request. The system pre-builds and maintains a cache database (such as a Redis database) to store generated request-response pairs. The fields of this database table include a unique identifier, creation time, application layer protocol type, binary packet of the original network request message, binary packet of the original response message, hash representation of the network request, and time-to-live (TTL). The hash representation of the network request is used to compare whether the request received by the system is the same as the record in the table. When a new request arrives, the system calculates its hash value and queries the cache database to see if a record with the same hash value exists. If a match is found, the response message corresponding to that record is directly read; if no match is found, the process proceeds to the next stage of the rule-based request processing flow.
[0081] In some embodiments, if no matching record is found in step S3, the application layer payload of the plaintext request is parsed according to the protocol. If the parsing fails, the original binary block of the current request is concatenated with the historical interaction binary blocks of the session in chronological order to construct the first input prompt. When generating the response message based on the fine-tuned byte-level large language model, if the protocol parser cannot parse the request, the system determines that the request belongs to a low-level malformed message or an unknown binary protocol, which cannot be processed by the rule engine or the sub-word-level large language model. At this time, the system retrieves the historical interaction records corresponding to the session tag from the session database, extracts the original binary request block and response block from each historical record, arranges them in chronological order, and uses a predefined instruction template to concatenate them to generate the first input prompt. The prompt is input into the fine-tuned byte-level large language model, and the model generates a binary response stream through autoregression. The system directly returns this as a response message to the attacker and stores the request-response pair in the session database. This method utilizes a finely tuned byte-level large model to perfectly cover malformed underlying packets and unknown protocol streams that fail to be parsed. It can effectively simulate all common network service protocols and attacks targeting vulnerabilities in underlying protocols, filling the gap in the previous inability to comprehensively and faithfully simulate binary network service protocols. The specific process is as follows:
[0082] S301. The system retrieves all historical interaction records for the current session from the session database based on the session tag of the current request. Each historical record contains the original binary request block sent by the client and the original binary response block previously generated by the system. The system arranges these historical interaction pairs in chronological order to form an ordered list. If the current session has no historical records, the historical list is empty;
[0083] S302. The system adopts an instruction template consistent with the fine-tuning stage of the byte-level large language model, concatenating the historical interaction list with the current request. The template structure is as follows: <|history_start|>[history request-response pair 1]<|comma|>[history request-response pair 2]<|comma|>…[history request-response pair n]<|history_end|><|request_start|>[byte stream sequence of client request]<|request_end|>;
[0084] S303. Input the first input prompt word into the fine-tuned byte-level large language model. During inference, the model predicts the next byte one by one using a causal autoregressive approach. Based on the learning during the fine-tuning phase, after recognizing the <|request_end|> marker, the model automatically generates the <|response_start|> marker, and then continuously outputs the response byte sequence until the <|response_end|> marker is generated. The system extracts the byte sequence after <|response_start|> and before <|response_end|> as the generated binary response stream;
[0085] S304. The system directly encapsulates the generated binary response stream into the transport layer payload of the TCP / UDP protocol and returns it to the attacker through the established network connection. At the same time, the original binary block of the current request and the generated response binary block are treated as a new interaction pair and asynchronously saved to the session database for subsequent retrieval of the underlying interaction history.
[0086] In some embodiments, if parsing is successful in step S3, the parsed formatted data is matched against the structured matching rule library. If a match is found, when synthesizing the response message according to the rules, when the protocol parser successfully converts the application layer payload of the plaintext request into formatted data, the generated formatted data should contain all the fields required for request matching in the YAML format rules. For example, for the HTTP protocol, the parsing result includes fields such as request method, request path, request parameters, request headers, and request body; for the MySQL protocol, it includes command type and command payload; for the SSH protocol, it includes command payload. The system sends the above formatted data to the rule matching engine. The rule matching engine loads all rules from the structured matching rule library, filters out rules of the same protocol type from the structured matching rule library according to the application layer protocol type of the current request, compares the matching conditions one by one, and records all matching rules. If one or more matching rules exist, the rule with the highest priority is selected to process the network request. Then, the response template fields of the parsed rule are used to obtain all the necessary content for constructing the response message. If placeholders are used in the response data portion of the response template, the network request is parsed again based on the semantics of the placeholders to extract the necessary information, such as the user ID and session token. The placeholders are then replaced with the parsed information. Finally, the protocol parser is called to create the response message, populate it with the content contained in the response template, and return the response message to the attacker. If no matching rules exist, it means the network request cannot match any rule's triggering conditions, and the system cannot generate a response based on the rules. In this case, the formatted characters output after request parsing are used as input to a word-level large language model, which adaptively synthesizes the response message corresponding to the network request.
[0087] In some embodiments, if a match is not found in step S3, a second input prompt word is constructed. When generating the response message based on the sub-word-level large language model, the system constructs a second input prompt word that includes system instructions, protocol knowledge and RAG examples, virtual system state, relevant historical interaction records, the current structured request, and output constraints. This prompt word is input into the sub-word-level large language model, and the model generates a structured response text that conforms to the output constraints. According to the application layer protocol type, the structured response text is serialized into a binary response message. This step utilizes the generalization ability and context learning ability of the large language model to achieve a high-fidelity adaptive response to uncovered requests. The specific process is as follows:
[0088] S311. The system generates the second input prompt word according to the predefined comprehensive prompt word template. The comprehensive prompt word template is shown below:
[0089] “<System_Instruction>
[0090] You are a high-interaction honeypot service response engine deployed in an isolated sandbox. The network protocol you are currently simulating is: [insert network protocol type, such as MySQL 8.0]. Your task is to analyze the attacker's structured requests and generate a structured response that conforms to the protocol specification. Your output must be in strict JSON format and contain fields that are exactly the same as the system rules engine's response template (such as status_code, headers, action, body_data, etc.) so that the system serializer can directly convert it into network packets.
[0091] < / System_Instruction>
[0092] <Protocol_Knowledge_&_RAG_Examples>
[0093] Below is a standard input / output example of this protocol (retrieved by the Faiss vector database based on the semantic similarity of the current request): [Insert Top-K standard structured request / response examples]< / Protocol_Knowledge_&_RAG_Examples>
[0094] <Virtual_System_State>
[0095] The current internal state of the virtual system for this session (such as authenticated users, current path, defined variables, database lock status, etc.): [Insert virtual system state description generated from step three; if none, use "No specific state"]< / Virtual_System_State>
[0096] <Relevant_Interaction_History>
[0097] Session history strongly related to the current request (sorted chronologically): [Insert relevant historical interaction records retrieved in step two]
[0098] < / Relevant_Interaction_History>
[0099] <Current_Request>
[0100] The attacker just sent a structured request: [Insert currently parsed structured network request]
[0101] < / Current_Request>
[0102] <Output_Constraint>
[0103] Based on the above status and history, infer the system's expected response. Output only valid JSON format results; do not include any additional natural language interpretation.
[0104] < / Output_Constraint> "
[0105] in,<System_Instruction> Indicates system commands,<Protocol_Knowledge_&_RAG_Examples> Representing protocol knowledge and RAG examples,<Virtual_System_State> Indicates the state of the virtual system.<Relevant_Interaction_History> This indicates the relevant historical interaction records.<Current_Request> Indicates the current structured request.<Output_Constraint> Indicates output constraints;
[0106] S312. The system inputs the second input prompt word into the sub-word-level large language model. Based on its powerful logical reasoning and contextual understanding capabilities, the large language model generates response content that conforms to the protocol's business logic. It outputs a structured response text (such as a strict JSON string), which includes fields such as the response status code, returned data lines, and directory echo.
[0107] S313. Because the TCP transport layer only accepts binary byte streams, the system cannot directly return structured response text to the attacker. Based on the current application layer protocol type, the system calls the matching protocol serialization middleware (such as using the serialization interface of the mysql-mimic library or the underlying packetization functions of OpenResty) to automatically calculate and fill in the dynamic fields required by the protocol (such as variable-length integers, checksums, and sequence numbers), ultimately obtaining a binary response message that conforms to the protocol specifications.
[0108] S314. The system returns a binary response message to the attacker and simultaneously stores the formatted data of the current request and the structured response text generated by the model as an interactive pair in the session database to update the virtual system state and history. This not only updates the session history but also provides structured basic data for subsequently triggering "virtual system state inference and compression".
[0109] In some embodiments, when obtaining the relevant historical interaction records and virtual system state in the second input prompt in step S3, the historical interaction records of the current session are obtained, and their total length is calculated. If the total length does not exceed a preset threshold, the historical interaction records are directly filled into the second input prompt as relevant historical interaction records, and the virtual system state is set to empty. If the total length exceeds the preset threshold, the historical interaction records are divided into a preset number of segments according to time order, and the sub-word-level large language model is called sequentially to perform correlation filtering on each segment, extracting interaction pairs that have logical dependence, state dependence, or contextual association with the current request, and merging them according to time order to obtain... The relevant historical interaction records are obtained. If the total length of the merged relevant historical interaction records still exceeds a preset threshold, the relevant historical interaction records are again divided into a preset number of segments in chronological order. Starting from the current virtual system state, the sub-word level large language model is called segment by segment. The virtual system state generated in the previous round is combined with the current historical segment as input to generate the virtual system state after the interaction of that segment. The generated virtual system state is used as the input for the next round of iteration. Finally, the compressed virtual system state is obtained, and the relevant historical interaction records are cleared or only the latest round of interaction pairs are retained. The compressed virtual system state is then filled into the second input prompt word. The specific process is as follows:
[0110] S321. The system retrieves the complete historical interaction record of the current session and calculates its total length (e.g., number of tokens or total character length). The system presets a length threshold (e.g., 60% of the maximum context window of the sub-word-level large language model). If the total length does not exceed the threshold, the complete historical interaction record is directly used as the total length.<Relevant_Interaction_History> Enter the second input prompt and set the virtual system status field to empty. The process ends. If the threshold is exceeded, proceed to step S322.
[0111] S322. The system divides the complete historical interaction record into multiple fixed-length segments in chronological order. For each segment, the system constructs relevant search suggestions, including the formatted content of the current request and the historical segment. It then calls a sub-word-level large language model to determine whether each interaction pair in the segment has a logical dependency, state dependency, or contextual association with the current request. The model outputs the filtered relevant interaction pairs. The system merges the filtered interaction pairs from all segments in their original chronological order to obtain the relevant historical interaction record. The relevant search suggestion template is as follows:
[0112] "Task objective: From the following historical session fragments, select historical interaction pairs that have logical dependencies, state dependencies, or contextual relationships with the current attacker's request."
[0113] [Current Request]: {Insert the currently formatted request content}
[0114] [Historical Session Fragments]: {Insert segmented historical interaction fragments, containing multiple request-response pairs}
[0115] Processing requirements: If a certain set of interactions in the segment (such as authentication login, variable assignment, directory switching) directly affects the processing of the [current request], please extract it. If they are unrelated, please ignore them. The extracted results should be output strictly in the original chronological order.
[0116] S323. The system calculates the total length of the relevant historical interaction records merged in step S322. If the length does not exceed a preset threshold, it is used as the relevant historical interaction record in the second input prompt, and the virtual system state is set to empty, ending the process. If it still exceeds the threshold, proceed to step S324.
[0117] S324. The system further divides the relevant historical interaction records obtained in step S323 into multiple continuous segments in chronological order. Starting from the initial virtual system state (usually empty or a preset initial value), the system performs the following iterative operations segment by segment: The current virtual system state is combined with the current historical segment as input to construct state deduction prompts. A sub-word-level large language model is then required to analyze the interaction behaviors in this segment, inferring the substantial changes these behaviors cause to the system state, and outputting a new virtual system state snapshot. The newly generated state is used as the input virtual system state for the next iteration. After iteratively processing all segments, the system obtains the final compressed virtual system state. Simultaneously, the system clears the relevant historical interaction records or retains only the latest single-round interaction pairs.
[0118] Specifically, the state deduction prompt word template is as follows:
[0119] "Task objective: As the system kernel state machine, you need to segment and iteratively update and deduce the current virtual system state snapshot based on the given historical network interaction records."
[0120] [Input Parameters]: 1. Inherited system state snapshot ( ): {Insert a snapshot of the structured system state generated in the previous round of simulation; empty if this is the first time.}
[0121] 2. Relevant historical interaction segments within the current time window ( ): {Insert the i-th relevant historical interaction segment segmented in chronological order}
[0122] [Processing Requirements]: Please conduct a rigorous analysis of the current segment ( Network interactions within the system state snapshot. Determine if these request-response pairs result in persistent system state changes. Apply these substantial changes to the inherited system state snapshot. Ignore interactions that are merely probing reads or error messages and do not change the system state.
[0123] [Output Specification]: Please generate a concise, highly compressed snapshot of the latest system state. The output must be in strict JSON format, and should include the following structured dimensions based on the actual interaction log:
[0124] {"authentication_state":"Authentication and authorization information","context_environment":"Current directory / database / environment variables","data_modifications":"Summary of created files / tables / records","protocol_flags":"Underlying state such as transactions / cookies"}
[0125] Please output the JSON result directly, without any reasoning or unnecessary natural language explanations.
[0126] Specifically, the virtual system state snapshot is represented in structured key-value pairs or JSON format, and its contents are dynamically determined according to the type of network protocol being simulated, including but not limited to the following dimensions:
[0127] Authentication & Privilege: The username of the user who has successfully logged in in the current session, the user role / permission level (such as Root, Admin or Guest), and the currently valid session token or authentication flag;
[0128] Context & Environment: The current working directory of the system (e.g., the current directory pwd in the SSH protocol), the database object currently selected for operation (e.g., USE database_name in the MySQL protocol), and the currently active environment variable settings;
[0129] Data & Resource Modifications: Persistent system changes resulting from attacker actions during the interaction. Examples include temporarily created, modified, or deleted file paths and key content summaries (applicable to SSH / HTTP); newly added database table structures, injected data records or views (applicable to MySQL); and modified system configuration items.
[0130] Protocol-specific flags: specific logical states at the underlying level of network protocols, such as the transaction start / commit state in database interactions, the active cookie state of an HTTP session, or step markers in a business process.
[0131] S325. The system fills the compressed virtual system status generated in step S324 into the second input prompt word.<Virtual_System_State> The field will be filled with the relevant historical interaction records after they have been cleared.<Relevant_Interaction_History> Fields. If the latest round of interaction pairs still needs to be retained after clearing, then only the most recent request-response pair will be retained.
[0132] In some embodiments, after completing offline preparation and building the online simulation engine, the system packages the structured matching rule base generated in the offline phase, the fine-tuned byte-level large language model weight file, the Faiss vector database, and the online service simulation response engine code (including various protocol parsing middleware), lightweight basic operating system, monitoring program, and behavior logging program in the online phase into a standard Docker container image. In practical applications, security operations personnel only need to assign a specified IP address and listening port to the Docker image through a configuration file to start the container instance with one click and run a complete general-purpose network service simulation honeypot. Since the core response generation relies entirely on the dynamic inference of the rule engine and the large language model rather than the actual vulnerable service program, this honeypot image can be deployed on a large scale and in batches on different network segments of the enterprise intranet or cloud environment hosts with extremely low security risk, thereby forming a wide-ranging distributed decoy network to achieve efficient perception and capture of attackers' various network service probing and lateral movement behaviors.
[0133] While embodiments of the present invention have been described in detail above, it will be apparent to those skilled in the art that various modifications and variations can be made to these embodiments. However, it should be understood that such modifications and variations fall within the scope and spirit of the invention as set forth in the claims. Furthermore, the invention described herein may have other embodiments and can be implemented or carried out in various ways.
Claims
1. A method for constructing honeypots for general network service simulation based on a large language model, characterized in that, include: Obtain network interaction traffic, and construct a structured matching rule base and fine-tune a byte-level large language model respectively; Receive a network request, identify the application layer protocol type based on the target port number of the network request, and decrypt the encrypted protocol to obtain the plaintext request; Extract session tokens from the plaintext request to manage session interaction history; Calculate the hash value of the original binary block of the plaintext request and compare it with the cache database; If a matching record exists, the response message is read directly. If no matching record is found, the application layer payload of the plaintext request is parsed according to the protocol. If the parsing fails, the original binary block of the current request is concatenated with the historical interaction binary block of the session in chronological order to construct the first input prompt word, and a response message is generated based on the fine-tuned byte-level large language model. If the parsing is successful, the parsed formatted data is matched with the structured matching rule base. If a match is found, a response message is synthesized according to the rules. If no match is found, a second input prompt word is constructed, and a response message is generated based on the sub-word level large language model; If the original request is an encrypted protocol, the response message is encrypted and returned to the attacker; otherwise, it is returned directly. The plaintext request and the corresponding response message are then stored as traffic pairs in the cache database and the session database.
2. The method as described in claim 1, characterized in that, When acquiring network traffic, this includes: For application layer protocols that have publicly available traffic datasets, obtain the open-source traffic dataset; For application layer protocols that do not have publicly available traffic datasets, a traffic dataset is synthesized independently. The independent synthesis process includes: deploying the application layer protocol server in an isolated environment and disabling the encrypted transmission mechanism of the server; using automated operation tools to send normal business operation request messages and abnormal operation request messages to the server; during the sending of request messages, capturing messages on the communication port of the server through a bypass listening program, generating and saving them as a data packet capture file; and obtaining the independently generated traffic dataset based on the data packet capture file.
3. The method as described in claim 1, characterized in that, When building a structured matching rule base, the following are included: The network interaction traffic is preprocessed to obtain preprocessed network interaction traffic; the preprocessed network interaction traffic is grouped according to the application layer protocol type; for the request payload data in each group, a feature vector is calculated based on the term frequency-inverse document frequency algorithm; and the feature vector is clustered based on the density-based spatial clustering algorithm. The request-response pairs from the clustering results are input into a pre-trained large language model, which outputs structured matching rules in YAML format based on preset prompt word templates. Each rule contains metadata, matching conditions, and a response template. Conflict detection is performed on the structured matching rules. When different structured matching rules are detected to match the same request message, their priority parameters or matching condition expressions are adjusted. The coverage and semantic accuracy of the structured matching rules are statistically analyzed using verification traffic data. Structured matching rules whose coverage and semantic accuracy are both higher than a preset threshold are retained to obtain a structured matching rule library.
4. The method as described in claim 1, characterized in that, Fine-tuning byte-level large language models includes: The application layer payload is extracted from the network interaction traffic, and session reassembly, denoising and truncation are performed to obtain a cleaned payload byte stream. The requests and corresponding responses in the cleaned payload byte stream are saved as binary byte sequences, special control flags are injected and concatenated in time to construct a fine-tuning data template. The fine-tuning data template includes a request start flag, a request byte sequence, a request end flag, a response start flag, a response byte sequence, and a response end flag. For stateful application layer protocols, a sliding window mechanism is used to concatenate the history of multiple rounds of interaction in the same session as a context prefix before the current request. The fine-tuning data template is used as a training sample to input into a byte-level large language model, and fine-tuning is performed based on low-rank adaptation technology; during fine-tuning, a masked causal language modeling strategy is adopted, and the prediction loss is calculated only for the response byte sequence portion; After fine-tuning, the low-rank matrix parameters obtained from training are merged into the original weights of the byte-level large language model, and cross-validation is performed using test traffic data that was not involved in fine-tuning, retaining the model that meets the preset performance indicators.
5. The method as described in claim 1, characterized in that, When extracting session tokens from the plaintext request and managing session interaction history, the following are included: For application layer protocols that support session state, extract the session tag from the application layer message and compare it with the existing session tag. If the same session tag exists, the current request is added to the corresponding session interaction history; otherwise, a new session record is created. For application layer protocols or unknown protocols that do not support session state, the attacker's IP address is used as the session identifier, and requests with the same IP address are grouped into the same session interaction history.
6. The method as described in claim 1, characterized in that, When generating response messages based on the fine-tuned byte-level large language model, the following are included: The first input prompt is input into the fine-tuned byte-level large language model, and a binary response stream is generated autoregressively after the preset response start marker, which serves as the response message; the first input prompt includes a history session start marker, a history request-response pair, a separator marker, a history session end marker, a request start marker, a request byte sequence, and a request end marker.
7. The method as described in claim 1, characterized in that, If parsing is successful, the parsed formatted data is matched against the structured matching rule base. If a match is found, the response message is synthesized according to the rules, including: The parsed formatted data is matched with rules of the same application layer protocol type in the structured matching rule base, and all matching rules are recorded. If at least one rule is matched, the rule with the highest priority is selected; based on the response template of the selected rule, the content required for the response message is obtained; if the response template contains placeholders, the corresponding information is extracted from the plaintext request according to the semantics of the placeholders and replaced; the protocol parser is called to construct the response message based on the content in the response template.
8. The method as described in claim 1, characterized in that, If no match is found, a second input prompt word is constructed. When generating the response message based on the sub-word-level large language model, this includes: The second input prompt includes system instructions, protocol knowledge and RAG examples, virtual system status, relevant historical interaction records, current structured request, and output constraints; wherein, the system instructions include the network protocol type and output format constraints of the current simulation, and the protocol knowledge and RAG examples include example request-response pairs recalled by the vector database based on the semantic similarity of the current request; The second input prompt word is input into the sub-word level large language model to generate a structured response text that conforms to the output constraints; the structured response text is serialized into a binary response message according to the application layer protocol type.
9. The method as described in claim 8, characterized in that, The methods for obtaining the relevant historical interaction records and virtual system status in the second input prompt include: Obtain the historical interaction records of the current session and calculate their total length; if the total length does not exceed the preset threshold, directly fill the historical interaction records as the relevant historical interaction records into the second input prompt words, and set the virtual system status to empty; If the total length exceeds the preset threshold, the historical interaction records will be divided into preset segments in chronological order. The sub-word level large language model will be called sequentially to filter the relevance of each segment, extract the interaction pairs that have logical dependence, state dependence or contextual association with the current request, and merge them in chronological order to obtain the relevant historical interaction records. If the total length of the merged related historical interaction records still exceeds the preset threshold, the related historical interaction records are again divided into a preset number of segments in chronological order. Starting from the current virtual system state, the sub-word level large language model is called segment by segment. The virtual system state generated in the previous round is combined with the current historical segment as input to generate the virtual system state after the interaction of the segment. The generated virtual system state is used as the input for the next round of iteration to finally obtain the compressed virtual system state. The related historical interaction records are cleared or only the latest round of interaction pairs are retained. The compressed virtual system state is then filled into the second input prompt word.
10. The method as described in claim 1, characterized in that, The following deployment steps are also included: The structured matching rule base, the fine-tuned byte-level large language model, and the program code required to run the method are packaged and built into a container image; the container image is then instantiated as a simulated honeypot by assigning a specified network address and listening port to it.