Traffic detection method, apparatus and device

Abstract

The application discloses a traffic detection method, device and equipment. The method comprises the following steps: obtaining passive domain name system (DNS) resolution traffic data of a cloud function to be detected; extracting DNS resolution time sequence features of the cloud function to be detected from the passive DNS resolution traffic data; performing C2 software carrier identification on the cloud function to be detected according to the DNS resolution time sequence features of the cloud function to be detected and sample DNS resolution time sequence features of a plurality of C2 software samples, to obtain an identification result; and if the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, determining that network traffic of the cloud function to be detected is suspected C2 malicious traffic. According to the method, the purpose of determining whether the network traffic of the cloud function to be detected is suspected C2 malicious traffic is achieved.

Description

Technical Field

[0001] This application relates to the field of cloud technology, and more specifically, to a traffic detection method, apparatus, and device. Background Technology

[0002] Serverless Cloud Function (SCF) is a serverless computing service that allows developers to run code in a cloud environment without configuring and managing servers. Given the characteristics of cloud functions, some may be maliciously used as servers for C2 (Command and Control) software to launch network attacks. If a cloud function is used as a server for C2 software, it is called a C2 software carrier cloud function.

[0003] Therefore, it is necessary to identify whether a cloud function is a suspected C2 software carrier cloud function, and then identify whether the access traffic of the cloud function is malicious traffic. Summary of the Invention

[0004] In view of this, embodiments of this application propose a flow detection method, apparatus, and device.

[0005] In a first aspect, embodiments of this application provide a traffic detection method, the method comprising: acquiring passive Domain Name System (DNS) resolution traffic data of a cloud function to be detected; extracting DNS resolution timing features of the cloud function to be detected from the passive DNS resolution traffic data; identifying the cloud function to be detected as a C2 software carrier based on the DNS resolution timing features of the cloud function to be detected and the sample DNS resolution timing features of multiple C2 software samples, and obtaining an identification result; if the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, determining that the network traffic of the cloud function to be detected is suspected C2 malicious traffic.

[0006] Secondly, embodiments of this application provide a traffic detection device, comprising: an acquisition module for acquiring passive Domain Name System (DNS) resolution traffic data of a cloud function to be detected; an extraction module for extracting DNS resolution timing features of the cloud function to be detected from the passive DNS resolution traffic data; an identification module for identifying the cloud function to be detected as a C2 software carrier based on the DNS resolution timing features of the cloud function to be detected and the sample DNS resolution timing features of multiple C2 software samples, and obtaining an identification result; and a determination module for determining that the network traffic of the cloud function to be detected is suspected C2 malicious traffic if the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function.

[0007] Optionally, the extraction module is also used to perform traffic analysis on each C2 software sample to obtain the carrier cloud function sample corresponding to each C2 software sample; obtain the sample passive DNS resolution traffic data of each carrier cloud function sample; and extract the DNS resolution time sequence features from the sample passive DNS resolution traffic data to obtain the sample DNS resolution time sequence features of the corresponding C2 software sample.

[0008] Optionally, the extraction module is also used to perform the following processing on each C2 software sample: perform sandbox traffic analysis on the C2 software sample to obtain the sample access traffic data of the C2 software sample; decrypt the sample access traffic data of the C2 software sample to obtain the candidate sample access address of the C2 software sample; and select the candidate sample access address whose domain name is the domain name of the cloud function service provider from the candidate sample access address of the C2 software sample as the carrier cloud function sample corresponding to the C2 software sample.

[0009] Optionally, the identification module is also used to train a C2 software carrier identification model using the sample DNS resolution timing features of multiple C2 software samples; the trained C2 software carrier identification model is then used to identify the C2 software carrier of the cloud function to be detected based on the DNS resolution timing features, and the identification result is obtained.

[0010] Optionally, the identification module is further configured to perform the (i+1)th round of clustering on the sample DNS resolution time sequence features of multiple C2 software samples based on the multiple cluster centers determined in the i-th iteration, to obtain the (i+1)th round of clustering results; i is a positive integer, and when i=1, the multiple cluster centers in the C2 software carrier identification model are initialized; based on the sample DNS resolution time sequence features belonging to the same cluster center in the (i+1)th round of clustering results, the multiple cluster centers in the C2 software carrier identification model are updated; if, based on the updated cluster centers in the C2 software carrier identification model, it is determined that the iteration termination condition is not met, i is incremented by 1, and the process returns to the step of performing the (i+1)th round of clustering on the sample DNS resolution time sequence features of multiple C2 software samples based on the multiple cluster centers determined in the i-th iteration, to obtain the (i+1)th round of clustering results, until the iteration termination condition is met.

[0011] Optionally, the extraction module is also used to count the number of domain name resolution requests of the cloud function to be tested in multiple periods based on the passive DNS resolution traffic data; and to generate the DNS resolution timing characteristics of the cloud function to be tested based on the number of domain name resolution requests of the cloud function to be tested in multiple periods.

[0012] Optionally, the extraction module is further configured to determine the maximum number of domain name resolution requests based on the number of domain name resolution requests of the cloud function to be detected in multiple periods; normalize the number of domain name resolution requests in multiple periods based on the maximum number of domain name resolution requests; and combine the normalized number of domain name resolution requests corresponding to multiple periods in chronological order to obtain the DNS resolution time sequence characteristics of the cloud function to be detected.

[0013] Optionally, the acquisition module is also used to acquire the public domain names of each cloud function service provider; in the passive DNS traffic database, it acquires the passive DNS resolution traffic data of each public domain name for the domain name to be resolved; wherein, the domain name to be resolved includes the passive DNS resolution traffic data of a public domain name, and the passive DNS resolution traffic data of a cloud function to be tested.

[0014] Optionally, the determining module is also used to update and train the trained C2 software carrier identification model based on the DNS resolution timing characteristics of the cloud function to be detected.

[0015] Optionally, the determination module is also used to generate an alarm message if network traffic of the cloud function to be detected is detected.

[0016] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory; the memory stores computer-readable instructions, which, when executed by the processor, implement the above-described method.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-readable instructions that, when executed by a processor, implement the above-described method.

[0018] Fifthly, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the method described above.

[0019] This application provides a traffic detection method, apparatus, and device. In this application, based on the passive Domain Name System (DNS) resolution traffic data of the cloud function to be detected, the DNS resolution timing characteristics of the cloud function to be detected are determined. Then, based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, the cloud function to be detected is identified as a C2 software carrier, and an identification result is obtained. If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, this means that the cloud function to be detected is highly likely to be manipulated by C2 software. Therefore, it is determined that the network traffic of the cloud function to be detected is suspected C2 malicious traffic, thereby achieving the purpose of determining whether the network traffic of the cloud function to be detected is suspected C2 malicious traffic.

