Methods, devices, and computer equipment for detecting the threat level of encrypted traffic.

Abstract

This application discloses a method, apparatus, and computer device for detecting the threat level of encrypted traffic. The method includes: acquiring a traffic mirror of the entire traffic flow and reconstructing the traffic mirror to obtain reconstructed traffic, wherein the traffic mirror contains encrypted traffic; decrypting the reconstructed traffic using a multi-dimensional decryption method to obtain plaintext traffic, the multi-dimensional decryption method including at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption / decryption algorithm; detecting the plaintext traffic using multiple methods to obtain multiple detection results, fusing the multiple detection results to obtain a final detection result, the detection result being used to indicate the threat level of the traffic. This application solves the technical problem of low accuracy in detecting the threat level of encrypted traffic in related technologies.

Description

Technical Field

[0001] This application relates to the field of network security technology, and more specifically, to a method, apparatus, and computer device for detecting the threat level of encrypted traffic. Background Technology

[0002] With the widespread application of encryption technology, network traffic is becoming increasingly encrypted, posing a significant challenge to network security. Traditional security devices based on plaintext analysis struggle to cope with threats within encrypted traffic. Malware and attackers are increasingly hiding their attacks within encrypted communications to evade detection. Existing technologies suffer from the following shortcomings: most security devices cannot decrypt and analyze encrypted traffic, resulting in detection blind spots. Rule-based and signature-based detection methods struggle to adapt to constantly evolving attack methods. There is a lack of effective threat intelligence and attribution analysis tools, making it impossible to trace and locate the source of threats. Detection models are slowly updated and iterated, making it difficult to quickly respond to new threats. Summary of the Invention

[0003] This application provides a method, apparatus, and computer device for detecting the threat level of encrypted traffic, so as to at least solve the technical problem of low accuracy in detecting the threat level of encrypted traffic in related technologies.

[0004] According to one aspect of the embodiments of this application, a method for detecting the threat level of encrypted traffic is provided, comprising: acquiring a traffic mirror of the full traffic and performing session reassembly on the traffic mirror to obtain reassembled traffic, wherein the traffic mirror contains encrypted traffic; decrypting the reassembled traffic using a multi-dimensional decryption method to obtain plaintext traffic, wherein the multi-dimensional decryption method includes at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption and decryption algorithm; detecting the plaintext traffic using multiple methods to obtain multiple detection results, fusing the multiple detection results to obtain a final detection result, wherein the detection result is used to indicate the threat level of the traffic.

[0005] Optionally, a multi-dimensional decryption method is used to decrypt the reconstructed traffic to obtain plaintext traffic, including: when the multi-dimensional decryption method uses certificate decryption, extracting the encryption key suite of the reconstructed traffic; obtaining the private key corresponding to the reconstructed traffic through the certificate corresponding to the reconstructed traffic, decrypting the encryption key suite to obtain the symmetric encryption key for subsequent communication; decrypting the reconstructed traffic based on the symmetric encryption key to obtain plaintext traffic; if a certificate update is detected for the reconstructed traffic, updating the private key corresponding to the reconstructed traffic; if the session corresponding to the reconstructed traffic belongs to the certificate before the update, decrypting with the private key before the update is used until the session belonging to the certificate before the update ends; after the session belonging to the certificate before the update ends, all sessions corresponding to the reconstructed traffic are decrypted with the updated private key.

[0006] Optionally, at least one method is selected from multiple methods to detect plaintext traffic and obtain detection results. The multiple methods include rule detection, fingerprint detection, and model detection. Rule detection includes matching the features of plaintext traffic with a set of rules in a preset detection rule library. Fingerprint detection includes comparing the fingerprint information of plaintext traffic with the fingerprint information in a preset fingerprint library. Model detection includes using a pre-trained model to identify the features of plaintext traffic.

[0007] Optionally, at least one method is selected from multiple methods to detect plaintext traffic and obtain detection results, including: when using the rule-based detection method, restoring the plaintext traffic to plaintext data; matching the features of the plaintext data with a rule set in a preset detection rule base; if the features of the plaintext data match any rule in the rule set, determining that the plaintext traffic corresponding to the plaintext data is threatening traffic, wherein any rule in the rule set is used to represent the features of threatening traffic; if the features of the plaintext data are the same as the features of threatening traffic, determining that the features of the plaintext data match a rule in the rule set; when using fingerprint detection, obtaining the plaintext traffic's... Fingerprint information is used to characterize the features obtained during the handshake between the server and the client. The similarity between the fingerprint information and fingerprints in a pre-set fingerprint database is calculated. If the similarity exceeds a pre-set similarity threshold, the plaintext traffic corresponding to the fingerprint information is determined to be threatening traffic. When model detection is used, the traffic statistics of the plaintext traffic are obtained as input to a pre-trained model, and the output of the pre-trained model is obtained. The output of the pre-trained model includes a threat level score for the plaintext traffic. The statistical features of the plaintext traffic include at least the request method, URI length, and number of parameters. Based on the output of the pre-trained model, it is determined whether the plaintext traffic is threatening traffic.

[0008] Optionally, the method further includes: acquiring honeypot data, which includes various attack traffic data; extracting multi-dimensional features of traffic attack behavior from the various attack traffic data, which include network layer features, host layer features, and application layer features, wherein the network layer features include at least the source IP, port, and protocol of the attack traffic, the host layer features include at least the attacker's system operation information and file read / write information, and the application layer features include at least the URL parameters of the network attack and the SQL injection statements of the network attack; constructing a honeypot model based on the multi-dimensional features of traffic attack behavior, and using the honeypot model to analyze plaintext traffic to obtain initial detection results, and inputting the initial detection results into a pre-trained model to output detection results.

[0009] Optionally, the method further includes: acquiring a source code corpus and segmenting the source code in the source code corpus into token sequences; compiling the source code in the source code corpus into an intermediate representation; constructing a control flow graph of the program based on the intermediate representation; extracting features from the token sequences and the control flow graph of the program to obtain source code sequence features and program structure graph features; training a vulnerability detection model based on the source code sequence features and program structure graph features, and using the vulnerability detection model to detect vulnerabilities in the server system.

[0010] Optionally, multiple methods are used to detect plaintext traffic, resulting in multiple detection results. These include: extracting multi-dimensional features from the plaintext traffic, where the multi-dimensional features include at least: network layer features, application layer features, content features, and behavioral features. Network layer features include at least: IP address, port, and protocol type; application layer features include at least: HTTP header information and TLS handshake parameters; content features include at least: keywords and byte distribution in the payload; and behavioral features include at least: connection duration and data transmission mode. At least one method is selected from these multiple methods to detect the multi-dimensional features, resulting in detection results. These multiple methods include: rule detection, fingerprint detection, and model detection. Rule detection includes: matching the multi-dimensional features with a rule set in a preset detection rule base; fingerprint detection includes: comparing the fingerprint information of the plaintext traffic with the fingerprint information in a preset fingerprint base; and model detection includes: using a pre-trained model to identify the multi-dimensional features.

[0011] Optionally, multiple detection results are fused to obtain a final detection result, which is used to indicate the threat level of the traffic. This includes: obtaining threat level scores indicated by multiple detection results; obtaining the weight corresponding to each detection result; and determining the final detection result based on the weight corresponding to each detection result and the threat level score indicated by each detection result.

[0012] Optionally, multiple detection results can be fused to obtain the final detection result, including: obtaining different characteristics of plaintext traffic for each detection result; and determining the traffic type of traffic mirroring based on the different characteristics of plaintext traffic.

[0013] According to another aspect of the embodiments of this application, a device for detecting the threat level of encrypted traffic is also provided, comprising: an acquisition module, configured to acquire a traffic mirror of the full traffic and perform session reassembly on the traffic mirror to obtain reassembled traffic, wherein the traffic mirror contains encrypted traffic; a decryption module, configured to decrypt the reassembled traffic using a multi-dimensional decryption method to obtain plaintext traffic, wherein the multi-dimensional decryption method includes at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption and decryption algorithm; and a detection module, configured to detect the plaintext traffic using multiple methods to obtain multiple detection results, and fuse the multiple detection results to obtain a final detection result, wherein the detection result is used to indicate the threat level of the traffic.

[0014] According to another aspect of the embodiments of this application, a computer device is also provided, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor, connected to the memory, is used to execute the above-described method for detecting the degree of threat of encrypted traffic.

[0015] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-mentioned method for detecting the degree of threat of encrypted traffic by running the computer program.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described method for detecting the degree of threat of encrypted traffic.

