RU2777348C1 - Computing apparatus and method for identifying compromised apparatuses based on dns tunnelling detection - Google Patents

Abstract

FIELD: information security.

SUBSTANCE: computer-implemented method for identifying compromised apparatuses using DNS tunnelling includes the following stages: receiving the traffic of the protected network infrastructure; retrieving at least one DNS query from the traffic; filtering the list of identified DNS queries while excluding the queries for previously determined types of domain names therefrom; feeding each of the multiple domain names remaining in the list one by one to the input of a pre-trained deciding rule; if at least one domain name has received a negative estimation of the deciding rule, increasing the penalty for the apparatus having output at least one DNS query containing said domain name; if the total penalty of at least one apparatus exceeds the predetermined threshold, data of the device is considered compromised, wherein a notification thereof is displayed.

EFFECT: increase in the accuracy of identifying compromised apparatuses based on DNS tunnelling detection.

13 cl, 3 dwg

Description

FIELD OF TECHNOLOGY

[0001] The present technical solution relates to the field of computer technology, in particular to the field of information security, namely to a computer-implemented method and computing device for detecting compromised devices based on DNS tunneling detection.

BACKGROUND OF THE INVENTION

[0002] DNS tunneling is one of the most common ways for attackers to exchange information with a compromised device over the Internet.

[0003] This term usually means such a way of exchanging information in which the actual message is transmitted in a standard DNS query under the guise of a third-level domain name or more, for example, extremely_hidden_secret_message.domain.com.

[0004] In this case, the message is usually encrypted before being sent, so a typical domain name for DNS tunneling usually looks like this:

MV4HI4TFNVSWY6K7NBUWIZDFNZPXGZLDOJSXIX3NMVZXGYLHMU=======.domain.com.

[0005] By itself, the presence of a DNS tunnel in the outgoing traffic of a network infrastructure is generally interpreted as an indication that at least one device of this infrastructure has been compromised.

[0006] The prior art uses two approaches to detect compromised devices using DNS tunneling, which can be loosely defined as based on traffic volume analysis and payload analysis.

[0007] In the first case, when analyzing the amount of traffic, pay attention to the total number of requests to a particular domain and compare this number with average values. Since DNS tunneling is characterized by an atypically large amount of DNS traffic, namely, tens and hundreds of times greater than typical values.

[0008] Thus, US 10044748 B2 (Georgia Tech Research Corp.) describes a method for detecting compromised devices on a network based on determining the frequency of DNS requests, that is, when the frequency of requests is suspicious, processing is performed related to determining the number of DNS requests for a certain period and comparing the collected data to determine if the third level domain requests exceed the second level domain requests.

[0009] Also known is the solution described in US 10587646 B2, which produces anomaly detection of DNS traffic based on a threshold value of the number of requests per unit of time.

[0010] However, for systems implementing such approaches, low-volume sessions may go unnoticed when, for example, malware uses a DNS tunnel to surreptitiously send compromised user credentials to the command and control server, rather than downloading or uploading a file, or other significant amount of information.

[0011] When analyzing the payload, attention is paid to anomalous requests, especially if they contain atypical domain names, strange characters, etc. Most often, this approach uses various statistical techniques to detect unusually long domain names in requests.

[0012] As an example, US 10270744 B2 (Infoblox Inc.) implements an analytic system that processes DNS data, while determining the entropy of a text string in the DNS data stream based on the distribution of the character set in the text string, determines lexical features based on the characters , human-readable and non-human-readable characters in a text string determine the percentile value of the distribution of scores in N-grams from the text string in the DNS data stream, based on which patterns are generated for the detection of compromised devices.

[0013] However, this approach is also known to attackers, and they may intentionally not use domain names of the maximum available length in DNS tunneling, which complicates detection.

[0014] Thus, it becomes obvious that there is a need to develop technical solutions that would allow detecting compromised network infrastructure devices even with small amounts of data exchange and with DNS tunneling with a known "harmless" domain name length.

[0015] Another technical solution is known, which was chosen as the closest analogue to RU 2668710 C1 (IB TDS Group), which is aimed at ensuring the detection of malicious domain names in network traffic. This document describes a heuristic approach to detecting malicious domain names. However, the calculation of the harmfulness of a domain name using a combination of techniques requires large resource and time costs. In addition, the solution described later in this document can not only detect a malicious domain name, but also block the device associated with it.

[0016] Therefore, the present technical solution is designed to overcome at least one of the above disadvantages of known systems and methods for detecting compromised devices using DNS tunneling.

SUMMARY OF THE INVENTION

[0017] The technical problem to be solved by the claimed solution is the creation of a system and a computer-implemented method for detecting compromised devices based on DNS tunneling. Additional embodiments of the present invention are presented in dependent claims.

[0018] The technical result is to improve the accuracy of identifying compromised devices based on DNS tunneling.

[0019] The claimed result is achieved by implementing a computer-implemented method for detecting compromised devices using DNS tunneling, comprising the steps of: receiving protected network infrastructure traffic; extracting at least one DNS query from the traffic; filtering the list of identified DNS requests, while excluding from it requests for predefined types of domain names; each of the many domain names remaining in the list is alternately fed to the input of a pre-trained decision rule; if at least one domain name received a negative evaluation of the decision rule, increase the penalty for the device from which at least one DNS request containing this domain name left; if the amount of fines of at least one device exceeds a predetermined threshold, this device is classified as compromised, and an alert is displayed about this.

[0020] In a particular embodiment of the described method, outgoing traffic of the protected network infrastructure is received, and also incoming network traffic of the protected network infrastructure is additionally obtained.

[0021] In a private embodiment of the described method, traffic is obtained by mirroring.

[0022] In a private embodiment of the described method, for each DNS request detected in traffic, at least the following data is retrieved: domain name; The IP address of the sender and/or destination.

[0023] In a private embodiment of the described method, the entry of at least one IP address of the recipient into the black and white lists is additionally checked,

if at least one recipient IP address is found in the blacklist, then increasing the penalty for at least one device from which at least one DNS request has left, containing at least one recipient IP address;

if at least one recipient IP address is found in the white list, then filter this DNS query.

[0024] In a particular embodiment of the described method, the predefined types of domain names include at least: second-level domain names, low entropy domain names, and known trusted names from well-known reliable sources.