[0020] Furthermore, this application learns from the known DNS resolution timing characteristics of C2 software samples, and then extracts the DNS resolution timing characteristics of the cloud function to be detected by starting from the passive DNS resolution traffic data of the cloud function to be detected. This allows for the identification of whether the cloud function to be detected is a suspected C2 software carrier cloud function. Therefore, it eliminates the need to obtain detailed traffic data related to the cloud function hidden within the cloud function service provider's infrastructure, thus reducing the difficulty and improving the accuracy of C2 software carrier cloud function identification. This addresses, to some extent, the problem that external methods struggle to identify C2 software carrier cloud functions whose operating state is almost a black box. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A schematic diagram is shown illustrating the application scenarios applicable to the embodiments of this application;

[0023] Figure 2 A flowchart of a traffic detection method according to an embodiment of this application is shown;

[0024] Figure 3 This illustration shows a schematic diagram of the process of obtaining passive Domain Name System (DNS) resolution traffic data in an embodiment of this application;

[0025] Figure 4 This illustration shows a schematic diagram of how the number of domain name resolution requests changes over a period of time, according to an embodiment of this application.

[0026] Figure 5 This illustration shows a schematic diagram of how the number of normalized domain name resolution requests changes over a period of time, according to an embodiment of this application.

[0027] Figure 6 This illustration shows a schematic diagram of the process of obtaining passive DNS resolution traffic data in an embodiment of this application;

[0028] Figure 7 It shows Figure 2 A flowchart of step S130 in one embodiment is shown in the corresponding example;

[0029] Figure 8 A schematic diagram of a flow detection process according to an embodiment of this application is shown;

[0030] Figure 9 A block diagram of a flow detection device according to an embodiment of this application is shown;

[0031] Figure 10 A structural block diagram of an electronic device for performing a flow detection method according to an embodiment of this application is shown. Detailed Implementation

[0032] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0033] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0034] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the application. It should be noted that "multiple" as used herein refers to two or more. "And / or" describes the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0035] The following will explain the nouns and abbreviations used in the embodiments of this application:

[0036] C2 software: also known as C2 malware, C2 (Command and Control) malware is a type of malicious program that controls and manipulates infected devices through remote servers, and is often used for data theft or network attacks.

[0037] DNS: The Domain Name System is a critical infrastructure of the Internet, responsible for resolving domain names into IP addresses, thereby enabling users to access websites through user-friendly names.

[0038] Passive DNS traffic data: also known as passive DNS resolution traffic data, refers to the traffic generated when requesting the Domain Name System to resolve domain names.

[0039] This application discloses a traffic detection method, apparatus, and device, which relates to cloud technology.

[0040] Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.

[0041] Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0042] Please refer to Figure 1 The diagram illustrates an application scenario applicable to the embodiments of this application. This application scenario includes a terminal 110, a network 120, and a server 130, where the network 120 can be a wired network or a wireless network.

[0043] Terminal 110 can be, for example, a smartphone, tablet, e-book reader, music player, wearable device, smart home device, in-vehicle terminal, etc. Terminal 110 can run a client for a security detection application, which can be used to implement the traffic detection method described in this application.

[0044] Server 120 can serve as the server for security detection applications, providing services to the clients of these applications. Server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0045] In some embodiments, server 120 may also communicate with a domain name server or a passive DNS traffic database, thereby obtaining passive DNS resolution traffic data of the cloud function to be detected from the domain name server or the passive DNS traffic database.

[0046] In some embodiments, server 130 may respond to a traffic detection request by acquiring passive DNS resolution traffic data of the cloud function to be detected. Then, server 130 continues to extract DNS resolution timing characteristics of the cloud function to be detected from the passive DNS resolution traffic data. Based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, server 130 performs C2 software carrier identification on the cloud function to be detected, obtaining an identification result. If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, server 130 determines that the network traffic of the cloud function to be detected is suspected C2 malicious traffic. Subsequently, server 130 may also output a prompt message indicating that the network traffic of the cloud function to be detected is suspected C2 malicious traffic.

[0047] In some embodiments, terminal 110 may send a traffic detection request, including the cloud function to be detected, to server 130. Server 130 may respond to the traffic detection request by obtaining passive DNS resolution traffic data of the cloud function to be detected. Then, server 130 continues to extract the DNS resolution timing characteristics of the cloud function to be detected from the passive DNS resolution traffic data. Based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, server 130 performs C2 software carrier identification on the cloud function to be detected, obtaining the identification result. Afterward, server 130 returns the identification result to terminal 110. If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, terminal 110 determines that the network traffic of the cloud function to be detected is suspected C2 malicious traffic. Furthermore, terminal 110 may also output a prompt message indicating that the network traffic of the cloud function to be detected is suspected C2 malicious traffic.

[0048] For ease of description, the following embodiments of this application will use electronic devices as the execution subject of the traffic detection method.

[0049] Please see Figure 2 , Figure 2 A flowchart of a traffic detection method according to an embodiment of this application is shown. This method is used in an electronic device, which may be, for example, an electronic device... Figure 1 In the terminal 110 or server 130, the method may include:

[0050] S110. Obtain the passive Domain Name System (DNS) resolution traffic data of the cloud function to be tested.

[0051] The cloud function to be detected can refer to the cloud function to be detected. In this application, the main purpose is to detect whether the cloud function is a suspected C2 software carrier cloud function, that is, to identify whether a cloud function is used as a server carrier of C2 software.

[0052] In some implementations, electronic devices can determine the cloud function requested for detection by the traffic detection request as the cloud function to be detected. The cloud function can be identified using a function URL (Uniform Resource Locator) configured for it; different cloud functions have different function URLs. The function URL of a cloud function is a dedicated HTTP(S) endpoint for that cloud function, and can be accessed through a browser or other means to invoke the cloud function.

[0053] It's worth noting that the serverless computing service represented by cloud functions doesn't mean there are no servers at all. Rather, it means developers don't need to worry about the underlying server resources; they only need to focus on the core code. Cloud functions actually run on a platform provided by the cloud function service provider. Therefore, the domain name in the function URL corresponding to a cloud function is actually the domain name of the cloud function service provider.

[0054] In other implementations, considering that the specific function URL of the cloud function may not be available, and since the cloud function runs on a platform provided by the cloud function service provider, the public domain name provided by each cloud function service provider for the cloud function service can be obtained on a per-service basis. Then, based on the corresponding public domain name on each cloud function service, passive DNS resolution traffic data for the requested domain name being resolved, where the requested domain name is one of the public domain names, is retrieved from the passive DNS traffic database and used as the passive DNS resolution traffic data for the cloud function to be tested. Specifically, the passive DNS resolution traffic data for a public domain name is considered as the passive DNS resolution traffic data for the cloud function to be tested.

