A path signature-based covert exploit traffic identification method

Abstract

The application discloses a kind of based on path signature concealed exploit traffic identification method, comprising: marking traffic dataset construction;TLS record level traffic sequence construction;Multi-window path signature feature extraction;Identification model training and detection.For the problem that plaintext attack payload is invisible under TLS encryption scene, and the detection method based on handshake information, packet statistical feature or single TLS record length sequence is difficult to fully depict exploit interaction process, the application reorganizes and analyzes TLS record to the transmission layer load, and four-dimensional TLS record path is mapped to the direction, type, length and position of TLS record;First-order path signature feature and second-order path signature feature are calculated using overall window and multi-level local window, respectively depict the overall change of each path dimension and the interaction relationship between different path dimensions with order, so that the model can identify concealed exploit traffic without decrypting communication content.When the number of TLS records is 24, the Macro-F1 of the present application under twin benign traffic scene and browsing benign traffic scene is 95.39% and 97.99% respectively, and the false positive rate is low, so that the concealed exploit traffic can be effectively identified.

Description

Technical Field

[0001] This invention belongs to the field of cyberspace security technology, and in particular relates to a method for identifying covert vulnerability exploit traffic by constructing TLS record-level traffic sequences and extracting multi-window path signature features. Background Technology

[0002] With the widespread deployment of internet business systems, cloud service platforms, and various web applications, network vulnerability exploitation has become a significant threat to cybersecurity. Attackers can exploit publicly known vulnerabilities, configuration flaws, or application implementation defects to construct exploit requests, achieving objectives such as unauthorized access, sensitive information reading, remote code execution, or bypassing business logic. Such exploits are typically characterized by concealed request structures, short triggering processes, and flexible attack payloads. If not detected in time, they can lead to security risks such as loss of system privileges, data breaches, and business interruptions. Therefore, effectively identifying vulnerability exploits in network traffic is a crucial technical challenge in network security monitoring, protection, and incident response.

[0003] Existing vulnerability exploitation detection methods mainly include network-side detection methods based on rule matching, deep packet inspection, and machine learning. For unencrypted communication scenarios, detection systems can directly analyze plaintext information such as request paths, request header fields, parameter content, and attack payloads to construct feature rules or train recognition models. However, in real-world network environments, many web services use encrypted communication based on the TLS protocol to transmit data. Both exploit requests and normal business requests are encapsulated in encrypted channels. Traditional detection methods relying on plaintext content, protocol fields, and attack payload characteristics are difficult to apply directly, resulting in stronger concealment of exploit behaviors under encrypted transmission conditions.

[0004] For encrypted traffic scenarios, existing methods typically utilize packet length, arrival time interval, direction sequence, traffic statistics, or deep learning models to identify traffic behavior. While these methods can extract some side-channel information without decrypting the communication content, they still have certain limitations: Firstly, single statistical features or simple sequence features are insufficient to fully characterize the evolution of encrypted communication interactions during vulnerability exploitation; secondly, modeling directly based on packet-level features is easily affected by link status, retransmission, fragmentation, and differences in the acquisition environment, leading to insufficient feature stability. Furthermore, although some deep learning methods have strong automatic feature extraction capabilities, the meaning of their features is not intuitive enough to explain the basis for the model's identification of hidden vulnerability exploitation traffic.

[0005] Therefore, how to extract relatively stable discrimination criteria from network traffic in encrypted communication scenarios and construct a method for identifying hidden vulnerability exploitation traffic that takes into account recognition capabilities, feature stability, and interpretability is a problem that existing technologies urgently need to solve. Summary of the Invention

[0006] To enhance network-side identification capabilities for covert vulnerability exploitation in encrypted communication scenarios, and addressing the limitations of existing detection methods based on handshake information, packet statistical features, or single TLS record length sequences in fully characterizing the multidimensional attribute changes and ordered interactions of TLS records during vulnerability exploitation, this invention proposes a path signature-based method for identifying covert vulnerability exploitation traffic. This method first constructs a labeled traffic dataset containing covert vulnerability exploitation traffic, benign browsing traffic, and twin benign traffic. Second, it performs grouping and transport layer payload reassembly on the original traffic, parses TLS records, and maps the TLS record direction, TLS record type, TLS record length, and TLS record position into a four-dimensional TLS record path. Then, it forms TLS record paths under different communication ranges through a global window and multi-level local windows, calculating first-order and second-order path signature features respectively, forming a path signature feature representation that considers the overall communication process, local interactive changes, and ordered relationships between dimensions. Finally, the path signature feature representation is input into the covert vulnerability exploitation traffic identification model to identify covert vulnerability exploitation traffic. By utilizing the changes in multidimensional attributes of TLS records during communication and their ordered interactions as identification criteria, this invention can improve the identification capability, feature stability, and result interpretability of covert vulnerability exploit traffic without decrypting the communication content. To achieve the above objectives, this invention provides the following technical solution:

[0007] A method for identifying covert vulnerability exploit traffic based on path signatures includes the following steps:

[0008] (1) Construct a labeled traffic dataset for training and testing. Set up multiple vulnerability service environments, collect traffic for exploiting hidden vulnerabilities, and collect benign browsing traffic and twin benign traffic for the same vulnerability service environment to form a labeled sample dataset with a control relationship;

[0009] (2) Perform grouping, direction division and transport layer load reassembly on the labeled traffic dataset and the network traffic to be detected, parse the reassembled TLS records, and construct a TLS record-level traffic sequence containing record direction, record type, record length and record position according to the parsing order of the TLS records;

[0010] (3) Construct a four-dimensional TLS record path based on the TLS record-level traffic sequence, divide the TLS record path according to the overall window and multi-level local windows, and calculate the first-order path signature and the second-order path signature in each window to form a path signature feature representation for identifying traffic exploiting hidden vulnerabilities.

[0011] (4) Train a hidden vulnerability exploit traffic identification model using training samples and their path signature features in the labeled traffic dataset, and input the path signature features corresponding to the test samples and the network traffic to be detected into the identification model, and output the identification result of whether the network traffic to be detected is a hidden vulnerability exploit traffic. Further, step (1) specifically includes the following sub-steps:

[0012] (1.1) Build multiple vulnerability service environments based on Vulhub to generate network access traffic under different vulnerability scenarios;

[0013] (1.2) For vulnerable service environments that do not support TLS encrypted access, Nginx is used to build a reverse proxy to encapsulate the communication process between the client and the vulnerable server into TLS encrypted communication, so as to form a hidden vulnerability exploitation traffic collection environment;

[0014] (1.3) Construct vulnerability exploitation requests for the vulnerability service environment. The vulnerability exploitation requests are modified based on publicly available vulnerability exploitation requests. While ensuring that the vulnerability can still be triggered, the variable parts are adjusted to enrich the vulnerability exploitation traffic samples.

[0015] (1.4) Collect TLS encrypted network traffic during the process of the client sending a vulnerability exploitation request to the vulnerability service environment, and mark it as covert vulnerability exploitation traffic;

[0016] (1.5) Collect normal access traffic for the same vulnerability service environment. The normal access traffic includes browsing benign traffic and twin benign traffic. Among them, browsing benign traffic is the TLS encrypted network traffic generated when the client makes a normal business access request to the vulnerability service environment. Twin benign traffic is the TLS encrypted network traffic generated after replacing the malicious content in the vulnerability exploitation request with normal content while retaining the basic structure of the vulnerability exploitation request.

[0017] (1.6) The collected hidden vulnerability exploitation traffic, benign browsing traffic and twin benign traffic are uniformly labeled, organized and sampled to construct a labeled traffic dataset;

[0018] (1.7) The labeled traffic dataset is divided into layers according to the vulnerability service environment and traffic category, and training samples and test samples are constructed using the five-fold cross-validation method for subsequent TLS record-level traffic sequence construction, path signature feature extraction, model training and detection verification.

[0019] Through steps (1.1) to (1.7), the labeled traffic dataset constructed by this invention simultaneously includes covert exploit traffic, benign browsing traffic, and twin benign traffic. Compared to schemes that only use ordinary normal access traffic as benign samples, this invention preserves the basic structure of exploit requests and replaces the malicious content within them by using twin benign traffic. This allows the model to learn the differences between attack-triggered behaviors and highly similar normal access, thereby reducing false positives caused by similar request structures.

[0020] Furthermore, step (2) specifically includes the following sub-steps:

[0021] (2.1) The labeled traffic dataset and the network traffic to be detected are grouped into streams according to the five-tuple, wherein the five-tuple includes the source IP address, destination IP address, source port, destination port and transport layer protocol, to obtain multiple network session streams;

[0022] (2.2) For each network session flow, determine the TLS record direction based on the communication relationship between the client and the vulnerable server, encode the client-to-server direction as +1, and encode the server-to-client direction as -1, and use... Indicates the first The direction encoding corresponding to each TLS record;

[0023] (2.3) Reassemble the forward and reverse transport layer payloads according to the TCP sequence number, remove duplicate transmission segments with the same sequence number and payload length, and obtain continuous encrypted payload byte streams in the corresponding directions;