[0025] In a particular embodiment of the described method, at least the following methods are used as heuristic rules: separation of domains by entropy level, selection of n-grams in domain names.

[0026] In a particular embodiment of the described method, an LSTM neural network is used as statistical methods.

[0027] In a particular embodiment of the described method, the input of the decision rule of the LSTM neural network is additionally supplied with statistics of network interactions of the device from which the DNS request was received, containing the given domain name in the last T minutes and the fine of this device.

[0028] In a private embodiment of the described method, a combination of an LSTM neural network and at least one of the heuristic methods is additionally used as a decision rule.

[0029] In a particular embodiment of the described method, at least one domain name that received a negative evaluation of the decision rule is additionally searched in the history of all incoming and outgoing traffic received from at least one device of the protected infrastructure and,

if they find occurrences of at least one domain name that has received a negative evaluation of the decision rule, then all devices included in the protected infrastructure that communicate with the specified domain name,

or additional fines

or fined if they have not been fined before.

[0030] In a particular embodiment of the described method, the identified malicious domain name is additionally blocked for the entire protected infrastructure, notifications are created, template letters for notifying interested parties about the incident, and the domain name is added to at least one black list.

[0031] The claimed result is also achieved by creating a computing device configured to perform a method for detecting compromised devices based on DNS tunneling.

DESCRIPTION OF THE DRAWINGS

[0032] The implementation of the invention will be described hereinafter in accordance with the accompanying drawings, which are presented to explain the essence of the invention and in no way limit the scope of the invention. The following drawings are attached to the application:

[0033] FIG. 1 illustrates a simplified implementation of a compromised device detection system based on DNS tunneling.

[0034] FIG. 2 illustrates the sequence of stages in the implementation of the described technology for detecting compromised devices based on DNS tunneling.

[0035] FIG. 3 illustrates a simplified schematic representation of one of the non-limiting implementations of a computing device for implementing the present technical solution.

DETAILED DESCRIPTION OF THE INVENTION

[0036] In the following detailed description of the implementation of the invention, numerous implementation details are provided to provide a clear understanding of the present technology. However, one skilled in the art will appreciate how the present invention can be used, both with and without these implementation details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to unnecessarily obscure the features of the present invention.

[0037] In addition, from the foregoing it will be clear that the invention is not limited to the above implementation. Numerous possible modifications, changes, variations and substitutions that retain the spirit and form of the present invention will be apparent to those skilled in the subject area.

[0038] DNS tunneling is a technique that allows arbitrary traffic to be transmitted over the DNS protocol. To organize a DNS tunnel, it is necessary that someone outside (that is, at the point where the tunnel is directed) accept it. The receiving point is the name server for a zone. Name requests for this zone are made from within the network; this is how traffic is transmitted from within the network. As a result of the conversion, response data is returned - this is how traffic is transmitted inside the network. DNS tunneling cannot be blocked by simple firewall rules while allowing other DNS traffic. This is because DNS tunnel traffic and legitimate DNS requests are indistinguishable.

[0039] Protected network infrastructure - a set of special hardware, software and user devices, which in the text of this application can be equally designated by the general term for this set of devices, in relation to which the fact of a possible compromise is actively monitored.

[0040] The term penalty in the present description refers to the accumulated assessment of the harmfulness and / or compromise of the device over a certain period of time.

[0041] The present technology is directed to providing a computer-implemented method and system for detecting compromised devices based on DNS tunneling detection.

[0042] The disclosed computer-implemented method for detecting compromised devices based on DNS tunneling detection is performed by the system for detecting compromised devices based on DNS tunneling detection shown in FIG. 1, which at least contains: a protected network infrastructure 110, a communication network 120, a computing device for performing detection of compromised devices based on discovery-DNS tunneling 130.

[0043] The computing device 130 is also in communication with the traffic capturing devices 112 to receive from them network traffic extracted from the data network 120, and is configured to further process the received network traffic to determine malicious domain names in it used for Establishing a connection between an infected workstation or an infected computer and a command and control center followed by receiving control commands from it to perform a set of programmed malicious actions.

[0044] Accordingly, the network infrastructure to be protected comprises at least one user workstation 111, a network switch 112, which is configured to transmit (relay) all traffic of the network infrastructure 110.

[0045] In the system 100 shown in FIG. 1, the traffic capture device 112 is connected to the computing device in a wired manner, for example, using a network cable, or wirelessly, and is at least one of the following known network devices for intercepting and transmitting network traffic: L2 network switches operating with using technology that mirrors network traffic of required network segments, such as, for example, CISCO's SPAN mirroring technology for network traffic in equipment from CISCO, network transparency tools, also called Security Delivery Platforms or Network Packet Brokers (NPBs), and taps network traffic (Test Access Point) of various types, as well as proxy servers with ICAP protocol support operating within an established TCP connection, mail servers with SMTP protocol support, etc.

[0046] In one of the embodiments of the present technology, the computing device 130 can be included directly in the data network 120 or connected directly to the data network 120 with the ability to extract or capture network traffic from it for further analysis and processing in order to detect malicious domain names in the specified network traffic. In other words, in such an implementation, the computing device 130 may have the functionality of the traffic capture devices 112 described above, while the computing device 130, if necessary, can use a secure data transmission/reception channel to receive network traffic extracted from the data communication network 120.

[0047] In another further embodiment of the present technology, the network traffic capturing devices 112 described above may be incorporated or integrated into the computing device 130.

[0048] In the system 100 shown in FIG. 1, the computing device 130 is essentially a hardware and software system and includes a traffic capture module 131, a communication module 132, a filter module 133, an analysis module 134, a decision module 135, and a local data store 136, each of which is connected to the communication bus 137 , wherein each of the traffic capture module 131, the communication module 132, the filter module 133, the analyzing module 134 and the decision module 135 is configured to exchange data, via the communication bus 137, with the local data storage 136, and the traffic capture module 131 is configured with the possibility of exchanging data, via the communication bus 137, and the communication module 132 is also configured to communicate, via the communication bus 137, with the filter module 133, which in turn is configured to communicate, via the communication bus 137, with the analyzing module 134, and the analysis module 134 is communicatively connected, via a communication bus 137, with decision-making power 135.