[0055] A passive DNS traffic database refers to a database storing a large amount of passive DNS traffic data, which may include passive DNS traffic data from cloud functions or non-cloud functions. Passive DNS traffic data refers to traffic generated by requests for domain name resolution, which may include multiple DNS records. A DNS record is a record generated by a domain name server performing a single domain name resolution. A DNS record may include information such as the domain name being resolved, the time of the resolution request, the requesting party, and the IP address determined by the resolution. Multiple cloud functions can run on a cloud function service provider's platform. The function URLs of multiple cloud functions running on the same provider's platform all include the public domain name provided by that provider for the cloud function service. Therefore, in this application, the public domain names of each cloud function service provider are obtained, and the public domain names are used as query keywords to query the passive DNS traffic database. The obtained domain name is the passive DNS resolution traffic data for each of these public domain names, which serves as the passive DNS resolution traffic data for the cloud function to be tested.

[0056] The process of obtaining passive Domain Name System (DNS) resolution traffic data for the aforementioned cloud function to be tested can be as follows: Figure 3 As shown, firstly, the public domain names of each cloud function service provider can be determined, and then the passive DNS resolution traffic data of the cloud function to be tested can be queried from the passive DNS traffic database.

[0057] S120. Extract the DNS resolution timing features of the cloud function to be detected from the passive DNS resolution traffic data.

[0058] The DNS resolution timing characteristics of the cloud function under test refer to the timing characteristics of the cloud function's behavior under the domain name resolution dimension. It is understandable that calling a cloud function requires first resolving the function URL to a domain name; that is, resolving the function URL to a domain name is a prerequisite and essential step in calling the cloud function. Therefore, the timing characteristics of the cloud function's behavior under the domain name resolution dimension can reflect the timing behavior of calling the cloud function, that is, reflect the timing changes of cloud function calls or the global timing change patterns.

[0059] As described above, the passive DNS resolution traffic data of the cloud function to be tested includes multiple domain name resolution records, which may include information such as the domain name requested for resolution, the time of the domain name resolution request, and the requester of the domain name resolution request. Based on this, the number of domain name resolution requests of the cloud function to be tested in multiple periods can be counted according to the passive DNS resolution traffic data; based on the number of domain name resolution requests of the cloud function to be tested in multiple periods, the DNS resolution time sequence characteristics of the cloud function to be tested can be generated. The duration of a period can be 1 hour, 3 hours, 12 hours, 1 day, 1 week, etc., and can be set according to actual needs.

[0060] For example, if the period is 1 day, the earliest DNS resolution request time T1 and the latest DNS resolution request time T2 can be determined from the passive DNS resolution traffic data of the cloud function being tested. Then, the number of DNS resolution requests in the time period from T1 to T2 is counted on a daily basis. After that, the DNS resolution timing characteristics of the cloud function to be tested can be determined based on the number of DNS resolution requests in the time period from T1 to T2 over multiple days. The DNS resolution timing characteristics of the cloud function to be tested reflect the behavioral timing characteristics of the cloud function to be tested in the time period from T1 to T2 over multiple days.

[0061] In some implementations, the time period covered by the passive DNS resolution traffic data of the cloud function to be detected can be first determined as the target time period. This target time period is then divided into multiple periods according to the duration of the aforementioned periods. For each period, based on the passive DNS resolution traffic data of the cloud function to be detected, the number of DNS resolution requests made by the cloud function in each period is determined, resulting in the number of DNS resolution requests for multiple periods. Then, based on the time sequence of the multiple periods and the number of DNS resolution requests made by the cloud function to be detected in the multiple periods, the DNS resolution time sequence characteristics of the cloud function to be detected can be generated.

[0062] In some implementations, the number of domain name resolution requests of the cloud function to be tested in each of the aforementioned multiple periods can be combined to obtain the DNS resolution timing characteristics of the cloud function to be tested.

[0063] In some other implementations, the number of DNS resolution requests of the cloud function to be tested in each period can be normalized to obtain the normalized number of DNS resolution requests of the cloud function to be tested in each period. Then, according to the time sequence of the aforementioned multiple periods, the normalized number of DNS resolution requests of the cloud function to be tested in multiple periods can be combined to obtain the DNS resolution time sequence characteristics of the cloud function to be tested.

[0064] In some other implementations, the maximum number of DNS resolution requests can be determined based on the number of DNS resolution requests made by the cloud function to be detected in multiple periods; the number of DNS resolution requests in multiple periods can be normalized based on the maximum number of DNS resolution requests; and the normalized number of DNS resolution requests corresponding to multiple periods can be combined according to the chronological order between multiple periods to obtain the DNS resolution time sequence characteristics of the cloud function to be detected.

[0065] The maximum number of DNS resolution requests can be determined from the number of DNS resolution requests of the cloud function under test in multiple periods. Then, the maximum number of DNS resolution requests is normalized to 1. The number of other DNS resolution requests of the cloud function under test in multiple periods, excluding the maximum number of DNS resolution requests, is divided by the maximum number of DNS resolution requests respectively, and these are taken as the corresponding normalized number of DNS resolution requests. This achieves the normalization of the number of other DNS resolution requests to the range of 0 to 1.

[0066] For example, the change in the number of domain name resolution requests for a certain cloud function D1 under test over a period of time is as follows: Figure 4 As shown, the vertical axis represents the number of domain name resolution requests for the cloud function D1 to be tested, and the horizontal axis represents the period, where each period lasts for one day. Figure 4 As can be observed, the number of domain name resolution requests varies within a relatively large range (1000-2000) across different periods. Correspondingly, the normalized result of the number of domain name resolution requests for the cloud function D1 under test varies with the period as follows: Figure 5 As shown, in Figure 5 It can be observed that the normalized result of the number of domain name resolution requests varies within a small range (0.4-1.0) between different periods.

[0067] In other embodiments, the maximum and minimum number of DNS resolution requests may be determined first from the number of DNS resolution requests in multiple cycles. Then, the difference between the number of DNS resolution requests in each cycle and the minimum number of DNS resolution requests is subtracted to obtain a first difference. The first difference is then divided by a second difference to obtain the normalized number of DNS resolution requests in one cycle. The second difference is the difference between the maximum and minimum number of DNS resolution requests.

[0068] In some embodiments, one or more of the following can be added to the DNS resolution time sequence features of the cloud function to be detected as sub-features: the earliest time of requesting domain name resolution in each period, the latest time of requesting domain name resolution in each period, and the K time periods with the highest frequency of requesting domain name resolution in a period (K is a positive integer and can be set as needed, and the duration of the time periods can also be set as needed).

[0069] S130. Based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, the C2 software carrier of the cloud function to be detected is identified, and the identification result is obtained.

[0070] C2 software samples refer to software samples known as C2 malware. In this application, temporal features are extracted from the passive Domain Name System (DNS) resolution traffic data of the cloud function controlled by the C2 software sample (i.e., the cloud function that serves as the server of the C2 software sample) to obtain the sample DNS resolution temporal features of the C2 software sample.