[0024] (2.4) Locate and parse the encrypted payload byte stream byte by byte according to the TLS record header format; when the content type is 20, 21, 22, 23 or 24, the protocol version is between 0x0300 and 0x0304, and the record length is no more than 18432 bytes, determine the current record as a valid TLS record and extract its record direction. Record type and record length And generate record positions starting from 0 in the parsing order of valid TLS records. ;

[0025] (2.5) Arrange the TLS records in each valid TLS session stream into a sequence of four tuples according to the parsing order. The records are truncated or padded according to a preset number N. When the number of valid TLS records is greater than N, the first N records are retained. When the number of valid TLS records is less than N, all-zero records are used to pad the records. The all-zero records are only used to unify the input length and do not participate in the calculation of the valid path increment.

[0026] Through steps (2.1) to (2.5), this invention first performs directional reassembly and duplicate fragment removal on the transport layer payload, then parses the TLS records to form a sequence of four-tuples representing direction, type, length, and position. Compared to schemes that directly statistically analyze the original data packets or only record the length and direction of the TLS records, this invention can reduce the impact of TCP fragmentation, retransmission, and differences in the acquisition link on the characteristics, and retain the protocol function category and session position of the TLS records in a unified sequence.

[0027] Furthermore, step (3) specifically includes the following sub-steps:

[0028] (3.1) Construct the TLS record path representation, for the first TLS record obtained in step (2.5) Each of the following is a valid TLS record, with its record direction, record type, record length, and record position recorded as follows: , , and And construct four-dimensional path points according to the following formula:

[0029]

[0030] Arrange the path points according to the parsing order of the TLS records to form the following TLS record path:

[0031]

[0032] in, ∈{+1,-1}, This represents the number of valid TLS records involved in path calculation in the current session. It is the natural logarithm.

[0033] (3.2) Construct a multi-level window path representation, set an overall window covering the complete TLS record path, and divide the valid TLS record path into two levels according to the proportion, forming two first-level local windows, four second-level local windows and eight third-level local windows in sequence, resulting in a total of 15 windows; the path points in each level of the window remain unchanged according to the original parsing order, and when there are fewer than two valid path points in a certain window, the path signature feature corresponding to that window is set to all zeros;

[0034] (3.3) Calculate the path change sequence for any window. Suppose that the window contains There are path points, and the window path is represented as:

[0035]

[0036] Calculate the path increment between adjacent path points sequentially, following the original parsing order of the path points within the window:

[0037]

[0038] (3.4) Extract path signature features. For any window w, its first-order path signature is calculated according to the following formula:

[0039]

[0040] When calculating the second-order path signature, the first-order path signature, the second-order path signature, and the prefix accumulator are first initialized:

[0041]

[0042] In the In the nth iteration, the th... The second-order interaction terms corresponding to each path increment:

[0043]

[0044] And update the second-order path signature and prefix accumulation in sequence:

[0045]

[0046]

[0047] in, This represents the outer product of vectors. After traversing all path increments, the 4-dimensional first-order path signature and 16-dimensional second-order path signature corresponding to each window are expanded and concatenated in the order of global window, first-level local window, second-level local window, and third-level local window to form a 300-dimensional path signature feature representation.

[0048] Through steps (3.1) to (3.4), this invention maps the multidimensional attributes of TLS records to four-dimensional paths, and calculates first-order and second-order path signatures within the overall window and multi-level local windows, respectively. Compared to a single overall sequence, ordinary statistics, or unordered feature combinations, this invention can simultaneously characterize the overall changes in each path dimension, the local changes in different communication stages, and the sequential interaction relationships between path dimensions, thereby forming a directly interpretable 300-dimensional path signature feature representation with a fixed dimension.

[0049] Furthermore, step (4) specifically includes the following sub-steps:

[0050] (4.1) The training sample set is constructed by taking the 300-dimensional path signature feature representation corresponding to the training sample as input and the sample as belonging to the hidden vulnerability exploit traffic or normal access traffic as label, and the LightGBM hidden vulnerability exploit traffic identification model is trained by class balanced weight.

[0051] (4.2) Perform hierarchical five-fold cross-validation according to the vulnerability service environment and traffic category; use three-fold validation inside each outer training fold to obtain the prediction score of the training sample, and select the threshold that maximizes Macro-F1 within the candidate threshold range of 0.05 to 0.95 as the judgment threshold of the outer fold, so that the recognition model learns the correspondence between the path signature features and the traffic category;

[0052] (4.3) Perform the same grouping, transport layer load reassembly, TLS record parsing, four-dimensional path construction, multi-window partitioning, and first- and second-order path signature calculations on the network traffic to be detected as steps (2) and (3) to obtain the 300-dimensional path signature feature representation of the network traffic to be detected.