[0049] The local data store 136 is designed to store executable program instructions that can control the operation of the traffic capture module 131, the communication module 132, the filter module 133, the analysis module 134, and the decision module 135. In addition, the local data store 136 is used in computing a device 130 for storing various data used in the operation of the computing device 130.

[0050] In particular, the local data store 136 stores data about the available analytical reports, each of which is associated with a specific domain name and each of which provides data on the numerical values of penalties assigned by the analyzing module 134 to a specific domain name, as well as data associated with the decision made by the decision module 135 in relation to the device from which the DNS request originated containing this domain name.

[0051] The local data store 136 also stores data about well-known domain names, blacklists and whitelists of domain names. It is additionally worth noting that information about blacklists and whitelists in an additional implementation can be obtained from external trusted databases (not shown) over the communication network 120.

[0052] In additional embodiments of the present technology, the local data store 136 also contains data about each of the devices 111 (for example, user devices) in the protected infrastructure 110, including the described data include at least: interaction statistics of a specific device 111 in the protected infrastructure 110 for T minutes, where the numerical value of T is selected in advance, the fines of this device, as well as notes about the fact of compromising this device 111.

[0053] In some embodiments of the present technology, at least some of the above data stored in the local data store 136 may be stored in a cloud data store (not shown), while this data may be located on a single remote file server included to the data network 120 or to another data network other than the data network 120, and on a plurality of remote file servers distributed in the data network 120 or in another data network other than the data network 120, while computing the device 130 may be configured to establish communication for data exchange, in particular a secure communication channel for receiving/transmitting data, with such a cloud storage using a wired and/or wireless connection method. In an embodiment in which the computing device 130 included in the data network 120 is connected to the cloud storage via at least one other data network other than the data network 120, a link may be used to connect these different data networks. at least one dedicated switching device, such as network hubs, also known as network hubs, network routers, and other known switching devices.

[0054] In one embodiment of the present technology, computing device 130 may include a separate local storage of analytical reports (not shown) for storing data about available analytical reports. Such a separate local storage of analytical reports can be connected, via a communication bus 137, to the filter module 133, allowing the filter module 133 to access such a local storage of analytical reports in order to obtain data from it about the available analytical reports, and also connected via a bus 137 communication, with the decision module 135 with the ability to access such a local storage of analytical reports to write a new analytical report, which will be described in more detail below.

[0055] In one embodiment, filter module 133, analysis module 134, and decision module 135 may be implemented as a single processor, such as a general purpose or special purpose processor (e.g., digital signal processors, ASICs, and etc.). Thus, the processor implementing these modules 131-135 in the computing device 130 can be configured to execute program instructions stored in the local data store 136 to implement the functionality of the traffic capture module 131 to receive traffic from the protected infrastructure 110, the filter module 133 for extracting domain name data from data packets in received network traffic, the functionality of the analysis module 134 for determining the numerical values of signs of suspicion for the analyzed domain name, and the functionality of the decision module 135 for making a final decision regarding the maliciousness of a particular device using the received set of features suspiciousness in the numerical values assigned to them.

[0056] In one embodiment of the present technology, filter module 133, analysis module 134, and decision module 135 may each be implemented as at least one separate processor capable of implementing the specific functions of the modules.

[0057] In computing device 130 of system 100 shown in FIG. 1, communication module 132 is wired, such as via a coaxial cable, twisted pair, fiber optic cable, or other physical connection, to a traffic capture device (112 or 131) to receive network traffic from them.

[0058] Thus, the communication module 132 is configured to connect to one or more of the above-described traffic capture devices (112 or 131) included in the data network 120 and to receive network traffic extracted by said traffic capture devices 112 from the network. 120 data transmission, from the specified one or more devices (112 or 131) traffic capture. In yet another embodiment of the present technology, the communication module 132 may be wirelessly connected to the traffic capturing devices (112 or 113), for example, via a WiFi technology link, a 3G technology link, an LTE technology link, and etc.

[0059] The communication module 132 in the computing device 130 according to the present technology can be implemented in the form of a network adapter equipped with the necessary connectors for connecting physical cables of the necessary types to them, depending on the types of physical connections used to communicate with devices (112 or 131) capturing traffic. In one embodiment of the present technology, communication module 132 in computing device 130 may be implemented as a network adapter in the form of a WiFi adapter, 3D adapter, LTE adapter, or other wireless adapter, depending on the type of wireless link used to provide communication. any external devices and remote data stores that can establish a wireless communication channel with a computing device to exchange the necessary data with it. Thus, communication module 132 in computing device 130 can be substantially configured to receive or receive input from one or more devices in a wired and/or wireless manner, as well as send or give output to other devices in a wired manner, and /or wirelessly.

[0060] The communication module 132 may also be any known communication device, such as a transceiver, modem, and/or network interface card for communicating with external devices of any type via a wired or wireless communication network, for example, using an Ethernet network connection. ”, digital subscriber line (DSL), telephone line, coaxial cable, cellular telephone system, etc. In some embodiments of the present technology, network traffic received by communication module 132 may be at least temporarily stored in local data storage 136 . In other embodiments of the present technology, the network traffic received by the communication module 132 may be at least temporarily stored in a separate local network traffic store (not shown), different from the local data store 136 and connected via the communication bus 137 to the communication module 132 In other embodiments of the present technology, the network traffic received by the communication module 132 may be at least temporarily stored in a separate remote network traffic store (not shown), connected with the ability to communicate with the communication module 132 in a wired and/or wireless manner.

[0061] In computing device 130 of system 100 shown in FIG. 1, filter module 133 is configured to connect or communicate, via communication bus 137, to communication module 132 to receive captured network traffic from it. The filter module 133 extracts a plurality of individual data packets that contain DNS queries from the received network traffic using, for example, known technologies for extracting DNS queries in data packets such as zeek, snort, Surikata, Bro, Kuko, and the like. . technologies, including using advanced technologies based on at least one of the above technologies. The filter module 133 is also configured to parse each of the plurality of retrieved data packets to extract at least one domain name and source and destination IP addresses from them.

[0062] In an embodiment of the present technology in which the received network traffic is stored in the local data store 136, the filter module 133 can be configured to access or communicate with the local data store 136 using the communication bus 137 to extract from it the stored network traffic for subsequent extraction of a plurality of data packets from it, as described above.