[0071] In this application, traffic analysis is performed on each C2 software sample to obtain the carrier cloud function sample corresponding to each C2 software sample; passive DNS resolution traffic data of each carrier cloud function sample is obtained; and DNS resolution timing features are extracted from the passive DNS resolution traffic data of the samples to obtain the corresponding C2 software sample's sample DNS resolution timing features.

[0072] First, traffic analysis can be performed on the C2 software sample to determine the network addresses requested during its operation. Then, based on these network addresses, network addresses including public domain names of cloud function service providers are selected as the carrier cloud function samples corresponding to the C2 software samples. Next, passive DNS traffic data where the requested domain name resolves to the network address of the carrier cloud function sample is obtained from the passive DNS traffic database, and this data is used as the sample passive DNS resolution traffic data corresponding to the C2 software samples. Then, DNS resolution timing features are extracted from the sample passive DNS resolution traffic data corresponding to the C2 software samples to obtain the sample DNS resolution timing features of the corresponding C2 software samples. The process of extracting the sample DNS resolution timing features is the same as the process of extracting the DNS resolution timing features of the cloud functions to be detected, and will not be repeated here.

[0073] In some implementations, the following processing can be performed on each C2 software sample: sandbox traffic analysis is performed on the C2 software sample to obtain sample access traffic data of the C2 software sample; the sample access traffic data of the C2 software sample is decrypted to obtain candidate sample access addresses of the C2 software sample; among the candidate sample access addresses of the C2 software sample, candidate sample access addresses with domain names of cloud function service providers are selected as the carrier cloud function samples corresponding to the C2 software samples.

[0074] After identifying the C2 software sample, sandbox traffic analysis can be performed on the C2 software sample to obtain the TLS (Transport Layer Security) traffic in the sandbox, which is used as the sample access traffic data of the C2 software sample. Then, the sample access traffic data of the C2 software sample is decrypted to obtain the website links involved in the operation of the C2 software sample, which are used as candidate sample access addresses for the C2 software sample.

[0075] The candidate sample access address of the C2 software sample includes the cloud function service provider domain name, which means that the C2 software sample may control the cloud function provided by the candidate sample access address. The cloud function provided by the candidate sample access address is suspected to be the carrier cloud function of the C2 software sample. Therefore, the candidate sample access address is determined as the carrier cloud function sample corresponding to the C2 software sample.

[0076] The process of obtaining passive DNS resolution traffic data for the aforementioned carrier cloud function sample is as follows: Figure 6 As shown, firstly, C2 software samples are identified, and then these samples are analyzed to determine the carrier cloud function samples that are being abused by the C2 software. Next, the passive DNS resolution traffic data of these carrier cloud function samples is obtained from the passive DNS traffic database. Afterward, the temporal characteristics of the sample passive DNS resolution traffic data can be extracted to obtain the sample DNS resolution temporal characteristics of the C2 software samples.

[0077] It is worth mentioning that, in determining the sample DNS resolution timing characteristics of the C2 software sample, the sample passive DNS resolution traffic data of the carrier cloud function sample of the C2 software sample is normalized to obtain the sample DNS resolution timing characteristics of the C2 software sample, so that each feature value in the sample DNS resolution timing characteristics of the C2 software sample is within (0, 1). Correspondingly, when determining the DNS resolution timing characteristics of the cloud function to be detected, it is also necessary to normalize the passive domain name system DNS resolution traffic data of the cloud function to be detected to obtain the DNS resolution timing characteristics of the cloud function to be detected, so that each feature value in the DNS resolution timing characteristics of the cloud function to be detected is also within (0, 1). Thus, it is ensured that the feature values ​​in the sample DNS resolution timing characteristics of the C2 software sample and the DNS resolution timing characteristics of the cloud function to be detected are all within the same range (0, 1), thereby ensuring that the identification results are more accurate when the sample DNS resolution timing characteristics of the C2 software sample are used to identify the DNS resolution timing characteristics of the cloud function to be detected.

[0078] C2 software carrier identification of the cloud function under test refers to identifying whether the cloud function under test is suspected of being used as a carrier of C2 software, that is, identifying whether the cloud function under test is suspected of being a C2 software carrier cloud function. For different cloud functions that are carriers of C2 software, their temporal behavior characteristics in the domain name resolution dimension have certain similarities. The sample DNS resolution temporal characteristics of multiple C2 software samples can reflect the temporal behavior characteristics of cloud functions known as carriers of C2 software samples in the domain name resolution dimension. Therefore, based on the DNS resolution temporal characteristics of the cloud function under test and the sample DNS resolution temporal characteristics of multiple C2 software samples, it is possible to identify whether the cloud function under test is suspected of being a C2 software carrier cloud function.

[0079] In some embodiments, after obtaining the sample DNS resolution time-series features of multiple C2 software samples, the feature similarity between the DNS resolution time-series features of the cloud function to be detected and the sample DNS resolution time-series features of the multiple C2 software samples can be calculated. Based on the feature similarity, the identification result is determined. The feature similarity can be cosine similarity, Euclidean distance, or Manhattan distance, etc., between the DNS resolution time-series features of the cloud function to be detected and the sample DNS resolution time-series features of the C2 software samples.

[0080] If the similarity between the DNS resolution timing features of the cloud function to be detected and the DNS resolution timing features of multiple samples is not greater than the first similarity threshold, it means that the differences between the DNS resolution timing features of the cloud function to be detected and the sample DNS resolution timing features are relatively large. Therefore, the cloud function to be detected is determined not to be a suspected C2 software carrier cloud function. Thus, the identification result indicates that the cloud function to be detected is not a suspected C2 software carrier cloud function. The first similarity threshold can be set according to actual needs, for example, it can be 0.6.

[0081] Correspondingly, if among the feature similarities between the DNS resolution timing features of the cloud function to be detected and the DNS resolution timing features of multiple samples, there is a feature similarity greater than the first similarity threshold with at least one sample DNS resolution timing feature, it means that the difference between the DNS resolution timing features of the cloud function to be detected and at least one sample DNS resolution timing feature is small, and it can be determined that the cloud function to be detected is a suspected C2 software carrier cloud function. Thus, the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function.

[0082] S140. If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, determine that the network traffic of the cloud function to be detected is suspected C2 malicious traffic.

[0083] The network traffic of the cloud function under test refers to the traffic generated by calling the cloud function, or in other words, the access traffic of the cloud function under test. It is understandable that if the cloud function under test is identified as a suspected C2 software carrier cloud function, it indicates a high probability that the cloud function is indeed a C2 software carrier cloud function. Correspondingly, in this case, the probability of the party calling the cloud function under test being subjected to network attacks is high. Therefore, it can be determined that the network traffic of the cloud function under test is suspected malicious C2 traffic.