[0017] In this embodiment, a traffic mirror of the entire traffic is obtained, and session reassembly is performed on the traffic mirror to obtain reconstructed traffic, wherein the traffic mirror contains encrypted traffic; the reconstructed traffic is decrypted using a multi-dimensional decryption method to obtain plaintext traffic, the multi-dimensional decryption method including at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption and decryption algorithm; multiple methods are used to detect the plaintext traffic to obtain multiple detection results, and the multiple detection results are fused to obtain a final detection result, which is used to indicate the threat level of the traffic, thereby achieving the purpose of decrypting the encrypted traffic before detection, thus achieving the technical effect of improving the accuracy of encrypted traffic threat level detection, and thus solving the technical problem of low detection accuracy of encrypted traffic threat level in related technologies. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing a method for detecting the threat level of encrypted traffic according to an embodiment of this application;

[0020] Figure 2 This is a flowchart of a method for detecting the threat level of encrypted traffic according to an embodiment of this application;

[0021] Figure 3 This is a structural diagram of a device for detecting the threat level of encrypted traffic according to an embodiment of this application. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] The information collected in this application embodiment is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, and necessary confidentiality measures have been taken. It does not violate public order and good morals, and provides corresponding operation entry points for users to choose to authorize or reject the automated decision results. If the user chooses to reject, the process will proceed to the expert decision-making process.

[0025] To address the problems existing in related technologies, embodiments of this application provide a method for detecting the threat level of encrypted traffic. This method can be run on... Figure 1 The computer terminal shown is explained below.

[0026] The method for detecting the threat level of encrypted traffic provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a method to detect the threat level of encrypted traffic is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0027] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be implemented wholly or partially as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be wholly or partially integrated into any other element in the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0028] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the encrypted traffic threat level detection method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned encrypted traffic threat level detection method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0029] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0030] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0031] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0032] In the above operating environment, this application provides an embodiment of a method for detecting the threat level of encrypted traffic. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] Figure 2 This is a flowchart of a method for detecting the threat level of encrypted traffic according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0034] Step S202: Obtain the traffic mirror of the full traffic and perform session reassembly on the traffic mirror to obtain reassembled traffic, wherein the traffic mirror contains encrypted traffic;

[0035] In step S202, the specific steps for full traffic mirroring and access are as follows:

[0036] Step 1.1: Deploy a traffic mirroring device at the network egress point to replicate all traffic in real time.

[0037] Step 1.1.1: Select a suitable traffic mirroring solution, such as TAP (Test Access Point) or SPAN (Switch Port Analyzer).

[0038] Among them, the TAP solution deploys physical optical splitting devices in parallel on the network link to replicate bidirectional traffic without loss; the SPAN solution forwards traffic from a specified port to a mirror port through a switch mirror port.

[0039] Understandably, mirroring devices need to support preset throughput to ensure that the mirrored traffic is consistent with the original traffic and that there is no packet loss. The preset throughput should meet the needs of peak network periods, for example, no less than 10Gbps. Mirroring devices also need to have traffic caching capabilities to cope with sudden traffic surges.

[0040] Step 1.1.2: Deploy redundant mirror devices to avoid single points of failure affecting data acquisition.

[0041] It should be noted that when deploying redundant mirror devices, high availability solutions such as primary / standby and load balancing can be adopted. Automatic failover and alarm mechanisms should be configured.

[0042] Step 1.2: Transmit the traffic mirror to the threat detection and tracing system (a system for performing the methods provided in the embodiments of this application) through a dedicated secure channel.

[0043] Step 1.2.1: Plan the transmission network for traffic mirroring to ensure that bandwidth and latency meet the requirements.

[0044] The transmission network should be independent of the service network to avoid affecting normal business operations. The transmission network bandwidth should not be lower than a preset value, such as 40Gbps, and should support linear expansion. The network latency should be less than a preset latency, such as 1ms, to ensure data real-time performance.

[0045] Step 1.2.2: Traffic mirroring must be transmitted with encryption throughout the process to prevent data leakage and tampering.

[0046] There are various encryption algorithms used for encrypted transmission, such as IPSec (Internet Protocol Security) and MACsec (Media Access Control security).

[0047] Server-grade encryption devices are used during the encryption process to ensure sufficient encryption processing performance.

[0048] Step 1.2.3: Reassemble the incoming traffic mirroring session for subsequent protocol parsing.

[0049] Reconstructed traffic is obtained by reassembling the data based on the five-tuple information (source IP, source port, destination IP, destination port, protocol) of the traffic mirroring.

[0050] By following the steps above, a highly efficient, reliable, secure, and real-time full-traffic mirroring access solution can be built. This forms the data foundation for the threat detection system and is a prerequisite for subsequent detection work. Furthermore, this solution can be reused in other scenarios such as network performance monitoring and fault diagnosis, improving the overall network operation and maintenance level. Additionally, by utilizing a large-capacity cache, it ensures that stateless UDP packets can be correctly reassembled.

[0051] Step S204: Decrypt the reconstructed traffic using a multi-dimensional decryption method to obtain plaintext traffic. The multi-dimensional decryption method includes at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption and decryption algorithm.

[0052] In step S204, the multi-dimensional decryption methods include: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption and decryption algorithm. The decryption algorithm library is used to decrypt in real time the traffic encrypted with TLS (Transport Layer Security) and SSL (Secure Sockets Layer) in the encrypted traffic.

[0053] The server-side private key is obtained and updated using a certificate, and then the private key is used to decrypt encrypted traffic.

[0054] Decrypt encrypted traffic using standard encryption and decryption algorithms.

[0055] Step S206: Plaintext traffic is detected using multiple methods to obtain multiple detection results. These multiple detection results are then fused to obtain the final detection result, which is used to indicate the threat level of the traffic.

[0056] Through steps S202 to S206 above, a traffic mirror of the entire traffic is obtained, and session reassembly is performed on the traffic mirror to obtain reconstructed traffic, wherein the traffic mirror contains encrypted traffic; the reconstructed traffic is decrypted using a multi-dimensional decryption method to obtain plaintext traffic. The multi-dimensional decryption method includes at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption / decryption algorithm; multiple methods are used to detect the plaintext traffic, resulting in multiple detection results, which are then fused to obtain the final detection result. The detection result is used to indicate the threat level of the traffic, thereby achieving the goal of decrypting the encrypted traffic before detection, thus improving the technical effect of improving the accuracy of encrypted traffic threat level detection, and solving the technical problem of low detection accuracy of encrypted traffic threat level in related technologies. The following is a detailed explanation.

[0057] In the technical solution provided by step S204 of the above-mentioned method for detecting the threat level of encrypted traffic, a multi-dimensional decryption method is used to decrypt the reconstructed traffic to obtain plaintext traffic. This includes: when the multi-dimensional decryption method uses a certificate for decryption, extracting the encryption key suite of the reconstructed traffic; obtaining the private key corresponding to the reconstructed traffic through the certificate corresponding to the reconstructed traffic, decrypting the encryption key suite to obtain the symmetric encryption key for subsequent communication; decrypting the reconstructed traffic based on the symmetric encryption key to obtain plaintext traffic; when a certificate update is detected for the reconstructed traffic, updating the private key corresponding to the reconstructed traffic; when the session corresponding to the reconstructed traffic belongs to the certificate before the update, decrypting it using the private key before the update, until the session belonging to the certificate before the update ends; after the session belonging to the certificate before the update ends, all sessions corresponding to the reconstructed traffic are decrypted using the updated private key.

[0058] Specifically, decryption can be performed using a certificate through the following steps:

[0059] Step 1: Obtain and update the server's private key to ensure decryption capability.

[0060] Step 1.1: Deploy a certificate management system to centrally manage all SSL / TLS certificates within the organization.

[0061] The certificate management system can use a mature certificate management platform, such as Venafi or OpenCA.

[0062] Role-based access control (RBAC) strictly restricts access to private keys and reduces the risk of certificate misconfiguration and expiration through centralized management.

[0063] Step 2: Configure the traffic decryption module to interface with the certificate management system and synchronize certificate information.

[0064] Specifically, the certificate management system's API interface allows for real-time querying of certificates used by business systems; synchronization of metadata information such as public keys, private keys, and validity periods; and encryption and storage of sensitive information such as private keys to ensure security.

[0065] Step 3: The decryption module dynamically decrypts TLS traffic based on the synchronized certificate private key.

[0066] Specifically, extract the encryption key suite, such as SessionKey, from the TLS traffic; decrypt the encryption key suite using the private key to obtain the symmetric encryption key for subsequent communication; and decrypt the application layer data in the TLS session based on the symmetric key.

[0067] Step 4: When the certificate changes, the decryption module automatically updates the private key information to ensure uninterrupted decryption.

[0068] The specific update steps are as follows: When the business system certificate is changed, the certificate management system sends a change notification; the decryption module retrieves the new certificate private key from the certificate management system; the new private key is smoothly switched to decrypt the newly established connection.

[0069] To explain the certificate renewal process more clearly, the following example illustrates it:

[0070] To ensure the security of HTTPS (Hypertext Transfer Protocol Secure) services, e-commerce platforms frequently change SSL certificates. In the event of a certificate change, follow these steps to complete the business transition:

[0071] Step 1: The e-commerce platform imports the newly applied certificate into the certificate management system, and after approval, it is automatically pushed to the business server.

[0072] Step 2: Subscribe to certificate changes and obtain the new certificate metadata from the certificate management system API.

[0073] Step 3: When the certificate becomes effective, the decryption system automatically updates the private key information and switches to using the new private key for decryption.

[0074] Step 4: For sessions with old certificates, the decryption system continues to use the old private key until the session ends.

[0075] Step 5: After the new certificate is fully effective, all new connections will be decrypted using the new private key to ensure a smooth business transition.

[0076] By integrating with the certificate management system, the traffic decryption system can adapt to changes in business certificates, continuously and efficiently decrypting SSL traffic. This solution avoids the risks of omissions associated with manual configuration and improves decryption reliability. Simultaneously, by encrypting and protecting sensitive information such as private keys, it prevents unauthorized use of certificates and minimizes security risks.

[0077] In some embodiments of this application, the specific steps for detecting plaintext traffic using multiple methods to obtain multiple detection results are as follows: at least one method is selected from multiple methods to detect plaintext traffic and a detection result is obtained. The multiple methods include rule detection, fingerprint detection, and model detection. Rule detection includes matching the features of plaintext traffic with a rule set in a preset detection rule library. Fingerprint detection includes comparing the fingerprint information of plaintext traffic with the fingerprint information in a preset fingerprint library. Model detection includes using a pre-trained model to identify the features of plaintext traffic.

[0078] In the case of using the rule-based detection method, plaintext traffic is restored to plaintext data; the features of the plaintext data are matched with the rule set in the preset detection rule base; if the features of the plaintext data match any rule in the rule set, the plaintext traffic corresponding to the plaintext data is determined to be threatening traffic. Here, any rule in the rule set is used to represent the features of threatening traffic. If the features of the plaintext data are the same as the features of threatening traffic, it is determined that the features of the plaintext data match the rules in the rule set.

[0079] Specifically, the rule-based detection engine is deployed, and the specific detection process is as follows:

[0080] Step 1: Deploy a built-in detection rule base containing 150+ common encryption attack tools.

[0081] Step 2: Based on the decrypted plaintext traffic, perform multi-mode rule matching analysis. The rule engine supports flexible customization and allows for the rapid addition of new detection rules.

[0082] Taking Cobalt Strike (CS) attack detection as an example, this article details the workflow of a rule-based detection engine.

[0083] It should be noted that Cobalt Strike is a common commercial penetration testing tool, but it is also frequently abused by hackers in actual attacks. Its communication is primarily encrypted, making it difficult to detect using traditional methods.

[0084] Step 1: Deploy a rule base for detecting common encryption attack tools, including:

[0085] To obtain Cobalt Strike's communication protocol and behavioral characteristics, CS uses SSL encrypted communication by default, and the port is usually 443, 8443, etc.; CS beacon communication uses the HTTP protocol; the URI structure has certain patterns.

[0086] For example, extract keywords from CS traffic such as "30820", "2d2d2d2d", " / jquery-3.3.1.min.js", etc.

[0087] Step 2: Formulate detection rules based on features to create a CS rule base.

[0088] The rule syntax can adopt mature formats such as Snort and Suricata, for example:

[0089] alert tcp any any->any$HTTP_PORTS(msg:"Suspected Cobalt StrikeBeacon";

[0090] ssl_version: tls1.2; content: " / jquery-3.3.1.min.js"; sid: 100001; indicates that: it identifies possible Cobalt Strike Beacon activity by detecting specific encrypted HTTP traffic (especially URLs using TLS 1.2 and containing " / jquery-3.3.1.min.js"). When matching traffic is detected, it will issue an alert to help security personnel discover and respond to potential network threats in a timely manner.

[0091] Based on threat intelligence, supplement information such as the IP addresses and domain names of other known client-server (CS) servers.

[0092] Step 3: Based on the decrypted plaintext traffic, perform multi-pattern rule matching analysis, including: restoring the decrypted traffic to plaintext data to extract HTTP protocol request headers and message body data; URL decoding the request parameters to restore the original data content. Input the plaintext traffic into the rule engine for multi-pattern matching.

[0093] Specifically, by using multi-pattern matching algorithms such as AC automata and Wu-Manber, efficient matching is achieved. When traffic successfully matches any rule in the rule set, an alarm is triggered.

[0094] It should be noted that the AC automaton can construct a pattern tree to search for multiple feature strings simultaneously, while the Wu-Manber algorithm can search for multiple different patterns in the text without multiple scans.

[0095] It should also be noted that the rules engine supports flexible customization and allows for the rapid addition of new detection rules.

[0096] Specifically, follow up on Cobalt Strike updates and extract the communication characteristics of the new versions. For example, CS 4.0 uses a new Beacon configuration file syntax. Pay attention to urgent vulnerability alerts and analyze changes in the CS attack chain. Iterate the rule base based on new characteristics to maintain the effectiveness of detection rules. Rule definitions follow standard formats to ensure rule quality and maintainability.

[0097] It's important to note that new rules have undergone thorough testing to control false positive rates. The rule base supports hot updates, eliminating the need to restart the detection engine. Updated rules take effect immediately, detecting new threat variants as soon as possible.

[0098] To better understand the rule detection process, the following example will further explain it.

[0099] A large amount of suspicious encrypted traffic suddenly appeared on the internal network of an organization. Analysis revealed that multiple hosts were continuously initiating SSL connections to overseas IPs.

[0100] 1. By decrypting the traffic, the plaintext of the SSL traffic was restored, revealing that it was HTTP traffic.

[0101] 2. The rule engine matches the URI characteristics of Cobalt Strike, such as " / jquery-3.3.1.min.js".

[0102] 3. It was determined to be a Cobalt Strike botnet, and the C&C server was identified through IP intelligence from the rule base.

[0103] 4. Quickly isolate the victim host and block C&C communication to prevent the attack from escalating.

[0104] 5. Follow up on the latest CS variants, extract targeted detection rules, and add them to the rule engine.

[0105] With a built-in massive attack tool rule library and support for flexible customization of new rules, the rule detection engine can continuously discover various covert attacks in encrypted traffic, leaving attackers nowhere to hide. At the same time, the rule engine employs a highly efficient multi-pattern matching mechanism, enabling real-time detection without impacting business operations, providing a solid guarantee for the performance and efficiency of the entire detection system.

[0106] When fingerprint detection is used, fingerprint information of plaintext traffic is obtained to characterize the feature information obtained during the handshake between the server and the client; the similarity between the fingerprint information and the fingerprint information in the preset fingerprint database is obtained, and if the similarity is higher than the preset similarity threshold, the plaintext traffic corresponding to the fingerprint information is determined to be threatening traffic.

[0107] The specific fingerprint detection process is as follows:

[0108] Step 1: Build a database of 300+ CS fingerprint features and extract TLS fingerprint information from encrypted traffic.

[0109] Step 2: Use fingerprint comparison algorithms to achieve fast and accurate identification of malware families.

[0110] Step 3: The fingerprint database supports automatic updates in the cloud to maintain the ability to identify new variant families.

[0111] Using the Cobalt Strike variant used by the APT41 group as an example, this article explains in detail the working principle of the fingerprint detection mechanism.

[0112] Step 1: Extract TLS fingerprint information from encrypted traffic using a database of 300+ CS fingerprint features, including:

[0113] Step 1.1: Collect various CS samples, including malicious traffic captured in the wild and honeypot system records.

[0114] Obtain CS variant samples used by organizations such as APT41.

[0115] By leveraging a globally deployed honeypot network, we proactively capture client-server traffic that impersonates legitimate businesses.

[0116] Step 1.2: Extract network behavior fingerprints from CS variants and construct a fingerprint database.

[0117] Specifically, the process involves collecting the client-server (CS) configuration files; running CS samples in a controlled environment using a sandbox system to extract the generated TLS fingerprints, such as cipher suites, compression methods, and extensions from the TLS client Hello; metadata information like the issuer and validity period of the SSL certificate; and semi-automatically optimizing the fingerprints to match different variants within the same family.

[0118] Step 2, utilizing fingerprint comparison algorithms to achieve fast and accurate identification of malware families, includes:

[0119] Step 2.1: After decrypting the traffic, extract its TLS fingerprint information.

[0120] It is understandable that fingerprint information of traffic can be extracted in two ways: one is to passively extract the TLS negotiation process from plaintext traffic; the other is to actively initiate a TLS request to obtain the fingerprint information returned by the server.

[0121] Step 2.2: Compare the extracted fingerprints with the feature database.

[0122] The specific comparison method is as follows: A similarity algorithm, such as the Jaccard coefficient, is used to calculate the fingerprint similarity. A one-to-many match is then performed with known family fingerprints in the feature database. If the similarity exceeds a similarity threshold, such as 90%, the fingerprint is identified as belonging to that malware family.

[0123] Step 3: The fingerprint database supports automatic cloud updates to maintain its ability to identify new variant families, including:

[0124] Step 3.1: Establish a cloud-based malware fingerprint management platform.

[0125] Understandably, the fingerprint cloud management platform aggregates fingerprint data from multiple organizations to achieve fingerprint sharing and joint defense. Member units can submit newly discovered fingerprints, which will be reviewed and confirmed by platform experts.

[0126] Step 3.2: The fingerprint database is automatically synchronized and updated in the cloud.

[0127] The endpoint detection device periodically pulls the latest fingerprint database from the cloud. The updated fingerprint database takes effect immediately and is applied to local traffic detection.

[0128] To better understand the rule detection process, the following example will further explain it.

[0129] A department is suspected of being targeted by an attack. The attacker used a client-server variant disguised as normal business traffic to evade traditional detection methods.

[0130] 1. After decryption and extraction of encrypted traffic, an abnormal TLS fingerprint was extracted:

[0131] The Client Hello uses an uncommon compression method, such as DEFLATE.

[0132] The server certificate contains a special CN field, which is inconsistent with legitimate business operations.

[0133] 2. The fingerprint detection mechanism quickly determines that the TLS fingerprint belongs to the Cobalt Strike variant family used by APT41 (Advanced Persistent Threat41, the codename for the Advanced Persistent Threat organization).

[0134] 3. The attack was determined to be a targeted penetration attack by APT41 against the department, and an early warning was issued in a timely manner.

[0135] 4. Submit the variant fingerprint to the cloud management platform, and after review, update it to the local fingerprint database of all members.

[0136] 5. Other organizations subsequently discovered similar TLS fingerprints, which promptly detected and blocked APT41's penetration activities.

[0137] In summary, fingerprint detection mechanisms are powerful tools for identifying advanced APT groups' Cobalt Strike variants and other crypto-malware. They can quickly compare and identify malware families; even if malware disguises its traffic, it cannot escape the keen eye of fingerprint comparison. Cloud-based collaborative defense of the fingerprint database further enhances the intelligence gathering and analysis capabilities of each member unit, significantly increasing the attack costs for APT groups. At the same time, this mechanism can be easily extended to the detection of other types of malware, showing broad application prospects.

[0138] When using model detection, the traffic statistics features of plaintext traffic are obtained as input to a pre-trained model, and the output of the pre-trained model is obtained. The output of the pre-trained model includes: a threat level score of plaintext traffic. The statistical features of plaintext traffic include at least: the request method of plaintext traffic, the URI length of plaintext traffic, and the number of parameters corresponding to plaintext traffic. Based on the output of the pre-trained model, it is determined whether the plaintext traffic is threatening traffic.

[0139] The specific methods for model detection are as follows:

[0140] Step 1: Train a traffic anomaly detection model using machine learning algorithms. This model includes, but is not limited to: a webshell (a website backdoor program) detection model based on LightGBM (a machine learning algorithm); a hidden tunnel detection model based on LOF; and a variant Trojan detection model based on ExtraTrees and AE.

[0141] Step 2: Extract traffic statistics features (such as packet size, duration, etc.) as model input.

[0142] Step 3: Output suspicious threat events and threat scores to identify high-risk traffic.

[0143] Taking the webshell detection model based on LightGBM as an example, this paper details the workflow of the model's detection capabilities.

[0144] It should be noted that Webshell is a type of malware commonly used by hackers. It achieves remote control through web scripts and is highly stealthy. Traditional signature-based detection methods are insufficient to detect various variants.

[0145] Step 1 involves training a traffic anomaly detection model using a machine learning algorithm, including:

[0146] Taking the LightGBM-based webshell detection model as an example,

[0147] Data preparation phase: Collect samples of common webshell families, such as China Chopper and Behinder; artificially construct webshell traffic disguised as normal business to enrich the diversity of samples; use expert knowledge and web crawling technology to label the malicious types of samples and form a training set.

[0148] Feature engineering phase: Extract statistical features of HTTP traffic, such as request method, URI length, number of parameters, etc.; extract N-Gram features of request content and capture webshell code snippets; use algorithms such as TF-IDF to weight the features.

[0149] Model training phase: The LightGBM algorithm is used to train the binary classification model; techniques such as grid search are used to optimize the model's hyperparameters and improve performance; and methods such as cross-validation are used to evaluate the model's generalization ability.

[0150] Step 2, extract traffic statistics features as model input, including:

[0151] Step 2.1: Extract key information about requests and responses from the decrypted HTTP traffic.

[0152] Specifically, extract the request's URI, headers, and body. Extract the response's status code, Server field, response length, and other metadata.

[0153] Step 2.2: Calculate the statistical characteristics of the request and response.

[0154] Specifically, it calculates the length, path depth, and number of parameters of the request URI; identifies suspicious keywords in the request, such as eval and base64_decode; calculates the frequency of HTML tags in the response; and extracts the entropy value of the response.

[0155] Step 3: Output suspicious threat events and threat scores to identify high-risk traffic.

[0156] Specifically, the extracted features are input into the trained LightGBM model; the model outputs a malicious probability for each request, serving as a threat score. A scoring threshold is set (e.g., 0.8), and requests exceeding the threshold are identified as webshells. Threat events are output, supplemented with threat intelligence. Multiple malicious requests from the same source IP are aggregated into a single threat event. External threat intelligence, such as IP reputation and C&C intelligence, is correlated to enrich the event information. Detailed event information is output, including: time, source IP, destination URL, attack type, etc.

[0157] During the training of the detection model, honeypot technology can be used to deploy an intelligent deception environment to attract and capture the malicious behavior of attackers, and the honeypot alerts can be actively analyzed through machine learning models to identify real threats.

[0158] Specifically, honeypot data is acquired, including various attack traffic data. Multi-dimensional features of attack behavior are extracted from this data, including network layer features, host layer features, and application layer features. Network layer features include at least the source IP, port, and protocol of the attack traffic; host layer features include at least the attacker's system operation information and file read / write information; and application layer features include at least the URL parameters and SQL injection statements of the network attack. A honeypot model is constructed based on these multi-dimensional features, and the model is used to analyze plaintext traffic to obtain initial detection results. These initial results are then input into a pre-trained model to output the final detection results.

[0159] Specifically, step A1 involves building a multi-layered intelligent honeypot platform, including:

[0160] Step A1.1: Deploy a low-interaction honeypot to simulate common network services and applications, such as SSH, RDP, HTTP, etc.

[0161] These honeypots can be deployed quickly and have a wide coverage area. They can effectively attract attack traffic, record attackers' initial behaviors such as scanning and brute-force attacks, and filter suspicious traffic.

[0162] Step A1.2 involves deploying high-interaction honeypots, providing a complete operating system and application environment. These honeypots are modeled after real systems and can deeply capture detailed attacker behavior. Through VPNs, tunnels, and other technologies, traffic from the high-interaction honeypots is redirected to a sandbox for easier behavioral analysis.

[0163] Step A1.3: Deploy intelligent decoys, such as artificially synthesized "decoy documents," at key nodes.

[0164] It should be noted that the decoy document contains embedded honey tags that can track abnormal actions such as opening and leaking the document. The decoy account can induce attackers to perform specific actions, actively revealing their attack intentions.

[0165] Step A2, constructing a multi-dimensional honeypot data analysis model, includes:

[0166] Step A2.1: Access multi-source heterogeneous honeypot data and extract multi-dimensional features of attack behavior.

[0167] Network layer characteristics: source IP, port, protocol, etc. of attack traffic.

[0168] Host-level characteristics: attacker's system operations, file reading and writing, etc.

[0169] Application layer characteristics: URL parameters and SQL injection statements used in web attacks.

[0170] Step A2.2: Utilize machine learning algorithms to construct a honeypot alarm analysis model.

[0171] In some embodiments of this application, unsupervised learning clustering algorithms, such as DBSCAN, can be used to mine attack clusters and discover new types of attacks. Supervised learning classification algorithms, such as SVM, can also be used to accurately identify attack types.

[0172] Step A2.3: The model is continuously trained and adaptively learned to improve the accuracy and robustness of detection.

[0173] The specific training process includes: analyzing typical attack logs, optimizing model features and hyperparameters, and regularly validating model performance by introducing adversarial examples to simulate the challenges the model faces.

[0174] Step A3, which automates the analysis and response to honeypot alerts, includes:

[0175] Step A3.1 involves inputting honeypot alerts into the machine learning model in real time to automatically identify real threats. This aggregates multi-dimensional abnormal behaviors of the same attacker, improving the confidence level of threat assessment. It also filters out harmless traffic alerts such as those from scanners, reducing alert fatigue.

[0176] Step A3.2: Automatically initiate the emergency response process based on the severity of the threat. This includes promptly notifying security personnel of high-risk threats for in-depth analysis and evidence collection. Activating protective equipment to block and isolate the malicious source, preventing further intrusion.

[0177] Step A3.3: Promptly feed the analysis results back to the honeypot platform to continuously evolve the deception environment.

[0178] Specifically, the distribution of honeypot resources is adjusted to entice attackers to focus on specific targets. Based on the attack methods, the behavior scripts of highly interactive honeypots are dynamically adjusted to extend the time attackers remain on the platform.

[0179] By combining honeypot technology with machine learning models, an intelligent and continuously evolving deception defense system can be constructed. Like a siren in mythology, it lures attackers with deceptive illusions, tricks them into revealing their true form, and then accurately identifies and proactively counters them. This deception defense model significantly enhances the ability to perceive unknown threats, shifting the focus of network attack and defense to proactive measures. Simultaneously, automated alarm analysis greatly improves security operation efficiency, enabling intelligent security operations through human-machine collaboration, and laying a solid foundation for achieving overall network security situational awareness.

[0180] In practical applications, while detecting encrypted traffic, it is also possible to detect system vulnerabilities in the server. Specifically, a vulnerability detection model can be built, and the specific construction method of the vulnerability detection model is as follows: obtain a source code corpus and segment the source code in the source code corpus into token sequences; compile the source code in the source code corpus into an intermediate representation; construct the control flow graph of the program based on the intermediate representation; extract features from the token sequences and the program's control flow graph respectively to obtain source code sequence features and program structure graph features; train the vulnerability detection model based on the source code sequence features and program structure graph features, and use the vulnerability detection model to detect vulnerabilities in the server system.

[0181] The specific implementation steps are as follows:

[0182] Step B1: Construct a multi-task sequence-to-sequence representation learning model from the source code;

[0183] Step B1 includes:

[0184] Step B1.1: Collect a large-scale source code corpus, covering various programming languages ​​and application scenarios. For example: crawl high-star projects from open-source communities such as GitHub and GitLab; crawl high-quality code solutions from programming competition platforms.

[0185] Step B1.2: Preprocess the source code, standardize the format, and extract the tokenized sequence of the source code.

[0186] Specifically, noise such as comments and whitespace characters is removed; the source code is segmented into token sequences using the lexical analyzer of the programming language.

[0187] Step B1.3: Train the language model of the source code based on sequence-to-sequence models such as Transformer.

[0188] Specifically, the Masked Language Modeling (MLM) task is used to predict the masked token; the Next Sentence Prediction (NSP) task is used to determine whether two code snippets are adjacent; the clone detection task is used to determine whether two code snippets are semantically similar; and multiple tasks are trained together to fully capture the semantic and structural features of the source code.

[0189] Step B2: Construct a graph neural network encoding model for the program control flow graph;

[0190] Step B2 includes:

[0191] Step B2.1: Compile the source code into an intermediate representation (IR) and extract the program's control flow graph (CFG).

[0192] Specifically, compiler frameworks such as LLVM are used to obtain the IR of the program; basic blocks and control flow edges are extracted from the IR to construct the CFG.

[0193] Step B2.2: Encode the CFG into a graph data structure and preprocess the features of the nodes and edges of the graph.

[0194] Specifically, node characteristics may include the instruction type and operands of the basic block; edge characteristics may include the type of control flow (sequence, branch, loop, etc.).

[0195] Step B2.3: Use graph neural networks such as graph convolutional networks (GCNs) to learn the embedding representation of CFG.

[0196] Specifically, the neighborhood information of nodes is aggregated through a message passing mechanism to update node embeddings; and the embedding vector of the entire CFG is generated through a pooling mechanism.

[0197] Graph Attention Networks (GAT) can be used, assigning different attention weights to different edges.

[0198] Step B3: Integrate source code sequence features and program structure graph features to train an end-to-end vulnerability detection model.

[0199] Step B3 includes:

[0200] Step B3.1: Concatenate the source code sequence from step B1 and the CFG embedding from step B2.

[0201] It should be noted that during the splicing process, an attention mechanism can be used to adaptively assign weights to the two types of features, or a gating mechanism can be used to control the information flow between the two types of features.

[0202] Step B3.2: Access source code samples containing and without vulnerabilities, along with the corresponding CFG graph data.

[0203] Specifically, known vulnerability code examples are obtained from vulnerability databases such as NVD; various typical vulnerabilities are manually injected to construct a dataset. Vulnerability labels are generated using a static vulnerability analysis tool as supervision signals for training.

[0204] Step B3.3 involves end-to-end training of the vulnerability classification model, outputting whether the given code contains a vulnerability. The model parameters are optimized using the cross-entropy loss function. The MSIVD fine-tuning method is employed, utilizing a small amount of labeled data for self-guided continuous optimization. Few-shot learning techniques are used to maximize the value of the labeled data. Thought chain hints are generated to guide the model in continuous reasoning and self-consistency verification. The weight ratio of source code sequence features and graph features is dynamically adjusted during training.

[0205] The above approach, combining multi-task sequence-to-sequence LLM and graph neural networks, fully extracts semantic and structural information from source code, comprehensively characterizing its vulnerability features. End-to-end training tightly couples feature extraction and vulnerability identification processes, forming an integrated end-to-end vulnerability detection solution. Simultaneously, the MSIVD fine-tuning method leverages the advantages of LLM in few-shot learning and continuous inference, endowing vulnerability detection with stronger self-guided optimization capabilities, enabling the model to continuously evolve and adapt to constantly changing vulnerability forms. Compared to traditional rule-based or single machine learning model-based methods, this approach significantly improves the accuracy, generalization, and automation of vulnerability detection, providing a new technical path for code security auditing and playing a crucial role in enhancing overall system security.

[0206] For example, a website administrator mistakenly uploaded a webshell file to a web server, which was then compromised by hackers.

[0207] The specific testing process is as follows:

[0208] 1. The full-traffic mirroring device captures the website's HTTP traffic in real time.

[0209] 2. After the traffic is decrypted, key statistical features are extracted and input into the LightGBM model.

[0210] 3. The model found that multiple URIs contained suspicious keywords, such as: eval, base64_decode, etc., with a threat score as high as 0.95.

[0211] 4. Identified as a variant attack of the China Chopper webshell family.

[0212] 5. Output the threat event and describe the attack process in detail:

[0213] Attackers discovered the website's webshell file using Google Hacking.

[0214] Attackers use webshells to send malicious requests to the server and execute system commands.

[0215] By analyzing the request's IP address and User-Agent, it was determined to be a foreign APT organization.

[0216] 6. Security personnel promptly removed the webshell and patched the vulnerability, preventing further data leakage.

[0217] In summary, model detection capability is one of the core engines of traffic threat detection. Through machine learning algorithms, it can automatically uncover the potential characteristics of malware and discover unknown threats such as webshells, tunnels, and Trojans. Combined with external intelligence, model detection can quickly focus on high-risk traffic and output actionable threat events, greatly improving the efficiency of security analysts. In practice, this capability has played a crucial role in detecting webshell attacks on government and enterprise intranets, accurately identifying various covert variants and safeguarding website system security. In the future, with further algorithm optimization, model detection is expected to become a "killer app" for traffic threat detection, safeguarding cybersecurity across various industries.

[0218] In some embodiments of this application, encrypted traffic detection can be automated through model operation, with the following specific steps:

[0219] Step 1: Implement cloud-based model version control and push through the SecXOps platform.

[0220] Step 2: Continuously optimize and build the detection model based on real business traffic.

[0221] Step 3: Automatically split the training set and test set, evaluate the performance of the new model, and conduct A / B testing.

[0222] In some embodiments of this application, source tracing and forensic analysis can also be performed on the identified threat traffic. The specific steps are as follows:

[0223] Step 1: Correlate threat events from the detection engine and aggregate and analyze suspicious traffic.

[0224] Step 2: Extract key intelligence information such as attacker IP, timeline, and attack methods.

[0225] Step 3: Generate a threat analysis report, which supports visualization and assists in incident response.

[0226] In some embodiments of this application, threat traffic can also be alerted; specifically,

[0227] Step 1: Automatically block malicious traffic based on the customer's preset strategy.

[0228] Step 2: Send alerts promptly via SMS, email, webhook, or other means.

[0229] Step 3: Integrate the situational awareness platform to achieve unified event orchestration and handling.

[0230] In some embodiments of this application, the specific steps for detecting plaintext traffic using multiple methods to obtain multiple detection results may include: extracting multi-dimensional features from the plaintext traffic, wherein the multi-dimensional features include at least: network layer features, application layer features, content features, and behavioral features; network layer features include at least: IP address, port, and protocol type; application layer features include at least: HTTP header information and TLS handshake parameters; content features include at least: keywords and byte distribution in the payload; and behavioral features include at least: connection duration and data transmission mode; selecting at least one method from multiple methods to detect the multi-dimensional features and obtain detection results, wherein the multiple methods include: rule detection, fingerprint detection, and model detection; wherein rule detection includes: matching the multi-dimensional features with a rule set in a preset detection rule base; fingerprint detection includes: comparing the fingerprint information of the plaintext traffic with the fingerprint information in a preset fingerprint base; and model detection includes: using a pre-trained model to identify the multi-dimensional features.

[0231] The process involves fusing multiple detection results to obtain a final detection result, which is used to indicate the threat level of the traffic. This includes: obtaining threat level scores indicated by multiple detection results; obtaining the weight corresponding to each detection result; and determining the final detection result based on the weight corresponding to each detection result and the threat level score indicated by each detection result.

[0232] The specific integration scheme that combines multiple methods is as follows:

[0233] Construct a three-layer detection architecture, consisting of rule-based detection, fingerprint detection, and model-based detection. Each layer can operate independently or interact with other layers to form an organic whole.

[0234] Meanwhile, all three detection methods share a unified feature extraction module. This module can extract multi-dimensional features from network traffic in real time, including but not limited to: network layer features: IP address, port, protocol type, etc.; application layer features: HTTP header information, TLS handshake parameters, etc.; content features: keywords and byte distribution in the payload, etc.; and behavioral features: connection duration, data transmission patterns, etc. These features are updated in real time to a shared feature pool, accessible to all three detection methods simultaneously.

[0235] In some embodiments of this application, the detection results of each method can be cross-validated. Specifically, the output results of each detection method are not isolated, but mutually validate and complement each other; suspicious behaviors discovered by rule detection will trigger fingerprint detection for further confirmation; the results of fingerprint detection will serve as important input features for model detection; the high-confidence predictions of model detection will be fed back to the rule base to dynamically update the detection rules.

[0236] During the fusion of detection results, the weights of the three methods can be dynamically adjusted based on the actual detection performance. For example, rule-based detection has a higher weight for known threats, fingerprint detection has a higher weight for variant attacks, and model-based detection has a dominant weight for unknown threats.

[0237] It should also be noted that the detection process takes into account contextual information such as network environment, service type, and historical alarms, and automatically selects the most suitable combination of detection strategies.

[0238] Employing a multi-method fusion approach can improve detection accuracy: cross-validation of multiple methods significantly reduces false positive and false negative rates; enhance defense against unknown threats: model-based detection can capture complex patterns that are difficult to describe with rules and fingerprints; improve detection efficiency: the most efficient detection method is adaptively selected based on the threat type; enhance system robustness: even if one detection method fails, other methods can still guarantee basic defense capabilities; and support continuous evolution: the feedback loop of detection results enables the system to continuously self-optimize and adapt to new threats.

[0239] In some embodiments of this application, different characteristics of plaintext traffic are determined for each detection result; and the traffic type of traffic mirroring is determined based on the different characteristics of plaintext traffic.

[0240] The three detection methods can detect different characteristics of the traffic to be detected, and together determine the detection result of the traffic to be detected.

[0241] To further explain the detection method that combines multiple approaches, several different detection scenarios are added below for further explanation. For example, in the scenario of detecting advanced persistent threats (APTs), attackers typically use highly customized tools and stealth techniques.

[0242] Rule-based detection: Captures specific attack patterns known to be used by APT groups;

[0243] Fingerprint detection; identifying the toolchains and communication protocols commonly used by APT groups;

[0244] Model detection revealed abnormal data outflow behavior and latent activity patterns.

[0245] The three methods work together to form a multi-layered APT detection and defense system.

[0246] Traditional methods are often ineffective in detecting zero-day exploits, especially when faced with novel, undisclosed vulnerabilities.

[0247] Rule-based detection: Quickly deploy temporary rules to block known attack vectors;

[0248] Fingerprint detection: Identifies abnormal structures and encoding patterns in attack payloads;

[0249] Model-based detection: Learns normal traffic patterns and detects abnormal behaviors that deviate from them.

[0250] This combination allows for the timely detection and prevention of zero-day attacks, even without specific vulnerability information.

[0251] With the increasing prevalence of encrypted communication, traditional content-based detection methods face challenges in detecting encrypted traffic threats.

[0252] Rule-based detection: Analyzing the plaintext portion of the encrypted handshake process;

[0253] Fingerprint detection: Extract TLS fingerprints to identify the communication characteristics of malware;

[0254] Model-based detection: Learn the statistical characteristics of encrypted traffic to discover hidden channels.

[0255] This fusion method can effectively detect threats in encrypted traffic without decryption.

[0256] In the context of WebShell detection, WebShell is a common website backdoor, characterized by its diversity and stealth.

[0257] Rule-based detection: Matching characteristic strings of known WebShells;

[0258] Fingerprint detection: Identifying common obfuscation and encoding techniques used in WebShells;

[0259] Model-based detection: Learn patterns from normal web requests and detect abnormal command execution;

[0260] This multi-dimensional detection method can effectively identify various variants of WebShell.

[0261] In the context of DGA domain detection, Domain Generation Algorithm (DGA) is a commonly used communication concealment technique in botnets.

[0262] Rule-based detection: Matching domain name patterns generated by known DGA algorithms;

[0263] Fingerprint detection: Analyze the registration information and DNS record characteristics of a domain name;

[0264] Model-based detection: Learn the linguistic features of normal domain names to identify abnormal random strings;

[0265] This combined approach can effectively detect and block the communication of the DGA botnet.

[0266] Using a complex advanced persistent threat (APT) attack scenario as an example, this demonstrates how the framework works in practice.

[0267] A major financial institution suffered a highly sophisticated APT attack. The attackers employed various advanced techniques, including zero-day vulnerabilities, custom malware, and encrypted communication. The specific detection and interception process is as follows:

[0268] 1. Initial detection phase;

[0269] (a) Rule detection:

[0270] The system detected a connection attempt from an unknown IP address, which matched the "suspicious geographic location" rule.

[0271] Alarm trigger level: Low;

[0272] (b) Fingerprint detection:

[0273] Analysis of the TLS handshake parameters of the connection revealed the use of an uncommon combination of cipher suites.

[0274] A comparison with fingerprint databases of known APT groups revealed an 80% similarity.

[0275] Alarm level triggered: Medium;

[0276] (c) Model Detection:

[0277] Based on connection behavior patterns (such as time, frequency, and data volume), the model identifies the behavior as abnormal.

[0278] Anomaly score: 0.75 (above the threshold of 0.7);

[0279] Alarm level triggered: Medium.

[0280] 2. In-depth analysis phase;

[0281] (a) Dynamic feature sharing:

[0282] The three detection methods share the following characteristics: suspicious IPs, abnormal TLS parameters, and abnormal behavior patterns.

[0283] Update the shared feature pool for use in subsequent detection.

[0284] (b) Cross-validation of test results:

[0285] Rule detection: Based on the results of fingerprints and models, the alert level is raised from "low" to "medium".

[0286] Fingerprint detection: Feedback the fingerprint similarity information of APT tissues to the model for detection.

[0287] Model detection: Anomaly scores are fed back to the rule engine to dynamically generate new rules.

[0288] (c) Adaptive weight adjustment:

[0289] The system found that fingerprint detection and model detection performed better, so its weights were dynamically increased.

[0290] For example: rule detection weight: 30%, fingerprint detection weight: 35%, model detection weight: 35%.

[0291] In practical applications, the alert levels from rule-based detection and fingerprint detection can be converted into threat scores according to preset rules. The threat scores from the three detection results are then weighted and summed to obtain the final threat score, which in turn generates the alert level.

[0292] 3. Continuous monitoring phase;

[0293] (a) Rule detection:

[0294] Based on the newly generated rules, a suspicious DNS request pattern was discovered, suspected to be DGA.

[0295] Alarm level triggered: Medium;

[0296] (b) Fingerprint detection:

[0297] A communication fingerprint suspected to be a custom C2 (command and control) protocol was identified.

[0298] Alarm trigger level: High;

[0299] (c) Model Detection:

[0300] An abnormal data transmission pattern was detected, which closely matches known data theft behavior.

[0301] Alarm level triggered: High.

[0302] 4. Threat identification and response;

[0303] (a) Context-aware detection strategy:

[0304] The system takes into account that the target is a financial institution, automatically increases sensitivity, lowers the alarm threshold, and determines the alarm level based on the comparison between the threat score and the alarm threshold.

[0305] (b) Comprehensive assessment:

[0306] By combining the results of the three detection methods, the system determined that this was a highly credible APT attack.

[0307] Generate detailed threat intelligence reports, including attack chains, technical characteristics, and potential attack groups.

[0308] (c) Automatic response:

[0309] Isolate the infected host immediately.

[0310] Block all communication with the suspicious C2 server.

[0311] The emergency response plan was activated, and the security team was notified to conduct in-depth analysis and evidence collection.

[0312] 5. Further optimizations;

[0313] (a) Rule update:

[0314] Based on this attack, new detection rules are automatically generated, such as specific DNS request patterns.

[0315] (b) Fingerprint database expansion:

[0316] Add the newly discovered C2 protocol fingerprint to the APT fingerprint database.

[0317] (c) Model retraining:

[0318] We used the data samples from this attack to fine-tune and optimize the anomaly detection model.

[0319] In summary, the three detection methods are not simply parallel, but rather a deeply integrated and mutually reinforcing organic whole; the system can adaptively adjust its strategies and flexibly apply different detection methods according to the characteristics of threats at different stages; continuous information sharing and cross-validation mechanisms make the detection results more reliable and comprehensive; context awareness enables the system to make more accurate judgments based on specific environments; the detection process is not a one-time event, but a dynamic, evolving, and continuously optimized process.

[0320] This multi-level, adaptive detection framework demonstrates powerful threat detection and response capabilities, effectively addressing complex APT attacks. Its core advantage lies in the tight integration and intelligent collaboration of its components. This deep integration makes it difficult for attackers to bypass any single detection layer, thereby significantly improving the overall security level.

[0321] Figure 3 This application discloses a device for detecting the threat level of encrypted traffic, comprising:

[0322] The acquisition module 30 is used to acquire the traffic image of the full traffic and perform session reassembly on the traffic image to obtain the reassembled traffic, wherein the traffic image contains encrypted traffic;

[0323] Decryption module 32 is used to decrypt the recombined traffic using a multi-dimensional decryption method to obtain plaintext traffic. The multi-dimensional decryption method includes at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption and decryption algorithm.

[0324] The detection module 34 is used to detect plaintext traffic using multiple methods, obtain multiple detection results, fuse the multiple detection results to obtain the final detection result, and the detection result is used to indicate the threat level of the traffic.

[0325] The aforementioned encrypted traffic threat level detection device acquires a full traffic image and reassembles the traffic image to obtain reconstructed traffic, which includes encrypted traffic. The reconstructed traffic is then decrypted using a multi-dimensional decryption method to obtain plaintext traffic. This multi-dimensional decryption method includes at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption / decryption algorithm. Multiple methods are used to detect the plaintext traffic, resulting in multiple detection results. These results are then fused to obtain the final detection result, which indicates the threat level of the traffic. This achieves the goal of decrypting encrypted traffic before detection, thereby improving the accuracy of encrypted traffic threat level detection and solving the technical problem of low accuracy in encrypted traffic threat level detection in related technologies.

[0326] The decryption module 32 includes a decryption submodule, used to decrypt the reconstructed traffic using a multi-dimensional decryption method to obtain plaintext traffic. This includes: extracting the encryption key suite of the reconstructed traffic when the multi-dimensional decryption method uses a certificate; obtaining the private key corresponding to the reconstructed traffic through the certificate corresponding to the reconstructed traffic, decrypting the encryption key suite to obtain the symmetric encryption key for subsequent communication; decrypting the reconstructed traffic based on the symmetric encryption key to obtain plaintext traffic; updating the private key corresponding to the reconstructed traffic when a certificate update is detected; using the previous private key to decrypt the session corresponding to the reconstructed traffic if the session belongs to the previous certificate, until the session belonging to the previous certificate ends; and after the session belonging to the previous certificate ends, decrypting all sessions corresponding to the reconstructed traffic using the updated private key.

[0327] The detection module 34 includes a first detection submodule and a second detection submodule. The first detection submodule is used to detect plaintext traffic using multiple methods to obtain multiple detection results, including: selecting at least one method from multiple methods to detect plaintext traffic and obtaining a detection result. The multiple methods include: rule detection, fingerprint detection, and model detection. Rule detection includes: matching the features of plaintext traffic with a rule set in a preset detection rule library. Fingerprint detection includes: comparing the fingerprint information of plaintext traffic with the fingerprint information in a preset fingerprint library. Model detection includes: using a pre-trained model to identify the features of plaintext traffic.

[0328] The first detection submodule includes: a detection unit, used to select at least one method from multiple methods to detect plaintext traffic and obtain a detection result, including: when using the rule-based detection method, restoring the plaintext traffic to plaintext data; matching the features of the plaintext data with a rule set in a preset detection rule base; if the features of the plaintext data match any rule in the rule set, determining that the plaintext traffic corresponding to the plaintext data is threatening traffic, wherein any rule in the rule set is used to represent the features of threatening traffic; if the features of the plaintext data are the same as the features of threatening traffic, determining that the features of the plaintext data match a rule in the rule set; and when using fingerprint detection... The process involves: acquiring fingerprint information of plaintext traffic to characterize the features obtained during the handshake between the server and the client; calculating the similarity between the fingerprint information and fingerprint information in a preset fingerprint database; determining that the plaintext traffic corresponding to the fingerprint information is threatening traffic if the similarity is higher than a preset similarity threshold; when using model detection, obtaining the traffic statistical features of the plaintext traffic as input to a pre-trained model and obtaining the output of the pre-trained model, wherein the output of the pre-trained model includes: a threat level score of the plaintext traffic, and the statistical features of the plaintext traffic include at least: the request method of the plaintext traffic, the URI length of the plaintext traffic, and the number of parameters corresponding to the plaintext traffic; and determining whether the plaintext traffic is threatening traffic based on the output of the pre-trained model.

[0329] The detection unit also includes a honeypot subunit for acquiring honeypot data, which includes various attack traffic data. Multi-dimensional features of attack behavior are extracted from this data, including network layer features, host layer features, and application layer features. Network layer features include at least the source IP, port, and protocol of the attack traffic; host layer features include at least the attacker's system operation information and file read / write information; and application layer features include at least the URL parameters and SQL injection statements of the network attack. A honeypot model is constructed based on these multi-dimensional features, and the model is used to analyze plaintext traffic to obtain initial detection results. These initial results are then input into a pre-trained model to output the final detection results.

[0330] The detection module 34 also includes: a vulnerability unit, used to acquire a source code corpus and segment the source code in the source code corpus into token sequences; compile the source code in the source code corpus into an intermediate representation; construct the control flow graph of the program based on the intermediate representation; extract features from the token sequences and the control flow graph of the program respectively to obtain source code sequence features and program structure graph features; train a vulnerability detection model based on the source code sequence features and program structure graph features, and use the vulnerability detection model to detect vulnerabilities in the server system.

[0331] The second detection submodule is used to detect plaintext traffic using multiple methods to obtain various detection results. These include: extracting multi-dimensional features from the plaintext traffic, where the multi-dimensional features include at least: network layer features, application layer features, content features, and behavioral features. Network layer features include at least: IP address, port, and protocol type; application layer features include at least: HTTP header information and TLS handshake parameters; content features include at least: keywords and byte distribution in the payload; and behavioral features include at least: connection duration and data transmission mode. The module then selects at least one method from multiple methods to detect the multi-dimensional features and obtain detection results. These multiple methods include: rule detection, fingerprint detection, and model detection. Rule detection includes: matching the multi-dimensional features with a rule set in a preset detection rule base; fingerprint detection includes: comparing the fingerprint information of the plaintext traffic with the fingerprint information in a preset fingerprint database; and model detection includes: using a pre-trained model to identify the multi-dimensional features.

[0332] The detection module 34 also includes a first fusion submodule and a second fusion submodule. The first fusion submodule is used to fuse multiple detection results to obtain a final detection result, including: obtaining threat level scores indicated by multiple detection results; obtaining the weight corresponding to each detection result; and determining the final detection result based on the weight corresponding to each detection result and the threat level score indicated by each detection result.

[0333] The second fusion submodule is used to fuse multiple detection results to obtain the final detection result, including: obtaining different characteristics of plaintext traffic for each detection result; and determining the traffic type of traffic mirroring based on the different characteristics of plaintext traffic.

[0334] It should be noted that, Figure 3 The device shown is used to perform the encryption traffic threat level detection. Figure 2 The method for detecting the threat level of encrypted traffic shown above also applies to the device for detecting the threat level of encrypted traffic, and will not be repeated here.

[0335] This application also provides a computer device, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor, connected to the memory, is used to execute the above-described method for detecting the degree of threat of encrypted traffic.

[0336] This application also provides a non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the above-mentioned method for detecting the degree of encrypted traffic threat by running the computer program.

[0337] This application also provides a computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the encrypted traffic threat level detection method in this application.

[0338] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the method for detecting the level of encrypted traffic threat in this application.

[0339] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0340] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0341] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0342] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0343] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0344] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0345] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for detecting the threat level of encrypted traffic, characterized in that, include: Obtain a traffic mirror of the full traffic, and perform session reassembly on the traffic mirror to obtain reassembled traffic, wherein the traffic mirror contains encrypted traffic; The reconstructed traffic is decrypted using a multi-dimensional decryption method to obtain plaintext traffic. The multi-dimensional decryption method includes at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption and decryption algorithm. The plaintext traffic is detected using multiple methods, resulting in multiple detection results. These multiple detection results are then fused to obtain a final detection result, which is used to indicate the threat level of the traffic. The plaintext traffic was detected using multiple methods, resulting in various detection results, including: At least one of the multiple methods is selected to detect the plaintext traffic to obtain a detection result. The multiple methods include rule detection, fingerprint detection, and model detection. The rule detection includes matching the features of the plaintext traffic with a rule set in a preset detection rule library. The fingerprint detection includes comparing the fingerprint information of the plaintext traffic with the fingerprint information in a preset fingerprint library. The model detection includes using a pre-trained model to identify the features of the plaintext traffic. At least one of the aforementioned methods is selected to detect the plaintext traffic, and a detection result is obtained, including: When the detection is performed using the rule-based detection method, the plaintext traffic is restored to plaintext data; The features of the plaintext data are matched with the rule set in the preset detection rule base. If the features of the plaintext data match any rule in the rule set, the detection result is determined to be that the plaintext traffic corresponding to the plaintext data is threatening traffic. Each rule in the rule set is used to represent the features of threatening traffic. If the features of the plaintext data are the same as the features of the threatening traffic, the features of the plaintext data are determined to match the rule in the rule set. When the fingerprint detection is used, fingerprint information of the plaintext traffic is obtained, and the fingerprint information is used to characterize the feature information obtained during the handshake process between the server and the client. The similarity between the fingerprint information and the fingerprint information in the preset fingerprint database is obtained. If the similarity is higher than a preset similarity threshold, the plaintext traffic corresponding to the fingerprint information is determined to be threatening traffic. When using the model for detection, the traffic statistics features of the plaintext traffic are obtained as input to a pre-trained model, and the output of the pre-trained model is obtained. The output of the pre-trained model includes: a threat level score of the plaintext traffic, and the statistical features of the plaintext traffic include at least: the request method of the plaintext traffic, the URI length of the plaintext traffic, and the number of parameters corresponding to the plaintext traffic. The plaintext traffic is determined to be threatening based on the output of the pre-trained model. The multiple detection results are fused to obtain the final detection result, including: Obtain a threat level score indicating multiple detection results; Obtain the weight corresponding to each detection result; The final detection result is determined based on the weight corresponding to each detection result and the threat level score indicated by each detection result. During the fusion of detection results, the weights of the three methods are dynamically adjusted according to the detection results: for known threats, rule detection has a higher weight; for variant attacks, fingerprint detection has a higher weight; and for unknown threats, model detection has a dominant weight.