[0063] In an embodiment of the present technology in which the received network traffic is stored in a separate local network traffic store (not shown), the filter module 133 can be configured to access or communicate with such a local network traffic store using communication bus 137 to extract stored network traffic from it for subsequent extraction of multiple data packets from it, as described above. In an embodiment of the present technology in which the received network traffic is stored in a separate remote network traffic store (not shown), the filter module 133 can be configured to access or communicate with such a remote network traffic store using the communication module 132 connected to the filter module 133 via the communication bus 137 to extract stored network traffic from it for subsequent extraction of a plurality of data packets from it, as described above.

[0064] Further, after extracting the domain names from the analyzed DNS queries, in one embodiment of the present technology, the filter module 133 further determines whether there is an analysis report for each of these extracted domain names.

[0065] To detect the presence of an analytical report already created for a given domain name, the filtering module 133 performs at least the following operations: accessing or communicating with the local data store 136 using the communication bus 137 to obtain data from it about the available analytical reports, each of which is associated with a specific domain name for which this analytical report was created; establishing, by character-by-character comparison of each of the extracted domain names with domain names that identify analytic reports in the specified received data, the correspondence of each of the extracted domain names to one of the available analytic reports. Thus, the filter module 133 compares each extracted domain name with the domain names identifying the analytics in the received analytics data, wherein the match of the extracted domain name with the domain name identifying one of the available analytics means that for the extracted domain name there is already an analysis report stored in the local data store 136, which indicates that the retrieved domain name has already been previously analyzed in the computing device 130.

[0066] In an implementation in which data about analytical reports are stored in a separate local repository of analytical reports (not shown), the filter module 133 accesses or communicates with such a local repository of analytical reports using the communication module 132 to obtain from It contains data about available analytical reports, each of which is matched with a specific domain name for which this analytical report was created, in order to subsequently match the extracted domain name to one of the available analytical reports.

[0067] Thus, the filter module 133 provides the ability to filter at least part of the domain names extracted from the data packets of the received network traffic, using the minimum computing resources of the computing device 130, which ultimately significantly speeds up the process of detecting malicious domain names in network traffic .

[0068] Subsequently, the filter module 133 transmits to the parsing module 134 only those extracted domain names for which there is no analytical report in the local data store 136, that is, only those domain names that have not previously been parsed in the computing device 130, in particular in its decision module 135.

[0069] In computing device 130 of system 100 shown in FIG. 1, the parsing module 134 is configured to connect to or communicate with the filtering module 133 using the communication bus 137 so as to be able to obtain information from it, for example, about domain names for which the filtering module 133 has detected the absence of an analysis report, as described above. .

[0070] In an embodiment of the present technology, in which the domain names extracted by the filter module 133 are stored in the local data store 136, the parsing module 134 accesses or communicates with the local data store 136 using the communication bus 137 to obtain from it data about the extracted domain names to be further analyzed in this parsing module 134, as will be described below.

[0071] In another embodiment of the present technology, in which the domain names extracted by the filter module 133 are stored in a separate local data store, the parsing module 134 accesses or communicates with such a local data store using the communication bus 137 or via wireless communication channel through the communication module 132 to receive from it data about the extracted domain names to be further analyzed in this analyzing module 134, as will be described below.

[0072] The parsing module 134 analyzes each of the received domain names using a predetermined set of suspiciousness analysis techniques or methods to assign a predetermined numerical penalty value to each of the received domain names.

[0073] In particular, the operation of the analyzing module 134 is based on a decision rule, on the basis of which a verdict is made regarding the harmfulness or harmlessness of a particular domain name using a set of signs of suspiciousness of this domain name, and is indicative of the potential harmfulness of the device (user device 111 ) for the decision module 135. Both heuristic and statistical algorithms, including machine learning algorithms (MLA), can act as a decision rule. An example of a heuristic rule can be the division of domains according to the level of entropy in such a way that domains with a high level of entropy are recognized as suspicious, that is, domain names whose entropy level exceeds a predetermined empirically derived threshold are recognized as suspicious. There are also possible approaches based on heuristic methods, such as extracting n-grams and then calculating the entropy of domain names.

[0074] One of the implementation examples is based on an LSTM neural network, where on the first layer the dimension of the feature space is normalized and reduced in a well-known way, after it comes the first training layer, directly LSTM with empirically derived coefficients. The next layer cleans up the results in a known way. After that, there are two additional intermediate layers, and on the last one, a binary verdict is established: whether the domain is suspicious.

[0075] In one implementation, the analysis module 134 may be based on a set of decision rules, each of which makes its own decision or makes its own verdict regarding the harmfulness or harmlessness of a particular domain name using the same set of signs of suspiciousness of this domain name . In one variation of this embodiment of the present technology, the final verdict on the harmlessness of the domain name may be issued by the parsing module 134, for example, in the case in which at least one of the given set of decision rules or all of the given set of decision rules rendered a verdict on otherwise, in which none of the predetermined set of decision rules rendered a verdict on the harmlessness of the domain name, module 134 may render a final verdict on the harmlessness of the domain name. In another variant of this embodiment, the parsing module 134 may make its final verdict on whether a domain name is harmful or not by comparing the total weight of the personal verdicts made by a given set of decision rules, with any personal verdict made by each decision rule in the given set automatically assigned its own predefined weighting factor. Thus, the parsing module 134 renders one or another final verdict, taking into account all intermediate verdicts that have one or another weight in the total weight taken into account for the final verdict.

[0076] In one of the embodiments of the present technology, the analyzing module 134 can be equipped with a special framework (software platform) that allows, for example, the operator or user of the computing device 130 to change a given set of methods for analyzing the harmfulness of the domain name used by the analyzing module 134 to obtain a verdict of harmfulness a domain name corresponding to one of a given set of analysis techniques, for example, a selection of a group of heuristic techniques described below or machine learning algorithms, which provides an extension of the functionality of both the analyzing module 134 individually and the computing device 130 as a whole. In addition, this framework serves to obtain data on the value of time T, which determines the statistics of the interaction of a particular device 111 and the protected infrastructure 110.