[0084] If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, then the network traffic of the cloud function to be detected is determined to be suspected C2 malicious traffic. If the identification result indicates that the cloud function to be detected is not a C2 software carrier cloud function, then the network traffic of the cloud function to be detected is determined to be not C2 malicious traffic.

[0085] If the network traffic of the cloud function to be detected is suspected C2 malicious traffic, a prompt message can also be output to indicate that the network traffic of the cloud function to be detected is suspected C2 malicious traffic.

[0086] In this application, the identification results of multiple cloud functions to be detected can be summarized to obtain a traffic analysis report, so that users can determine whether each cloud function to be detected is a C2 software carrier cloud function based on the traffic analysis report.

[0087] In some implementations, after S140, the method further includes: generating an alarm message if network traffic of the cloud function to be detected is detected. That is, after determining that the network traffic of the cloud function to be detected is suspected C2 malicious traffic, all traffic generated by the cloud function to be detected can be identified as C2 malicious traffic. Therefore, after detecting the network traffic of the cloud function to be detected, an alarm message can be generated to indicate the potential risk of C2 software attack, so that the user is aware of the risk or can take security measures for the cloud function to be detected.

[0088] After receiving the alarm notification, in addition to outputting the alarm notification to the user to inform them that the cloud function under test has generated malicious C2 traffic, the alarm notification can also be sent to the relevant security officer so that the relevant security officer can take timely security measures.

[0089] In some embodiments, each domain name resolution record in the passive domain name system DNS resolution traffic data of the aforementioned cloud function to be detected includes the IP address determined by the domain name resolution. When it is determined that the cloud function to be detected is a suspected C2 software carrier cloud function, the corresponding IP address determined by the domain name resolution in the domain name resolution record can be regarded as the IP address of the suspected C2 software. Therefore, the traffic generated by communication with the IP address can be obtained based on the IP address in the domain name resolution record corresponding to the cloud function to be detected, and used as the network traffic of the cloud function to be detected.

[0090] In some embodiments, after step S140, to further verify whether the network traffic of the cloud function to be detected is actually malicious C2 traffic, threat analysis can be performed on the network traffic of the cloud function to be detected to determine whether the party calling the cloud function to be detected is under network attack. For example, a threat intelligence analysis model can be used to perform threat analysis on the network traffic of the cloud function to be detected to quickly detect C2 traffic, that is, access traffic generated by C2 software.

[0091] If a cyberattack is confirmed, it can also be determined that the cloud function under investigation is a C2 software carrier cloud function, and that the network traffic of the cloud function under investigation is malicious C2 traffic. Corresponding countermeasures can then be taken. For example, if a suspicious network connection is detected to an IP address in the DNS record corresponding to the cloud function under investigation, an alarm message can be generated.

[0092] Furthermore, if it is determined that the network traffic of the cloud function to be detected is actually malicious C2 traffic, the network traffic of the cloud function to be detected can be used to update and train the threat intelligence analysis model, so that the threat intelligence analysis model can learn the access behavior characteristics of the cloud function as the carrier of C2 software, and then accurately identify the attack methods and IP addresses of C2 software.

[0093] In this embodiment, based on the passive Domain Name System (DNS) resolution traffic data of the cloud function to be detected, the DNS resolution timing characteristics of the cloud function to be detected are determined. Then, based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, the C2 software carrier of the cloud function to be detected is identified, and the identification result is obtained. If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, it means that the cloud function to be detected is highly likely to be manipulated by C2 software. Thus, it is determined that the network traffic of the cloud function to be detected is suspected C2 malicious traffic, thereby achieving the purpose of determining whether the network traffic of the cloud function to be detected is suspected C2 malicious traffic.

[0094] Secondly, the behavior of cloud functions is hidden within the infrastructure of the cloud function service provider. For C2 servers hosted on cloud functions, detailed traffic data is unavailable using existing technologies. Therefore, this application learns from the known DNS resolution timing characteristics of C2 software samples, and then extracts the DNS resolution timing characteristics of the cloud function to be detected by acquiring its passive DNS resolution traffic data. This allows for the identification of whether the cloud function to be detected is a suspected C2 software carrier cloud function. This eliminates the need to obtain detailed traffic data related to cloud functions hidden within the cloud function service provider's infrastructure, thus reducing the difficulty and improving the accuracy of C2 software carrier cloud function identification. To a certain extent, this solves the problem that external methods struggle to identify C2 software carrier cloud functions whose operating state is almost a black box.

[0095] In this application, considering the different functions provided by cloud functions, the numerical range of domain name resolution request counts in the passive DNS resolution traffic data of different cloud functions can vary greatly. The number of domain name resolution requests in the carrier cloud function samples within different C2 software samples may also differ significantly. For example, the number of domain name resolution requests in the passive DNS resolution traffic data of one cloud function may be 100-180 times per day, while the number of domain name resolution requests in the passive DNS resolution traffic data of another cloud function may be 1000-1800 times per day. Therefore, a normalization process is introduced. The number of domain name resolutions of the cloud function to be detected in each period is normalized to obtain the corresponding DNS resolution time sequence features. Similarly, the number of domain name resolutions corresponding to multiple C2 software samples is normalized to obtain the corresponding sample DNS resolution time sequence features. This avoids situations where the number of domain name resolutions of the cloud function to be detected differs greatly from that of different C2 software samples, even though the overall variation pattern is similar, leading to incorrect identification results.

[0096] In some embodiments, such as Figure 7 As shown, S130 may include:

[0097] S210. The C2 software carrier identification model is trained by using the sample DNS resolution time sequence features of multiple C2 software samples.

[0098] The C2 software carrier identification model can be a clustering model such as a decision tree model or a hierarchical clustering model, or a neural network model constructed through a neural network, such as a multilayer perceptron (MLP) or a recurrent neural network model, etc., without specific limitations.

[0099] A C2 software carrier identification model can be initialized by inputting the sample DNS resolution timing features of multiple C2 software samples as input parameters. The C2 software carrier identification model learns the domain name resolution timing features of the cloud functions controlled by the C2 software samples based on the sample DNS resolution timing features of multiple C2 software samples, thus obtaining the trained C2 software carrier identification model.

[0100] In some implementations, the C2 software carrier identification model can be a clustering model, and the C2 software carrier identification model can be trained according to the following process:

[0101] The C2 software carrier identification model can perform the (i+1)th round of clustering on the sample DNS resolution time sequence features of the multiple C2 software samples based on the multiple cluster centers determined in the i-th iteration, to obtain the (i+1)th round of clustering results; i is a positive integer, and when i=1, the multiple cluster centers in the C2 software carrier identification model are initialized; based on the sample DNS resolution time sequence features belonging to the same cluster center in the (i+1)th round of clustering results, the multiple cluster centers in the C2 software carrier identification model are updated; if the updated cluster centers in the C2 software carrier identification model determine that the iteration termination condition is not met, i is incremented by 1, and the process returns to the step of performing the (i+1)th round of clustering on the sample DNS resolution time sequence features of the multiple C2 software samples based on the multiple cluster centers determined in the i-th iteration, to obtain the (i+1)th round of clustering results, until the iteration termination condition is met.