2. The method according to claim 1, characterized in that, The reconstructed traffic is decrypted using a multi-dimensional decryption method to obtain plaintext traffic, including: When the multi-dimensional decryption method uses certificate decryption, the encryption key suite of the reconstructed traffic is extracted; The private key corresponding to the reconstructed traffic is obtained through the certificate corresponding to the reconstructed traffic, and the encryption key suite is decrypted to obtain the symmetric encryption key for subsequent communication. The reconstructed traffic is decrypted using the symmetric encryption key to obtain the plaintext traffic; If a certificate update is detected for the reconstructed traffic, the private key corresponding to the reconstructed traffic is updated. If the session corresponding to the reconstructed traffic belongs to the certificate before the update, the private key before the update is used for decryption until the session belonging to the certificate before the update ends. After the session belonging to the certificate before the update ends, all sessions corresponding to the reassembled traffic are decrypted using the updated private key.

3. The method according to claim 1, characterized in that, The method further includes: Acquire honeypot data, which includes: various attack traffic data; Multi-dimensional features of traffic attack behavior are extracted from the various attack traffic data. These multi-dimensional features include network layer features, host layer features, and application layer features. The network layer features include at least the source IP, port, and protocol of the attack traffic. The host layer features include at least the attacker's system operation information and file read / write information. The application layer features include at least the URL parameters of the network attack and the SQL injection statements of the network attack. A honeypot model is constructed based on the multi-dimensional features of the traffic attack behavior, and the honeypot model is used to analyze the plaintext traffic to obtain initial detection results. The initial detection results are then input into the pre-trained model to output the detection results.