[0053] (4.4) Input the path signature feature representation corresponding to the network traffic to be detected into the trained covert vulnerability exploitation traffic identification model to obtain the identification score of its belonging to covert vulnerability exploitation traffic. And according to the recognition score With the judgment threshold Relationships determine traffic categories:

[0054]

[0055] when Greater than or equal to If the network traffic to be detected is deemed to be exploiting a hidden vulnerability, it will be classified as normal access traffic. The value range is [0,1]. The threshold value is the one determined in step (4.2).

[0056] Through steps (4.1) to (4.4), this invention trains the LightGBM model using class-balanced weights and selects a decision threshold that maximizes Macro-F1 within the training data. Compared to model training methods that use fixed thresholds or ignore differences in class distribution, this invention can balance the detection capability of covert vulnerability exploitation traffic and the control of false alarms for normal access traffic, while maintaining low online feature computation and classification overhead.

[0057] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0058] (1) This invention constructs covert exploit traffic, benign browsing traffic, and twin benign traffic for the same vulnerability service environment. The twin benign traffic replaces malicious content with normal content while retaining the basic structure of the exploit request, so that the training samples simultaneously cover real benign access and difficult benign samples with highly similar attack traffic structures. Compared with the scheme that only uses general normal access traffic to construct the training set, this invention enables the identification model to pay more attention to the changes in TLS records caused by exploit interaction behavior, and reduces false positives caused by similar request structures.

[0059] (2) This invention performs directional reassembly and deduplication on the transport layer payload before parsing TLS records, and maps the record direction, record type, record length, and record position to four-dimensional path points, enabling the TLS request-response direction, protocol function category, data size, and session stage to be jointly described in a unified path representation. Compared to directly using packet-level statistical features or only using TLS record length sequences with direction symbols, this invention can reduce the impact of retransmission, fragmentation, and differences in the acquisition link on features, and provides a foundation for subsequently characterizing the ordered interaction relationships between different record attributes.

[0060] (3) This invention divides the same TLS record path into an overall window, two first-level local windows, four second-level local windows, and eight third-level local windows, and calculates first-order path signatures and second-order path signatures within each window. The first-order path signature is used to characterize the overall change of each path dimension within the corresponding window, and the second-order path signature is used to characterize the sequential interaction relationship between changes in different path dimensions. By sequentially splicing the 20-dimensional path signatures corresponding to the 15 windows to form a 300-dimensional feature representation, this invention can simultaneously characterize the complete communication process, local interaction stages, and ordered relationships between dimensions, avoiding the loss of local stage differences and interaction order information by a single overall sequence or ordinary statistics.

[0061] (4) This invention uses path signature feature representation as input to a LightGBM recognition model trained with class-balanced weights, and determines the judgment threshold within the training data, which can reduce false positives in normal access traffic while maintaining high detection capability. Under five-fold cross-validation, the precision, recall, and Macro-F1 of this invention in the scenario of browsing benign traffic reach 97.94%, 96.67%, and 97.99%, respectively, with a false positive rate of 1.002%; in the scenario of twin benign traffic, the precision, recall, and Macro-F1 reach 95.16%, 94.24%, and 95.39%, respectively, with a false positive rate of 3.566%. Attached Figure Description

[0062] Figure 1 A schematic diagram of a traffic identification framework for covert vulnerability exploitation;

[0063] Figure 2 A schematic diagram illustrating the iterative calculation process of first-order path signatures and second-order path signatures;

[0064] Figure 3 Performance of the model on different performance metrics under different numbers of TLS records;

[0065] Figure 4 Comparison of the identification performance of different encrypted malicious traffic detection methods in two benign traffic scenarios. Detailed Implementation

[0066] The technical solutions provided by the present invention will be described in detail below with reference to specific embodiments. It should be understood that the following specific embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention.