[0102] In this embodiment, the iteration termination condition may include reaching the maximum number of iterations, or whether multiple cluster centers converge (i.e., the cluster centers remain unchanged or change only slightly). The maximum number of iterations can be set based on requirements, for example, 50 times.

[0103] In other words, the cluster centers of the C2 software carrier identification model are updated based on the sample DNS resolution time sequence characteristics of multiple C2 software samples, so that at least one updated cluster center can accurately reflect the characteristics of a class of C2 software samples.

[0104] The number of cluster centers initially set in the C2 software carrier identification model can be set as needed. For example, the number of cluster centers initially set can be the same as or less than the number of C2 software samples involved in the training. In some embodiments, before training begins, M sample DNS resolution time-series features can be selected from the sample DNS resolution time-series features of multiple C2 software samples as the feature representations of M cluster centers, where M is the number of cluster centers initially set. For example, M sample DNS resolution time-series features can be randomly selected, or M sample DNS resolution time-series features with relatively uniform distribution can be selected.

[0105] In some embodiments, after one iteration, based on the DNS resolution time sequence characteristics of samples belonging to the same cluster center in the clustering results of the (i+1)th round, the centroid or mean of the DNS resolution time sequence characteristics of samples belonging to the same cluster center is calculated and used as the updated cluster center.

[0106] In some implementations, the C2 software carrier identification model can also be a classification neural network model. Sample labels can be added to the sample DNS resolution time-series features of multiple C2 software samples. These sample labels indicate that the carrier cloud function sample of the C2 software sample is a C2 software carrier cloud function. The parameter-initialized C2 software carrier identification model is trained using the sample DNS resolution time-series features and sample labels of multiple C2 software samples to obtain a trained C2 software carrier identification model. The trained C2 software carrier identification model can classify based on the DNS resolution time-series features of the cloud function to be detected, and the classification result is used as the identification result.

[0107] The process of training the parameter-initialized C2 software carrier identification model using sample DNS resolution time-series features and sample labels of multiple C2 software samples is as follows: The sample DNS resolution time-series features are input into the C2 software carrier identification model for C2 software carrier cloud function classification, resulting in predicted labels corresponding to each sample's DNS resolution time-series features. These predicted labels indicate whether the carrier cloud function sample corresponding to the sample's DNS resolution time-series features is a C2 software carrier cloud function. Then, based on the sample labels and predicted labels corresponding to each sample's DNS resolution time-series features, the classification loss is calculated. Finally, the parameters of the C2 software carrier identification model are adjusted based on the classification loss until the training termination condition is met.

[0108] In specific embodiments, classification loss can be calculated using absolute value loss function, mean squared error loss function, cross-entropy loss function, etc.

[0109] In some embodiments, the sample DNS resolution timing features of normal cloud functions can also be used to train the C2 software carrier identification model to ensure that the trained C2 software carrier identification model has the ability to identify normal cloud functions.

[0110] The classification result can be the probability that the cloud function to be detected belongs to the cloud function of the C2 software carrier. Correspondingly, if the probability that the cloud function to be detected belongs to the cloud function of the C2 software carrier is higher than a specified threshold, the cloud function to be detected is determined to be a suspected C2 software carrier cloud function. If the probability that the cloud function to be detected belongs to the cloud function of the C2 software carrier is not higher than the specified threshold, the cloud function to be detected is determined not to be a suspected C2 software carrier cloud function. The specified threshold can be, for example, 0.6.

[0111] S220. The trained C2 software carrier identification model identifies the C2 software carrier of the cloud function to be detected based on the DNS resolution time sequence characteristics, and obtains the identification result.

[0112] After obtaining the trained C2 software carrier identification model, the C2 software carrier identification model can be used to identify the C2 software carrier of the cloud function to be detected by means of the characteristic information of the passive domain name system DNS resolution traffic of the cloud function controlled by the C2 software sample (that is, the sample DNS resolution timing characteristics) and the DNS resolution timing characteristics of the cloud function to be detected, and obtain the identification result.

[0113] As mentioned above, the trained C2 software carrier identification model corresponds to at least one updated cluster center. Based on the DNS resolution time sequence characteristics of the cloud function to be detected, the trained C2 software carrier identification model determines the probability that the cloud function to be detected belongs to each cluster center. Based on the probability that the cloud function to be detected belongs to each cluster center, the identification result is obtained.

[0114] If the probability of the cloud function to be detected belonging to each cluster center is less than the probability threshold, it means that the DNS resolution time sequence characteristics of the cloud function to be detected differ greatly from those of each cluster center, the passive DNS resolution traffic data of the cloud function to be detected differ greatly from the passive DNS resolution traffic data of multiple C2 software samples, the traffic of the cloud function to be detected is not similar to the traffic of each carrier cloud function sample, and the cloud function to be detected is not a C2 software carrier cloud function. Therefore, the identification result indicates that the cloud function to be detected is not a C2 software carrier cloud function. The probability threshold can be set based on requirements, and this application does not limit it; for example, the probability threshold is 0.7.

[0115] Correspondingly, if the probability of the cloud function to be detected belonging to a certain cluster center is not less than the probability threshold, it means that the difference between the DNS resolution timing characteristics of the cloud function to be detected and a certain cluster center is small, the difference between the passive DNS resolution traffic data of the cloud function to be detected and the passive DNS resolution traffic data of some C2 software samples is small, the traffic of the detected cloud function is similar to the traffic of some carrier cloud function samples, and the cloud function to be detected is suspected to be a C2 software carrier cloud function. Therefore, the identification result indicates that the cloud function to be detected is suspected to be a C2 software carrier cloud function.

[0116] In this embodiment, after determining that the identification result of the cloud function to be detected indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, the method may further include: updating and training the trained C2 software carrier identification model based on the DNS resolution timing characteristics of the cloud function to be detected. This achieves the goal of updating the C2 software carrier identification model in real time based on the DNS resolution timing characteristics of the cloud function to be detected, thereby improving the identification capability of the C2 software carrier identification model.

[0117] In some embodiments, the traffic detection process is as follows: Figure 8 As shown, firstly, sample passive DNS resolution traffic data of C2 software can be obtained. Then, the sample passive DNS resolution traffic data is normalized, and based on the normalized result, sample DNS resolution time sequence features of C2 software samples are constructed. Then, based on a large number of sample DNS resolution time sequence features of C2 software samples, a C2 software carrier identification model is trained so that the C2 software carrier identification model learns the features and obtains the trained C2 software carrier identification model.