[0077] After the final verdict is reached, the analysis module 134 and prepares or generates a separate analysis report for each examined domain name, and such an analysis report at least contains all the information from the corresponding log file created during the analysis process for the specified domain name, and also data on the final verdict made by the parsing module 134 in relation to the domain name, as well as data on the decision rule used by the parsing module 134. may contain data about each of the decision rules used to make the final verdict, and data about the verdicts of each of the decision rules regarding the harmfulness or harmlessness of the domain name.

[0078] In some embodiments of the present technology, the analysis module 134 may be divided into several independent modules, each of which can perform at least one of the above-described functionality inherent in the analysis module 134, and which are configured to communicate with each other and the rest constructive modules of the computing device 130 using the communication bus 137. In this case, one of these independent modules may be configured to create at least one log file, or there may be, for example, an additional module for creating log files, configured to communicate with by the specified independent modules using, for example, the communication bus 137 with the provision of obtaining from each of them, for example, data on a specific sign of suspicion with a numerical value assigned to it for the same domain name.

[0079] To save a prepared or created analytical report in the local data store 136, the analyzing module 134 accesses or communicates with the local data store 136 using the communication bus 137 to ensure that the specified analytical report is transferred to the local data store 136 for saving . In addition, an implementation option is possible when the prepared or created analytical report is stored in a separate local storage of analytical reports (not shown).

[0080] In computing device 130 of system 100 shown in FIG. 1, the decision module 135 is configured to connect to or communicate with the analysis module 134 using a communication bus 137 to receive from it log files prepared or created by the analysis module 134.

[0081] The decision module 135 analyzes the penalties associated with each domain name with their assigned numerical values contained in each of the received log files, using a given set of analysis rules, ensuring that each domain name for which a corresponding log has been created is assigned. file, to malicious domain names, if the results of the analysis of signs of suspicion are characteristic of malicious domain names, or to trusted domain names, if the results of the analysis of signs of suspicion are characteristic of trusted domain names. Thus, the decision module 135 makes a final decision or renders a final verdict regarding the compromised devices based on the assessment of the harmfulness or harmlessness of the domain name using the log file generated by the parsing module 134 for each retrieved domain name.

[0082] It should be noted that the communication module 132, the filter module 133, the analysis module 134 and the decision module 135 implement their above-described functions essentially in real time, that is, the communication module 132 continues to receive network traffic, the filter module 133 performs its operations filtering at least part of the DNS queries extracted from the data packets in the received network traffic, based on predefined types of domain names, the parsing module 134 performs its operations of parsing domain names and assigning them suspicious signs - fine values, followed by the creation of a log - file for each domain name separately, and the decision module 135 performs its operations of parsing at least a portion of the log files received from the parsing module 134 and storing at least a portion of the generated or prepared analytical reports in the local data store 136.

[0083] In one embodiment of the present technology, the functional modules described above may be separated or combined while retaining the inherent functions of each. For example, the analyzing module 134 and the decision module 135 can be combined, for example, into one module for detecting malicious domain names and, based on them, identifying compromised devices 111, a protected infrastructure, having all the above-described functionality inherent in each of them separately. Alternatively, in yet another embodiment of the present technology, the filter module 133 and the analysis module 134 may be combined, for example, into one module having all of the above-described functionality inherent in each of them separately.

[0084] As another embodiment of the present technology, communication module 132 may be divided into multiple separate communication modules, each of which provides at least one of known wired and/or wireless communication methods to computing device 130.

[0085] According to another aspect, a method for detecting compromised devices using DNS tunneling is provided, shown as a simplified flowchart in FIG. 2.

STEP 210 RECEIVING TRAFFIC OF PROTECTED NETWORK INFRASTRUCTURE

[0086] At the first step of the implementation of the described technology, the traffic of the protected network infrastructure 110 is received on the device 130 via the data network 120.

[0087] The operations at this stage of the implementation of the claimed method 200 include connecting, via the communication module 132, to at least one of the network traffic capture devices included in the data network (112 or 131).

[0088] In this case, the traffic of the protected network infrastructure can be understood as outgoing traffic of the protected network infrastructure, as well as additionally incoming network traffic.

[0089] It is worth noting that the acquisition of traffic can be carried out by any method known in the art, for example, mirroring.

[0090] By way of example, but not limitation, mirroring is accomplished by duplicating packets transmitted through one port of network switch 112 to another for receipt by computing device 130. It is worth noting that most modern network switches allow traffic to be duplicated through built-in features. In addition, it is additionally possible to use, for example, the tcpdump console utility, which is included in most Unix systems and allows you to intercept and display network traffic by the traffic capture module 131.

[0091] After receiving traffic from the protected network infrastructure 110, it is stored in the database 136 of the computing device 130.

[0092] Next, the present technology proceeds to analyze the received traffic by the methods described below.

STEP 220 EXTRACT AT LEAST ONE DNS REQUEST FROM THE TRAFFIC

[0093] The analysis of the traffic received in the previous step begins at step 220, at which at least one DNS query is extracted from it.

[0094] Extracting at least one DNS query from the traffic can be performed by the computing device 130 through the filter module 133 based on any method known in the art, for example, using a specially written parser or network traffic analysis services.

[0095] As an example of the implementation of this technology, but not limited to, the following tools can be used to detect DNS queries: zeek, snort, Suricata, etc. However, it is worth noting that the use of such tools allows you to get a complete picture of what is happening on the network over all the most popular protocols: HTTP, DNS, TLS, SMB, FTP, RDP, SSH, ICMP, etc., including industrial protocols s7, iec104, opcua, etc.

[0096] In one of the additional embodiments of the described technology through the filter module 133, for each DNS request detected in traffic, at least the following data is retrieved: domain name; Sender and destination IP addresses.

[0097] Additionally, at the described step of implementing the method 200, there may be a step of checking for the presence of an analytical report associated with the investigated domain names in the local data store 136 and may include performing, through the filter module 133, at least the following sub-steps: (i) obtaining data about analytical reports; (ii) establishing, by character-by-character comparison of each of the extracted domain names with domain names identifying analytics in said retrieved data, that each of the extracted domain names matches one of the available analytics. In some embodiments of the present invention, in response to the fact that there is no analysis report for the extracted domain name, according to the proposed method, the specified domain name is transmitted, by means of a filter module, to the analysis module 134.