[0067] Example 1: This invention proposes a method for identifying covert vulnerability exploit traffic based on path signatures. The identification framework is as follows: Figure 1 As shown, it is divided into four parts. The first part is the construction of the labeled traffic dataset. Specifically, it involves building a vulnerability service environment based on Vulhub, using Nginx to encapsulate the vulnerability service that does not support TLS encrypted access into encrypted communication, and collecting hidden vulnerability exploit traffic, browsing benign traffic, and twin benign traffic. The second part is the construction of TLS record-level traffic sequences. Specifically, it involves grouping, dedirecting, and reassembling the transport layer load of the original encrypted traffic to parse out the TLS record direction, type, length, and position. The third part is the extraction of multi-window path signature features. Specifically, it involves mapping the multi-dimensional attributes of TLS records to four-dimensional path points, dividing the TLS record path according to the overall window and the three-level local window, and calculating the first-order path signature and the second-order path signature respectively to form a 300-dimensional path signature feature representation. The iterative calculation process of the first-order path signature and the second-order path signature is as follows. Figure 2 As shown; the fourth part is the training and detection of the recognition model, which specifically involves training the LightGBM recognition model using path signature feature representation, and classifying the test traffic based on the recognition score and judgment threshold output by the model. Figure 3 The model's performance on different metrics is shown under different numbers of TLS records. Figure 4 The performance comparison of TLS-MHSA, ADRSA, DC-GL, and the present invention in benign traffic scenarios and twin benign traffic scenarios is shown. The comparison metrics include precision, recall, Macro-F1, and false positive rate. Specifically, a method for identifying covert vulnerability exploitation traffic based on path signatures includes the following steps:

[0068] (1) Construct a labeled traffic dataset for training and testing.

[0069] The specific process for this step is as follows:

[0070] (1.1) Build multiple vulnerability service environments based on Vulhub to generate network access traffic under different vulnerability scenarios;

[0071] (1.2) For vulnerable service environments that do not support TLS encrypted access, Nginx is used to build a reverse proxy to encapsulate the communication process between the client and the vulnerable server into TLS encrypted communication, so as to form a hidden vulnerability exploitation traffic collection environment;

[0072] (1.3) Construct vulnerability exploitation requests for the vulnerability service environment. The vulnerability exploitation requests are modified based on publicly available vulnerability exploitation requests. While ensuring that the vulnerability can still be triggered, the variable parts are adjusted to enrich the vulnerability exploitation traffic samples.

[0073] (1.4) Collect TLS encrypted network traffic during the process of the client sending a vulnerability exploitation request to the vulnerability service environment, and mark it as covert vulnerability exploitation traffic;

[0074] (1.5) Collect the following three traffic samples for the same vulnerable service environment:

[0075]

[0076] (1.6) The collected hidden vulnerability exploitation traffic, benign browsing traffic and twin benign traffic are uniformly labeled, organized and sampled to construct a labeled traffic dataset;

[0077] (1.7) The labeled traffic dataset is divided into layers according to the vulnerability service environment and traffic category, and training samples and test samples are constructed using the five-fold cross-validation method for subsequent TLS record-level traffic sequence construction, path signature feature extraction, model training and detection verification.

[0078] (2) Perform group flow and transport layer load reassembly on the labeled traffic dataset and the network traffic to be detected, parse the reassembled TLS records, extract the TLS record direction, TLS record type, TLS record length and TLS record position, and construct the TLS record-level traffic sequence according to the parsing order of the TLS records.

[0079] The specific process for this step is as follows:

[0080] (2.1) The labeled traffic dataset and the network traffic to be detected are grouped into streams according to the five-tuple, wherein the five-tuple includes the source IP address, destination IP address, source port, destination port and transport layer protocol, to obtain multiple network session streams;

[0081] (2.2) For each network session flow, determine the TLS record direction based on the communication relationship between the client and the vulnerable server, encode the client-to-server direction as +1, and encode the server-to-client direction as -1, and use... Indicates the first The direction encoding corresponding to each TLS record;

[0082] (2.3) Reassemble the forward and reverse transport layer payloads according to the TCP sequence number, remove duplicate transmission segments with the same sequence number and payload length, and obtain continuous encrypted payload byte streams in the corresponding directions;

[0083] (2.4) Locate and parse the encrypted payload byte stream byte by byte according to the TLS record header format; when the content type is 20, 21, 22, 23 or 24, the protocol version is between 0x0300 and 0x0304, and the record length is no more than 18432 bytes, determine the current record as a valid TLS record and extract its record direction. Record type and record length And generate record positions starting from 0 in the parsing order of valid TLS records. The descriptions of each field are as follows:

[0084]

[0085] (2.5) Arrange the TLS records in each valid TLS session stream into a sequence of four tuples according to the parsing order. The records are truncated or padded according to a preset number N. When the number of valid TLS records is greater than N, the first N records are retained. When the number of valid TLS records is less than N, all-zero records are used to pad the records. The all-zero records are only used to unify the input length and do not participate in the calculation of the valid path increment.

[0086] (3) Map the TLS record direction, TLS record type, TLS record length and TLS record position to four-dimensional path points, and construct TLS record paths according to the parsing order of TLS records; form TLS record paths under different communication ranges through the overall window and multi-level local windows, calculate the first-order path signature features and second-order path signature features of each window respectively, and combine them in a preset order to form a 300-dimensional path signature feature representation.