4. The method according to claim 1, characterized in that, The method further includes: Obtain a source code corpus and segment the source code in the corpus into token sequences; Compile the source code in the source code corpus into an intermediate representation; The control flow graph of the program is constructed based on the intermediate representation; Feature extraction is performed on the token sequence and the control flow graph of the program respectively to obtain source code sequence features and program structure graph features; A vulnerability detection model is trained based on the source code sequence features and the program structure diagram features. The vulnerability detection model is used to detect vulnerabilities in server systems.

5. The method according to claim 1, characterized in that, The plaintext traffic was detected using multiple methods, resulting in various detection results, including: Extract multi-dimensional features from the plaintext traffic. The multi-dimensional features include at least: network layer features, application layer features, content features, and behavioral features. The network layer features include at least: IP address, port, and protocol type. The application layer features include at least: HTTP header information and TLS handshake parameters. The content features include at least: keywords and byte distribution in the payload. The behavioral features include at least: connection duration and data transmission mode. At least one of the multiple methods is selected to detect the multi-dimensional features to obtain a detection result. The multiple methods include rule detection, fingerprint detection, and model detection. The rule detection includes matching the multi-dimensional features with a rule set in a preset detection rule library. The fingerprint detection includes comparing the fingerprint information of the plaintext traffic with the fingerprint information in a preset fingerprint library. The model detection includes using a pre-trained model to identify the multi-dimensional features.