[0098] If the filter module 133 retrieves an analytical report that indicates the legitimacy of the domain name, then all DNS queries containing the domain name specified in the report are filtered out (excluded from further analysis). In the opposite case, when the filtering module 133 extracts an analytical report containing information about the maliciousness of the domain name, then in the traffic of the protected infrastructure 110 they search for all devices 111 that interact with the identified domain name and charge a fine for the detected devices 111, in accordance with the rules which will be described later (step 250).

[0099] Further, all requests identified in the traffic are stored in the local data store 136 of the system 100 in the form of a list containing a DNS query and its corresponding domain name; Sender and/or destination IP addresses.

STEP 230 FILTERING THE LIST OF DETECTED DNS REQUESTS AND EXCLUDING REQUESTS FOR PRE-DETERMINED TYPES OF DOMAIN NAMES.

[0100] Further, during the second stage of analysis, the list stored in the local data store 136 is filtered by the filter module 133. request sent.

[0101] The types of domain names that are filtered, that is, excluded from a pre-generated list, include at least the following: second-level domain names, domain names with low entropy, as well as known trusted names from well-known reliable sources.

[0102] Thus, by means of the filter module 134, second-level domain names are additionally excluded from the list stored in the local data store 136. This performs at least the following operations: (i) establishes a connection with the data store, including a separate local 136 or remote trusted store of domain names (not shown), depending on the implementation, as described above to obtain a list of domain names from it , (ii) convert each domain name to a string and check the number of dots in that string (iii) depending on whether the number of dots in the string is greater than one (corresponding to a second-level domain name), the domain name is either filtered and marked as a trusted domain name name, or remains in the list.

[0103] It is worth noting that the features that allow the determination of the use of tunnels include the entropy of domain names. Ordinary domain names usually consist of English words; such names have low entropy. At the same time, encoded data (and DNS tunneling tools encode data that is placed in a DNS query) has a high entropy. Thus, domain names that have high entropy may indicate that tunneling is being used. Based on this, at this stage of the implementation of this technology, it is proposed to filter those domain names that have low entropy.

[0104] Determining the entropy of a domain name can be performed by any well-known method through the filter module 133. As an example, but not limited to, the entropy can be determined by the method described below.

[0105] As an exemplary implementation of the present technology, at least the following sub-steps may be performed in the filter module for sorting domain names having low entropy: (i) determining the frequency of occurrence of each of the set of given N-grams in each of the received domain names, while each N-gram corresponds to a combination of N consecutive characters. N-grams may be obtained from local data store 136, or from a wirelessly connected data store; alternatively, they can be set by the operator in a special interface of the computing device 130; (ii) determining the entropy of the N-grams of said analyzed domain name as a function of the determined frequency of occurrence of each N-gram in that analyzed domain name. The calculation itself can be carried out by any method known in the art; (iii) comparing the determined N-gram entropy of the analyzed domain name with a predetermined N-gram entropy threshold that identifies low entropy domain names; the threshold value is pre-determined empirically; (iv) filtering out (exclusion) of domain names whose entropy is below a given threshold value.

[0106] Also, by means of the filter module 134, the list stored in the local data store 136 further excludes known trusted names previously obtained from well-known reliable sources. This performs at least the following operations: (i) establishes a connection with the data store, including a separate local 136 or remote trusted domain name store (not shown), depending on the implementation option, as described above to obtain from it a set of known trusted domain names, (ii) determine, by character-by-character comparison of each of the extracted domain names with the domain names in the resulting set of domain names, a match of each of the extracted domain names with one of the known domain names, and (iii) depending on the result of the match, the domain name either filtered out and marked as a trusted domain name, or left.

[0107] Alternatively, in additional implementations, it is possible that the step of filtering requests for known trusted names from well-known reliable sources can be skipped and performed in a subsequent step using the parsing module 134, being included in the formation of training samples of the decision rule.

[0108] In some additional implementations of the present technology, domain names may also be encoded by any well-known method to support localized domain names, that is, domain names consisting not of the Latin alphabet, but of characters from other national alphabets, such as, for example, domain.name .in.Russian.rf.

[0109] In one embodiment of the present technology, if the domain name is found in a locally accessible database 132 in the system 100 or a trusted database accessed over the network, then the method proceeds to the last step of the present technology, which will be discussed in detail. below (step 260).

[0110] In one implementation, this step further checks at least one extracted source IP address and/or destination IP address against well-known trusted sources and against the whitelist and blacklist stored in database 136. This may be performed the method described above for checking domain names. Moreover, depending on the result of establishing a match, the domain name associated with the set IP address of the sender and / or addressee is either filtered and marked as a trusted domain name, or proceeds to the next stage described below, or is blocked if found in the black list or in a database, for example, of web resources that are known to be owned by cybercriminals.

STEP 240 EACH OF THE MULTIPLE DOMAIN NAMES REMAINING IN THE LIST ARE SUPPLIED IN TURN TO THE PRE-LEARNED DECISION RULE.

[0111] In the embodiments of the described technology, the operations performed in step 240 of the method 200 include analysis, by means of the analyzing module 134, of the obtained set of signs of suspiciousness of the analyzed domain name using at least one pre-compiled decision rule, which can be both heuristic algorithms and and statistical, incl. machine learning algorithms.

[0112] In one of the described embodiments of the present technology, heuristic rules act as a decision rule. So, an example of a heuristic rule can be the division of domains according to the level of entropy in such a way that domains with a high level of entropy are recognized as suspicious. Moreover, the threshold level of entropy is determined empirically. Approaches based on the selection of N-grams and the subsequent calculation of their entropy, as well as the comparison of the calculated entropy with a predetermined threshold value, are also possible.

[0113] In addition, embodiments of the present technology are possible when several heuristic approaches are used in parallel and their results are brought to a single binary assessment, that is, the decision can be one of two: the domain name is malicious or not. In this case, the analyzing module 134 is configured to assign a reliability coefficient to each heuristic rule used in the process of obtaining the final score and to derive a single assessment of the suspiciousness of the domain based on these coefficients, while the analyzing module 134 is configured to implement any known heuristic algorithms for determining the harmfulness of a domain name , for example, machine learning algorithms such as neural networks, decision trees, boosting algorithms, and signatures.

[0114] In one of the described embodiments of the present technology, a pre-trained neural network can act as a decision rule.