[0087] The specific process for this step is as follows:

[0088] (3.1) Construct the TLS record path representation, for the first TLS record obtained in step (2.5) Each of the following is a valid TLS record, with its record direction, record type, record length, and record position recorded as follows: , , and And construct four-dimensional path points according to the following formula:

[0089]

[0090] Arrange the path points according to the parsing order of the TLS records to form the following TLS record path:

[0091]

[0092] in, ∈{+1,-1}, This represents the number of valid TLS records involved in path calculation in the current session. It is the natural logarithm.

[0093] (3.2) Construct a multi-level window path representation, set an overall window covering the complete TLS record path, and divide the valid TLS record path into two levels according to the proportion, forming two first-level local windows, four second-level local windows and eight third-level local windows in sequence, resulting in a total of 15 windows; the path points in each level of the window remain unchanged according to the original parsing order, and when there are fewer than two valid path points in a certain window, the path signature feature corresponding to that window is set to all zeros;

[0094] (3.3) Calculate the path change sequence for any window. Suppose that the window contains There are path points, and the window path is represented as:

[0095]

[0096] Calculate the path increment between adjacent path points sequentially, following the original parsing order of the path points within the window:

[0097]

[0098] (3.4) Extract path signature features. For any window w, its first-order path signature is calculated according to the following formula:

[0099]

[0100] When calculating the second-order path signature, the first-order path signature, the second-order path signature, and the prefix accumulator are first initialized:

[0101]

[0102] In the In the nth iteration, the th... The second-order interaction terms corresponding to each path increment:

[0103]

[0104] And update the second-order path signature and prefix accumulation in sequence:

[0105]

[0106]

[0107] in, This represents the outer product of vectors. After traversing all path increments, the 4-dimensional first-order path signature and 16-dimensional second-order path signature corresponding to each window are expanded and concatenated in the order of global window, first-level local window, second-level local window, and third-level local window to form a 300-dimensional path signature feature representation.

[0108] like Figure 2 As shown, the first-order path signature calculation process first inputs the path point sequence and calculates the increments of adjacent path points, then sequentially accumulates each path increment to... The second-order path signature calculation process, based on the same path increment, utilizes the accumulated prefix amount before the current increment. Interaction item with current incremental calculation And the interaction items are accumulated sequentially to .

[0109] (4) Use the training samples and their path signature features in the labeled traffic dataset to train the hidden vulnerability exploitation traffic identification model, and input the path signature features corresponding to the test samples and the network traffic to be detected into the identification model, and output the identification result of whether the network traffic to be detected is the hidden vulnerability exploitation traffic.

[0110] The specific process for this step is as follows:

[0111] (4.1) Use the path signature feature representation and its label corresponding to the training sample to construct training samples, train the hidden vulnerability traffic identification model, the identification model is LightGBM, set the number of decision trees to 350, the learning rate to 0.035, the number of leaf nodes to 15, the minimum number of samples for a single leaf node to 5, the sample sampling ratio and the feature sampling ratio to 0.9, and set the class balance weight.

[0112] (4.2) Input the hidden vulnerability exploitation traffic, browsing benign traffic and twin benign traffic in the test sample into the trained identification model, and verify the identification ability of the model under different traffic scenarios;

[0113] (4.3) The identification model outputs the identification result of whether the network traffic to be detected belongs to the hidden vulnerability exploit traffic or normal access traffic;

[0114] (4.4) To verify the impact of the TLS record count setting on the recognition effect, tests were conducted with the TLS record count set to 4, 8, 12, 16, 20, 24, 28, and 32 respectively. The test results are as follows: Figure 3 As shown. The comparison results show that the model performs best in all performance indicators when the number of TLS records is 24. Therefore, 24 is selected as the preferred number of TLS records in this invention.

[0115] (4.5) To verify the effectiveness of the multi-window path signature feature construction method proposed in this invention, three encrypted malicious traffic detection methods—TLS-MHSA, ADRSA, and DC-GL—were selected as comparison methods, and the output categories of each method were uniformly set to covert vulnerability exploitation traffic and normal access traffic. Under the same training samples, test samples, and data partitioning methods, the precision, recall, Macro-F1, and false positive rates of each method were compared in both benign traffic browsing scenarios and twin benign traffic scenarios. The results are as follows: Figure 4 As shown, in the scenario of browsing benign traffic, the precision, recall, and Macro-F1 of this invention reached 97.94%, 96.67%, and 97.99%, respectively, with a false positive rate of 1.002%. In the scenario of twinned benign traffic, the precision, recall, and Macro-F1 of this invention reached 95.16%, 94.24%, and 95.39%, respectively, with a false positive rate of 3.566%. The comparison results show that this invention can maintain a high detection capability for exploit traffic and a low false positive rate for normal access traffic in both benign traffic scenarios, especially demonstrating good distinguishing ability for twinned benign traffic that has a high structural similarity to exploit traffic.