6. The method according to claim 1, characterized in that, The multiple detection results are fused to obtain the final detection result, including: Each detection result is used to determine different characteristics of the plaintext traffic; The traffic type of the traffic mirror is determined based on the different characteristics of the plaintext traffic.

7. A device for detecting the threat level of encrypted traffic, characterized in that, include: The acquisition module is used to acquire a traffic image of the full traffic and perform session reassembly on the traffic image to obtain reassembled traffic, wherein the traffic image contains encrypted traffic; The decryption module is used to decrypt the reconstructed traffic using a multi-dimensional decryption method to obtain plaintext traffic. The multi-dimensional decryption method includes at least one of the following: decryption using a decryption algorithm library, decryption using a certificate, and decryption using a standard encryption and decryption algorithm. The detection module is used to detect the plaintext traffic using multiple methods, obtain multiple detection results, fuse the multiple detection results to obtain a final detection result, and the detection result is used to indicate the threat level of the traffic; The plaintext traffic was detected using multiple methods, resulting in various detection results, including: At least one of the multiple methods is selected to detect the plaintext traffic to obtain a detection result. The multiple methods include rule detection, fingerprint detection, and model detection. The rule detection includes matching the features of the plaintext traffic with a rule set in a preset detection rule library. The fingerprint detection includes comparing the fingerprint information of the plaintext traffic with the fingerprint information in a preset fingerprint library. The model detection includes using a pre-trained model to identify the features of the plaintext traffic. At least one of the aforementioned methods is selected to detect the plaintext traffic, and a detection result is obtained, including: When the detection is performed using the rule-based detection method, the plaintext traffic is restored to plaintext data; The features of the plaintext data are matched with the rule set in the preset detection rule base. If the features of the plaintext data match any rule in the rule set, the detection result is determined to be that the plaintext traffic corresponding to the plaintext data is threatening traffic. Each rule in the rule set is used to represent the features of threatening traffic. If the features of the plaintext data are the same as the features of the threatening traffic, the features of the plaintext data are determined to match the rule in the rule set. When the fingerprint detection is used, fingerprint information of the plaintext traffic is obtained, and the fingerprint information is used to characterize the feature information obtained during the handshake process between the server and the client. The similarity between the fingerprint information and the fingerprint information in the preset fingerprint database is obtained. If the similarity is higher than a preset similarity threshold, the plaintext traffic corresponding to the fingerprint information is determined to be threatening traffic. When using the model for detection, the traffic statistics features of the plaintext traffic are obtained as input to a pre-trained model, and the output of the pre-trained model is obtained. The output of the pre-trained model includes: a threat level score of the plaintext traffic, and the statistical features of the plaintext traffic include at least: the request method of the plaintext traffic, the URI length of the plaintext traffic, and the number of parameters corresponding to the plaintext traffic. The plaintext traffic is determined to be threatening based on the output of the pre-trained model. The multiple detection results are fused to obtain the final detection result, including: Obtain a threat level score indicating multiple detection results; Obtain the weight corresponding to each detection result; The final detection result is determined based on the weight corresponding to each detection result and the threat level score indicated by each detection result. During the fusion of detection results, the weights of the three methods are dynamically adjusted according to the detection results: for known threats, rule detection has a higher weight; for variant attacks, fingerprint detection has a higher weight; and for unknown threats, model detection has a dominant weight.

8. A computer device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; The processor, connected to the memory, is used to execute the method for detecting the threat level of encrypted traffic as described in any one of claims 1-5.

9. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method for detecting the threat level of encrypted traffic as described in any one of claims 1-5.

Images