[0118] Next, the passive DNS resolution traffic data of the cloud function to be detected can be obtained. Then, the passive DNS resolution traffic data is normalized, and the DNS resolution timing features of the cloud function to be detected are constructed based on the normalized results. Then, the DNS resolution timing features of the cloud function to be detected are input into the trained C2 software carrier identification model, so that the trained C2 software carrier identification model can identify the cloud function to be detected based on the DNS resolution timing features of the cloud function to be detected, and obtain the identification result of whether the cloud function to be detected is a C2 software carrier cloud function.

[0119] In this embodiment, a C2 software carrier identification model is trained using the sample DNS resolution timing features of C2 software samples. This model learns the sample DNS resolution timing features of C2 software samples, enabling it to resolve C2 software carrier cloud functions. Therefore, the trained C2 software carrier identification model analyzes the DNS resolution timing features extracted from the passive DNS resolution traffic data of the cloud function to be detected in the passive DNS traffic database. This identifies whether the cloud function to be detected is a carrier cloud function of C2 software, thus solving to some extent the problem that external methods struggle to detect the abuse of cloud functions whose operating state is almost a black box, and improving the accuracy of detecting the abuse of C2 software cloud functions.

[0120] Secondly, in this solution, the cloud function to be detected can be analyzed through the C2 software carrier identification model, eliminating the need for manual analysis. This allows for efficient identification of large-scale cloud functions using the C2 software carrier. Furthermore, it does not require knowledge of the internal operation of the cloud function infrastructure, enabling cloud function detection to rely on existing infrastructure without requiring modifications, thus reducing the detection cost and difficulty.

[0121] The traffic detection method in this application can be encapsulated into a traffic detection tool, which can be deployed on terminals, local area network devices, or servers to promptly identify cloud functions suspected of being C2 software carrier cloud functions. For example, it can be used in the following scenarios:

[0122] Enterprise network security maintenance: Deploy traffic detection tools on terminals within the enterprise's internal network. These tools integrate the traffic detection methods described in this application to detect whether C2 software carrier cloud functions are involved in the network activities of employees within the enterprise. Upon detecting suspected C2 software carrier cloud functions, they output alarm information or take security measures to prevent data leakage and malicious attacks.

[0123] Remote working environment: With the popularization of remote work, end users may work in an insecure network environment. The terminal can deploy a traffic detection tool that integrates the traffic detection method in this application. The traffic detection tool can identify whether there is suspected C2 malicious traffic in the terminal's network traffic according to the method in this application, detect potential C2 software carrier cloud functions in advance, and output alarm information or take security measures after discovering C2 software carrier cloud functions.

[0124] Cross-platform terminal protection: Traffic detection tools can be deployed on various operating systems (such as Windows, macOS, Linux) and mobile devices (such as Android, iOS). These traffic detection tools integrate the traffic detection methods described in this application to analyze the network traffic involved in the communication of the terminals, identify potential C2 software carrier cloud functions as early as possible, and ensure the security protection of all terminal devices.

[0125] Please see Figure 9 , Figure 9 This illustration shows a block diagram of a flow detection device according to an embodiment of this application. The flow detection device 900 includes:

[0126] Module 910 is used to acquire the passive Domain Name System (DNS) resolution traffic data of the cloud function to be detected.

[0127] Extraction module 920 is used to extract the DNS resolution timing features of the cloud function to be detected from passive DNS resolution traffic data;

[0128] The identification module 930 is used to identify the C2 software carrier of the cloud function to be detected based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, and obtain the identification result.

[0129] The determination module 940 is used to determine that the network traffic of the cloud function to be detected is suspected C2 malicious traffic if the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function.

[0130] Optionally, the extraction module 920 is also used to perform traffic analysis on each C2 software sample to obtain the carrier cloud function sample corresponding to each C2 software sample; obtain the sample passive DNS resolution traffic data of each carrier cloud function sample; and extract the DNS resolution time sequence features from the sample passive DNS resolution traffic data to obtain the sample DNS resolution time sequence features of the corresponding C2 software sample.

[0131] Optionally, the extraction module 920 is also used to perform the following processing on each C2 software sample: perform sandbox traffic analysis on the C2 software sample to obtain the sample access traffic data of the C2 software sample; decrypt the sample access traffic data of the C2 software sample to obtain the candidate sample access address of the C2 software sample; and select the candidate sample access address whose domain name is the domain name of the cloud function service provider from the candidate sample access address of the C2 software sample as the carrier cloud function sample corresponding to the C2 software sample.

[0132] Optionally, the identification module 930 is also used to train the C2 software carrier identification model using the sample DNS resolution timing features of multiple C2 software samples; and to identify the C2 software carrier of the cloud function to be detected based on the DNS resolution timing features after training, thereby obtaining the identification result.

[0133] Optionally, the identification module 930 is further configured to perform the (i+1)th round of clustering on the sample DNS resolution time sequence features of multiple C2 software samples based on the multiple cluster centers determined in the i-th iteration, to obtain the (i+1)th round of clustering results; i is a positive integer, and when i=1, the multiple cluster centers in the C2 software carrier identification model are initialized; based on the sample DNS resolution time sequence features belonging to the same cluster center in the (i+1)th round of clustering results, the multiple cluster centers in the C2 software carrier identification model are updated; if, based on the updated cluster centers in the C2 software carrier identification model, it is determined that the iteration termination condition is not met, i is incremented by 1, and the process returns to the step of performing the (i+1)th round of clustering on the sample DNS resolution time sequence features of multiple C2 software samples based on the multiple cluster centers determined in the i-th iteration, to obtain the (i+1)th round of clustering results, until the iteration termination condition is met.

[0134] Optionally, the extraction module 920 is also used to count the number of domain name resolution requests of the cloud function to be tested in multiple periods based on the passive DNS resolution traffic data; and to generate the DNS resolution time sequence characteristics of the cloud function to be tested based on the number of domain name resolution requests of the cloud function to be tested in multiple periods.

[0135] Optionally, the extraction module 920 is further configured to determine the maximum number of domain name resolution requests based on the number of domain name resolution requests of the cloud function to be detected in multiple periods; normalize the number of domain name resolution requests in multiple periods based on the maximum number of domain name resolution requests; and combine the normalized number of domain name resolution requests corresponding to multiple periods in chronological order to obtain the DNS resolution time sequence characteristics of the cloud function to be detected.

[0136] Optionally, the acquisition module 910 is also used to acquire the public domain names of each cloud function service provider; in the passive DNS traffic database, it acquires the passive DNS resolution traffic data of each public domain name for which the requested domain name is resolved; wherein, the requested domain name is the passive DNS resolution traffic data of a public domain name, and is the passive domain name system DNS resolution traffic data of a cloud function to be detected.

[0137] Optionally, the determination module 940 is also used to update and train the trained C2 software carrier identification model based on the DNS resolution timing characteristics of the cloud function to be detected.

[0138] Optionally, the determination module 940 is also used to generate an alarm message if network traffic of the cloud function to be detected is detected.