[0116] The technical means disclosed in this invention are not limited to those disclosed in the above embodiments, but also include technical solutions composed of any combination of the above technical features. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications are also considered within the scope of protection of this invention.

Claims

1. A method for identifying covert vulnerability exploit traffic based on path signatures, characterized in that, Includes the following steps: (1) Construction of labeled traffic dataset: Deploy multiple vulnerability service environments, collect hidden vulnerability exploitation traffic, browsing benign traffic and twin benign traffic respectively, and uniformly label, organize and sample the collected traffic to obtain labeled traffic dataset for model training and testing; (2) Constructing TLS record-level traffic sequences: The labeled traffic dataset and the network traffic to be detected are reassembled into groups and transport layer payloads according to the five-tuples. The reassembled TLS records are parsed to extract the TLS record direction, TLS record type, TLS record length and TLS record position, and the TLS record-level traffic sequences are constructed according to the parsing order of the TLS records. (3) Multi-window path signature feature extraction: the TLS record direction, TLS record type, TLS record length and TLS record position are mapped to four-dimensional path points, and the TLS record path is constructed according to the parsing order of the TLS record; TLS record paths under different communication ranges are formed through the overall window and multi-level local windows, and the first-order path signature features and second-order path signature features of each window are calculated respectively, and combined in a preset order to form a path signature feature representation; (4) Identification model training and detection: Use the path signature feature representation corresponding to the training sample to train the hidden vulnerability exploitation traffic identification model; Perform the same TLS record-level traffic sequence construction and multi-window path signature feature extraction on the network traffic to be detected, input the obtained path signature feature representation into the trained identification model, and determine whether the network traffic to be detected belongs to the hidden vulnerability exploitation traffic based on the identification score and judgment threshold output by the model.

2. The method for identifying covert vulnerability exploitation traffic based on path signatures according to claim 1, characterized in that, Step (1) specifically includes the following sub-steps: (1.1) Build a network environment that includes vulnerability services, configure the client, encrypted communication link and target vulnerability server to generate hidden vulnerability exploit traffic and normal access traffic; (1.2) Execute a vulnerability exploitation request on the target vulnerability server and collect the encrypted network traffic generated during the vulnerability exploitation process; (1.3) Execute normal business access requests for the target vulnerability server, collect the encrypted network traffic generated during the normal access process, and distinguish and mark it with the encrypted network traffic of the vulnerability. (1.4) Collected encrypted network traffic for vulnerability exploitation and normal access encrypted network traffic are uniformly sorted, labeled and sampled to construct a labeled traffic dataset containing hidden vulnerability exploitation traffic and normal access traffic; (1.5) Divide the labeled traffic dataset into a training sample set and a test sample set for subsequent path signature feature extraction, model training and traffic identification verification.

3. The method for identifying covert vulnerability exploitation traffic based on path signatures according to claim 2, characterized in that, Both the exploited encrypted network traffic and the normal access to the encrypted network traffic are encrypted traffic transmitted based on the TLS protocol. The encrypted network traffic for vulnerability exploitation includes attack traffic generated by executing vulnerability exploitation requests against different vulnerability service environments, while the encrypted network traffic for normal access includes normal traffic generated by executing normal business access requests against the same or corresponding vulnerability service environments, in order to form covert vulnerability exploitation samples and normal access samples with a comparative relationship.

4. The method for identifying covert vulnerability exploitation traffic based on path signatures according to claim 1, characterized in that, Step (2) specifically includes the following sub-steps: (2.1) The original encrypted network traffic in the labeled traffic dataset and the network traffic to be detected is grouped into streams according to the five-tuple information, which includes the source IP address, destination IP address, source port, destination port and transport layer protocol, to obtain multiple independent network session streams; (2.2) For each network session stream, according to the data transmission direction between the client and the server, the transport layer payload in the network session stream is marked with a direction to obtain the encrypted payload streams from the client to the server and from the server to the client. (2.3) Reassemble the transport layer loads in the client-to-server direction and the server-to-client direction respectively, and remove duplicate load segments to obtain the encrypted load byte streams in the corresponding directions; (2.4) Parse the encrypted payload byte stream according to the TLS record format, extract the TLS record direction, TLS record type and TLS record length corresponding to each TLS record, and generate the TLS record position according to the parsing order of the TLS records; (2.5) Arrange the TLS record direction, TLS record type, TLS record length and TLS record position according to the order in which the TLS records appear in the network session stream, and truncate or supplement them according to the preset number of records to construct a TLS record-level traffic sequence with consistent length.