[0115] By way of illustration, but not limitation, an LSTM neural network can be used as a decision rule based on a neural network. LSTMs are networks with long-term short-term memory (is a member of the family of recurrent networks, RNN), they allow you to analyze dependencies in a sequence of data.

[0116] Next, the designed neural network uses vector representations of the input domain name prefix characters as features for learning. The prefix in this implementation is considered to be a part of the domain, composed of subdomains of the third and higher levels. For example, for the domain aaaa.drive.google.com, the prefix would be the string "aaaa.drive".

[0117] In embodiments of the present technology, determination of the domain name prefix may be performed in any known manner. Thus, as an illustration, a specially written script can be used, in the implementation of which a generic top-level domain (gTLD) and/or a country code top-level domain (ccTLD), which are generic top-level domains, are first allocated using well-known methods. For example, in the URL https://www.xyz.example.com/doc.html, example.com is the second-level domain and a.com is the generic top-level domain (gTLD). Similarly, in https://www.example.ac.ru/ example.ac.ru is a generic second-level domain, a.ru is a country code TLD (ccTLD). Next, a lower-level subdomain is allocated and also excluded from the prefix.

[0118] The above operations, as an example, can be implemented through a script written in Python using the 'tldextract' library, which uses well-known domain suffix directories, including PUBLIC SUFFIX LIST (https://publicsuffix.org /). A simplified version of the results obtained by executing the specified script is presented below:

tldextract.extract('http://forums.news.cnn.com/')

ExtractResult(subdomain-'forums.news', domain-cnn', suffix-'com').

[0119] It is worth noting that, in addition to the domain name, the decision rule input is additionally fed the statistics of network interactions collected over the last T minutes of the device from which the DNS request containing this domain name was received, and the fine of this device.

[0120] Statistics in the context of this description refers to the number of interactions on the above protocols in the last T minutes, and for protocols over TCP this is the number of sessions, and for UDP protocols this is the number of datagrams.

[0121] In various embodiments, the number of T minutes may be set manually by an expert or user of the computing device 130, or may be set automatically, for example, depending on the number of devices in the protected infrastructure 110.

[0122] It is worth noting that the built neural network can also function with zero statistics parameters, but T is assumed to be small, that is, as an example, but not limited to 10 minutes, respectively, these statistics will appear quickly.

[0123] With regard to the user device penalty 111, its value is initially set to zero, which changes with the number of iterations in the system 100 in a manner described in more detail below. In this case, all intermediate values of fines are stored in the local data storage 136.

[0124] In embodiments of the present technology, training samples can be formed both in an isolated stand, and in "combat" conditions, within an operating and highly loaded network using well-known methods for building DNS tunnels. For example, such methods include the use of special utilities such as _NameServer (NSTX), Dns2tcp, lodine, dnscat2, etc.

[0125] The following will describe the general points of building a neural network for example. On the first layer, the dimension of the feature space is normalized in a well-known way. As an example of a feature space normalization procedure, all identified domains are padded to a length of 256 with special characters on the right.

[0126] After this layer comes the first training layer, directly LSTM with empirically derived coefficients. These coefficients are formed directly at the training stage, when labeled samples of domain names are loaded into the neural network, i.e. those for which the verdict is known in advance, i.e. the fact that they belong to malicious or non-malicious. It should be noted that these samples can be obtained both from external trusted sources and by an empirical method, for example, by manually setting the "harmful" flag for malicious domain names. In addition, the above data is also enriched with legitimate tagged domain names. That is, the analysis module 134 based on the LSTM neural network receives at the preparatory stage both marked malicious and legitimate domain names, on the basis of which the LSTM neural network generates coefficients, which are then used in the classification (prediction) mode.

[0127] The next layer of the LSTM neural network cleans up the results of the previous one to obtain the most reliable results. In the prior art there are many cleaning methodologies that can be implemented for this technology, one example of such methods is the rejection of a part of the extreme (maximum and minimum) values obtained during the analysis, for example, 25% of both.

[0128] After that, there are two additional intermediate layers that serve to enable the LSTM neural network to extract longer chains of dependencies as features. Empirically, it has been established that a given number of internal layers gives the necessary balance of speed and errors. At the last layer of the neural network, a binary verdict is issued: is the domain malicious.

[0129] The positive or negative evaluation of the domain name received in the analyzing module 134 is stored in the local data store 136.

STEP 250 IF THE DOMAIN NAME GOT A NEGATIVE DECISION VALUE, INCREASE THE PENALTY FOR THE DEVICE FROM WHICH THE DNS REQUEST CONTAINING THE DOMAIN NAME WAS GONE

[0130] Next, the verdict from the analyzing module 134 is passed to the decision module 135, where, based on the parameters described below, a decision is made on whether a device has been compromised and on the degree of its harmfulness.

[0131] Thus, the decision module 135 checks the evaluation of the decision rule embedded in the analysis module 134, and if the domain name received a negative evaluation of the decision rule, increases the value of the penalty stored in the local data store 136 for the device from which the DNS request left The that contained the examined domain name.

[0132] In one additional implementation, the decision module 135 additionally searches for a specific domain name in the history of all incoming and outgoing traffic received from the protected infrastructure 110. Moreover, it is worth noting that this considers not only DNS queries. If the decision module finds other occurrences of a particular domain name, then all devices 111 of the protected infrastructure 110 communicating with this domain name either additionally penalize or penalize them if they did not penalize at the last discovery.

[0133] In one of the additional implementation options, the decision-making module 135 is additionally configured to block the detected malicious domain name for the entire protected infrastructure 110, create notifications (alerts), template letters to notify interested parties about the incident, blacklisting, available by communication network to computing device 130, etc.

[0134] In one of the additional implementation options, the decision module 135 is further configured to extract from the local data store 136 at least one IP address of the sender and / or destination that correlates with a malicious domain name, definitions in the local data store 136 at least at least one additional domain name that is located at the same extracted IP address, as well as identifying all devices 111 of the protected infrastructure 110 that communicated with at least one additionally identified domain name and adding a penalty to these devices.

[0135] It is worth noting that the decision module also updates the blacklist (list of malicious domain names) that is used in the filtering step in the filter module 133 to reduce processing time and instantly issue a verdict on a similar request.

[0136] In addition, the decision module processes the received penalty values of each device 111 and makes a decision about its compromise.

STEP 260 WHEN THE SUM OF PENALTY ON AT LEAST ONE DEVICE EXCEEDS A PRESET THRESHOLD, THIS DEVICE IS CLASSIFIED AS COMPROMISED AND A NOTIFICATION IS DISPLAYED ABOUT THIS.

[0137] The decision module 135 is configured to check if the amount of fines of each device (device 111) exceeds a predetermined threshold, classify it as compromised if the threshold is exceeded, and output notifications, messages, alerts, etc. about this incident.

[0138] The penalty threshold is chosen empirically based on device compromise statistics, frequency of interaction with malicious domain names, and so on.

[0139] In one of the additional implementation options, the decision module 135 is additionally configured to identify all contacts (interactions) of the identified compromised device 111 within the protected infrastructure 110. Moreover, special attention is paid to remote control protocols. In the case of a large number of critical operations, such as launching applications remotely, accessing shared resources, etc. when interacting with some other device 111, it is also penalized and then checked to see if the penal exceeds the compromise threshold.

[0140] It is worth further noting that the implementation of the method 200 described above is also possible in specific networks. The claimed technology shows particular effectiveness in networks with strict security policies. For example, in a network of video cameras, interactions over all network protocols will most likely be disabled, except for the protocol necessary for transmitting video information. The DNS protocol is required to provide routing on a network and is generally allowed even on such networks. In this case, it is highly likely that attackers will use DNS as a transport to exfiltrate data.

[0141] In FIG. 3, the general scheme of the computing device 130 will be presented below, providing the data processing necessary to implement the claimed solution.

[0142] In general, device 300 includes components such as: one or more processors 301, at least one memory 302, data storage 303, I/O interfaces 304, I/O 305, networking 306.

[0143] The processor 301 of the device performs the basic computing operations necessary for the operation of the device 300 or the functionality of one or more of its components. The processor 301 executes the necessary machine-readable instructions contained in the main memory 302.

[0144] The memory 302 is typically implemented as RAM and contains the necessary software logic to provide the desired functionality.

[0145] The storage medium 303 may be in the form of HDD, SSD disks, raid array, network storage, flash memory, optical storage media (CD, DVD, MD, Blue-Ray disks), etc.

[0146] Interfaces 304 are standard means for connecting and working with the server side, for example, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire, and the like. The choice of interfaces 304 depends on the specific implementation of device 300, which may be a personal computer, mainframe, server cluster, thin client, smartphone, laptop, and the like.

[0147] The data I/O means 305 can be a keyboard, joystick, display (touchscreen), projector, touchpad, mouse, trackball, light pen, speakers, microphone, and the like.

[0148] Means of networking 306 are selected from devices that receive and transmit data over the network, for example, an Ethernet card, WLAN / Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFTD module, GSM modem, etc. .P. With the help of means 305, the organization of data exchange over a wired or wireless data transmission channel, for example, WAN, PAN, LAN (LAN), Intranet, Internet, WLAN, WMAN or GSM, is provided.

[0149] The components of the device 130 are interfaced through a common data bus 310.

[0150] In the present application materials, a preferred disclosure of the implementation of the claimed technical solution was presented, which should not be used as limiting other, private embodiments of its implementation, which do not go beyond the scope of the requested legal protection and are obvious to specialists in the relevant field of technology.

[0151] Modifications and improvements to the above described embodiments of the present technical solution will be clear to specialists in this field of technology. The foregoing description is provided by way of example only and is not intended to be limiting in any way. Thus, the scope of the present technical solution is limited only by the scope of the appended claims.

Claims (28)

1. A computer-implemented method for detecting compromised devices using DNS tunneling, comprising the steps of: receive traffic of the protected network infrastructure; extracting at least one DNS query from the traffic; filtering the list of identified DNS queries, while excluding from it requests to predefined types of domain names; each of the many domain names remaining in the list is alternately fed to the input of a pre-trained decision rule; if at least one domain name received a negative evaluation of the decision rule, increase the penalty for at least one device from which at least one DNS request containing this domain name left; if the amount of fines for at least one device exceeds a predetermined threshold, this device is classified as compromised, and a notification is given about it. 2. A computer-implemented method according to claim 1, in which outgoing traffic of the protected network infrastructure is received, and also incoming network traffic of the protected network infrastructure is additionally received. 3. The computer-implemented method of claim 1, wherein the traffic is received by mirroring. 4. The computer-implemented method according to claim 1, wherein for each DNS query detected in traffic, at least the following data is retrieved: domain name; Sender and destination IP addresses. 5. The computer-implemented method according to claim 4, which additionally checks whether at least one recipient IP address is in the black and white list, if at least one recipient IP address is found in the black list, then increase the penalty for at least one device from which at least one DNS request has left, containing at least one recipient IP address; if at least one recipient IP address is found in the white list, then filter this DNS query. 6. The computer-implemented method of claim 1, wherein the predefined domain name types include at least: second level domain names, low entropy domain names, and known trusted domain names from well-known reliable sources. 7. A computer-implemented method according to claim 1, in which at least the following heuristic methods are used as a decision rule: separation of domains by entropy level, selection of n-grams in domain names. 8. The computer-implemented method of claim 1, wherein an LSTM neural network is used as the decision rule. 9. The computer-implemented method according to claim 8, in which the input of the LSTM neural network is additionally supplied with statistics of network interactions for the last T minutes of the device from which the DNS request containing the given domain name was received, and the fine of this device. 10. The computer-implemented method of claim 1, further comprising using a combination of an LSTM neural network and at least one of the heuristic methods as a decision rule. 11. The computer-implemented method of claim 1, further comprising searching for at least one domain name that received a negative decision rule score in the history of all incoming and outgoing traffic received from at least one protected infrastructure device and, if they find occurrences of at least one domain name that received a negative evaluation of the decision rule, then all devices included in the protected infrastructure and communicating with the specified domain name, or additional fines or fined if they have not been fined before. 12. The computer-implemented method according to claim 1, in which the detected malicious domain name is additionally blocked for all devices included in the same protected infrastructure, notifications about the maliciousness of the domain name are created, template letters are created to notify interested parties about the incident, and the domain name on at least one black list. 13. A computing device for detecting compromised devices based on DNS tunneling, configured to perform a method for detecting compromised devices based on DNS tunneling according to any one of paragraphs. 1-12.

Images