[0139] It should be noted that the device embodiments in this application correspond to the aforementioned method embodiments. The specific principles in the device embodiments can be found in the content of the aforementioned method embodiments, and will not be repeated here.

[0140] Figure 10 A structural block diagram of an electronic device for performing a flow detection method according to an embodiment of this application is shown. The electronic device may be... Figure 1 For server 130 or terminal 110, it should be noted that... Figure 10 The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0141] like Figure 10 As shown, the computer system 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage portion 1208 into Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0142] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0143] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0144] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0145] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0146] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0147] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium carries computer-readable instructions that, when executed by a processor, implement the methods in any of the above embodiments.

[0148] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, causing the electronic device to perform the methods of any of the above embodiments.

[0149] In the embodiments of this application, the terms "module" or "unit" refer to a part of a computer program with a predetermined function, which works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (e.g., processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that functions as a whole.

[0150] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0151] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause an electronic device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0152] Other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. It should be understood that this application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

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

Claims

1. A flow rate detection method, characterized in that, include: Obtain the passive Domain Name System (DNS) resolution traffic data of the cloud function to be tested; Extract the DNS resolution timing features of the cloud function to be detected from the passive DNS resolution traffic data; Based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, the C2 software carrier of the cloud function to be detected is identified, and the identification result is obtained. If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, then the network traffic of the cloud function to be detected is determined to be suspected C2 malicious traffic.

2. The method according to claim 1, characterized in that, Before obtaining the identification result by identifying the C2 software carrier of the cloud function to be detected based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, the method further includes: Traffic analysis is performed on each of the C2 software samples to obtain the carrier cloud function samples corresponding to each of the C2 software samples. Obtain the passive DNS resolution traffic data of each carrier cloud function sample; DNS resolution timing features are extracted from the passive DNS resolution traffic data of the sample to obtain the corresponding sample DNS resolution timing features of the C2 software sample.

3. The method according to claim 2, characterized in that, The step of performing traffic analysis on each of the C2 software samples to obtain the carrier cloud function sample corresponding to each of the C2 software samples includes: The following processing is performed on each of the C2 software samples: Sandbox traffic analysis was performed on the C2 software sample to obtain the sample access traffic data of the C2 software sample; The sample access traffic data of the C2 software sample is decrypted to obtain the candidate sample access address of the C2 software sample; Among the candidate sample access addresses of the C2 software sample, the candidate sample access addresses whose domain name is the domain name of the cloud function service provider are selected as the carrier cloud function samples corresponding to the C2 software sample.

4. The method according to any one of claims 1 to 3, characterized in that, The step of identifying the C2 software carrier of the cloud function to be detected based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, and obtaining the identification result, includes: The C2 software carrier identification model is trained by using the sample DNS resolution time sequence features of multiple C2 software samples. The trained C2 software carrier identification model identifies the cloud function to be detected based on the DNS resolution timing features, and obtains the identification result.

5. The method according to claim 4, characterized in that, The step of training the C2 software carrier identification model using the sample DNS resolution time sequence features of multiple C2 software samples includes: The C2 software carrier identification model performs (i+1) rounds of clustering on the sample DNS resolution time sequence features of the multiple C2 software samples based on the multiple cluster centers determined in the i-th iteration, obtaining the (i+1)-th round clustering result; i is a positive integer, and when i=1, the multiple cluster centers in the C2 software carrier identification model are initialized; based on the sample DNS resolution time sequence features belonging to the same cluster center in the (i+1)-th round clustering result, the multiple cluster centers in the C2 software carrier identification model are updated; If, based on the updated cluster centers in the C2 software carrier identification model, it is determined that the iteration termination condition is not met, increment i by 1 and return to the step of performing the (i+1)th round of clustering on the sample DNS resolution time sequence features of the multiple C2 software samples by the multiple cluster centers determined by the C2 software carrier identification model based on the i-th iteration, to obtain the (i+1)th round of clustering results, until the iteration termination condition is met.

6. The method according to claim 1, characterized in that, The step of extracting the DNS resolution timing features of the cloud function to be detected from the passive DNS resolution traffic data includes: Based on the passive DNS resolution traffic data, the number of domain name resolution requests of the cloud function to be detected in multiple periods is counted. Based on the number of domain name resolution requests made by the cloud function to be tested in multiple periods, the DNS resolution timing characteristics of the cloud function to be tested are generated.

7. The method according to claim 6, characterized in that, The step of generating DNS resolution time sequence characteristics of the cloud function under test based on the number of domain name resolution requests in multiple periods includes: The maximum number of domain name resolution requests is determined based on the number of domain name resolution requests made by the cloud function to be detected in multiple periods; Based on the maximum number of domain name resolution requests, the number of domain name resolution requests in the multiple periods is normalized. Based on the chronological order of the multiple cycles, the normalized number of domain name resolution requests corresponding to the multiple cycles are combined to obtain the DNS resolution time sequence characteristics of the cloud function to be detected.

8. The method according to any one of claims 1-3, characterized in that, The acquisition of passive Domain Name System (DNS) resolution traffic data for the cloud function to be detected includes: Obtain the public domain names of each cloud function service provider; In the passive DNS traffic database, the requested domain name is the passive DNS resolution traffic data of each of the aforementioned public domain names; wherein, the requested domain name is the passive DNS resolution traffic data of one of the aforementioned public domain names, and is the passive DNS resolution traffic data of a cloud function to be detected.

9. The method according to claim 4 or 5, characterized in that, If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, and after determining that the network traffic of the cloud function to be detected is suspected C2 malicious traffic, the method further includes: The C2 software carrier identification model is updated and trained based on the DNS resolution timing characteristics of the cloud function to be detected.

10. The method according to any one of claims 1-3, characterized in that, If the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function, and after determining that the network traffic of the cloud function to be detected is suspected C2 malicious traffic, the method further includes: If network traffic to the cloud function to be detected is detected, an alarm message is generated.

11. A flow detection device, characterized in that, include: The acquisition module is used to acquire the passive Domain Name System (DNS) resolution traffic data of the cloud function to be tested; The extraction module is used to extract the DNS resolution timing features of the cloud function to be detected from the passive DNS resolution traffic data; The identification module is used to identify the C2 software carrier of the cloud function to be detected based on the DNS resolution timing characteristics of the cloud function to be detected and the sample DNS resolution timing characteristics of multiple C2 software samples, and obtain the identification result. The determination module is used to determine that the network traffic of the cloud function to be detected is suspected C2 malicious traffic if the identification result indicates that the cloud function to be detected is a suspected C2 software carrier cloud function.

12. An electronic device, characterized in that, include: processor; A memory storing computer-readable instructions that, when executed by the processor, implement the method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by a processor, implement the method as described in any one of claims 1-10.

14. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the method of any one of claims 1-10.

Images