5. The method for identifying covert vulnerability exploitation traffic based on path signatures according to claim 1, characterized in that, Step (3) specifically includes the following sub-steps: (3.1) Construct the TLS record path representation, for the first TLS record obtained in step (2.5) Each of the following is a valid TLS record, with its record direction, record type, record length, and record position as follows: , , and And construct four-dimensional path points according to the following formula: Arrange the path points according to the parsing order of the TLS records to form the following TLS record path: in, ∈{+1,-1}, This represents the number of valid TLS records involved in path calculation in the current session. It is the natural logarithm. (3.2) Construct a multi-level window path representation, set an overall window covering the complete TLS record path, and divide the valid TLS record path into two levels according to the proportion, forming two first-level local windows, four second-level local windows and eight third-level local windows in sequence, resulting in a total of 15 windows; the path points in each level of the window remain unchanged according to the original parsing order, and when there are fewer than two valid path points in a certain window, the path signature feature corresponding to that window is set to all zeros; (3.3) Calculate the path change sequence for any window. Suppose that the window contains There are path points, and the window path is represented as: Calculate the path increment between adjacent path points sequentially, following the original parsing order of the path points within the window: (3.4) Extract path signature features for any window Its first-order path signature is calculated according to the following formula: When calculating the second-order path signature, the first-order path signature, the second-order path signature, and the prefix accumulator are first initialized: In the In the nth iteration, the th... The second-order interaction terms corresponding to each path increment: And update the second-order path signature and prefix accumulation in sequence: in, The vector outer product is represented by the following: after traversing all path increments, the 4-dimensional first-order path signature and 16-dimensional second-order path signature corresponding to each window are expanded and concatenated in the order of global window, first-level local window, second-level local window and third-level local window to form a 300-dimensional path signature feature representation.

6. The method for identifying covert vulnerability exploitation traffic based on path signatures according to claim 5, characterized in that, The preset window includes one overall window, two first-level local windows, four second-level local windows, and eight third-level local windows. The first-order path signature corresponding to each window is a 4-dimensional vector, which is used to represent the overall change of each dimension of the TLS record path within the corresponding window. The second-order path signature is a 4×4 matrix, which is expanded into a 16-dimensional vector by rows, and is used to represent the sequential interaction relationship between the changes of different path dimensions. The path signatures corresponding to the 15 windows are concatenated in a preset order to obtain a 300-dimensional path signature feature representation.

7. The method for identifying covert vulnerability exploitation traffic based on path signature according to claim 1, characterized in that, Step (4) specifically includes the following sub-steps: (4.1) The training sample set is constructed by taking the 300-dimensional path signature feature representation corresponding to the training sample as input and the sample as belonging to the hidden vulnerability exploit traffic or normal access traffic as label, and the LightGBM hidden vulnerability exploit traffic identification model is trained by class balanced weight. (4.2) Perform hierarchical five-fold cross-validation according to the vulnerability service environment and traffic category; use three-fold validation inside each outer training fold to obtain the prediction score of the training sample, and select the threshold that maximizes Macro-F1 within the candidate threshold range of 0.05 to 0.95 as the judgment threshold of the outer fold, so that the recognition model learns the correspondence between the path signature features and the traffic category; (4.3) Perform the same grouping, transport layer load reassembly, TLS record parsing, four-dimensional path construction, multi-window partitioning, and first- and second-order path signature calculations on the network traffic to be detected as steps (2) and (3) to obtain the 300-dimensional path signature feature representation of the network traffic to be detected. (4.4) Input the path signature feature representation corresponding to the network traffic to be detected into the trained covert vulnerability exploitation traffic identification model to obtain the identification score of its belonging to covert vulnerability exploitation traffic. ,when Greater than or equal to the judgment threshold At that time, the network traffic to be detected is judged as traffic exploiting hidden vulnerabilities; otherwise, it is judged as normal access traffic. The value range of is [0,1]. The threshold value is the one determined in step (4.2).

8. The method for identifying covert vulnerability exploitation traffic based on path signatures according to claim 7, characterized in that, The hidden vulnerability exploitation traffic identification model outputs the identification score corresponding to the network traffic to be detected based on the input path signature features, and determines whether the network traffic to be detected belongs to the hidden vulnerability exploitation traffic according to the preset judgment threshold.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the path signature-based method for identifying covert vulnerability exploit traffic as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, the computer instruction implements the path signature-based stealth exploit traffic identification method as described in any one of claims 1-8.

Images