Online Detection of Algorithmically Generated Domains

Abstract

Detection of algorithmically generated domains is disclosed. A DNS query is received. A Markov chain analysis is performed on a domain included in the received query. A determination is made, based at least in part on a result of the Markov chain analysis, whether the received query relates to an algorithmically generated domain.

Description

Background Art

[0001] Criminals attempt to compromise computer systems in a variety of ways. As an example, such a person may embed or otherwise include malicious software ("malware") in an email attachment and transmit or cause the malware to be transmitted to an unsuspecting user. When executed, the malware compromises the victim's computer. Certain types of malware will instruct the compromised computer to communicate with a remote host. For example, malware can turn a compromised computer into a "bot" in a "botnet", thereby receiving instructions from and / or reporting data to a command and control (C&C) server under the control of the criminal. One way to mitigate the damage caused by malware is for security companies (or other appropriate entities) to try to identify the malware and prevent it from reaching / executing on an end-user computer. Another way is to try to prevent the compromised computer from communicating with the C&C server. Unfortunately, malware authors are using increasingly sophisticated techniques to obfuscate how their software works. Therefore, there is a continuing need for improved techniques for detecting malware and preventing its damage. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings:

[0003] Figure 1 illustrates an example of an environment in which malware is detected and its damage is mitigated;

[0004] Figure 2A An embodiment of a data device is illustrated;

[0005] Figure 2B is a functional diagram of the logical components of an embodiment of a data device;

[0006] Figure 3 A visual representation of a portion of an example Markov chain model is depicted;

[0007] Figure 4A The difference between the parse counts of algorithmically generated domains and benign domains is illustrated;

[0008] Figure 4B An example of the difference between the resolution intervals of algorithmically generated and benign domains is illustrated;

[0009] Figure 5 An example of a process for detecting algorithmically generated domains is illustrated. DETAILED DESCRIPTION

[0010] The present invention may be implemented in a variety of ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. In this specification, these implementations or any other form that the present invention may take may be referred to as techniques. In general, the order of steps of the disclosed processes may be changed within the scope of the present invention. Unless otherwise stated, a component such as a processor or memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform a task at a given time, or manufactured as a specific component that performs the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores that are configured to process data such as computer program instructions.

[0011] A detailed description of one or more embodiments of the present invention is provided below, as well as drawings illustrating the principles of the present invention. The present invention is described in conjunction with these embodiments, but the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention includes many alternatives, modifications and equivalents. In order to provide a thorough understanding of the present invention, many specific details are set forth in the following description. These details are provided for illustrative purposes, and the present invention can be practiced according to the claims without some or all of these specific details. For the sake of clarity, technical materials known in the technical field related to the present invention are not described in detail to avoid unnecessarily obscuring the present invention.

[0012] I. Overview

[0013] A firewall generally protects a network from unauthorized access while allowing authorized communications to pass through the firewall. A firewall is typically a device, a set of devices, or software executed on a device that provides firewall functionality for network access. For example, a firewall can be integrated into the operating system of a device (e.g., a computer, a smart phone, or other type of device with network communication capabilities). A firewall can also be integrated into or executed as one or more software applications on various types of devices, such as computer servers, gateways, network / routing devices (e.g., network routers), and data devices (e.g., security devices or other types of dedicated devices), and in various implementations, certain operations can be implemented in dedicated hardware such as ASICs or FPGAs.

[0014] Firewalls typically deny or allow network transmissions based on a set of rules. These rule sets are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted external traffic from reaching the protected device. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allowing, blocking, monitoring, notifying, or logging, and / or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria, such as described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

[0015] Security devices (e.g., security appliances, security gateways, security services, and / or other security devices) may include various security functions (e.g., firewalls, anti-malware, intrusion prevention / detection, data loss prevention (DLP), and / or other security functions), networking functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other networking functions), and / or other functions. For example, routing functions may be based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.

[0016] Basic packet filtering firewalls filter network traffic by inspecting individual packets as they travel over the network (e.g., packet filtering firewalls or first generation firewalls, which are stateless packet filtering firewalls). Stateless packet filtering firewalls typically inspect individual packets themselves and apply rules based on the packets inspected (e.g., using a combination of the packet's source and destination address information, protocol information, and port numbers).

[0017] Application firewalls can also perform application layer filtering (e.g., application layer filtering firewalls or second generation firewalls, which work at the application layer of the TCP / IP stack). Application layer filtering firewalls or application firewalls can generally identify certain applications and protocols (e.g., web browsing using Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) requests, file transfers using File Transfer Protocol (FTP), and various other types of applications and other protocols such as Telnet, DHCP, TCP, UDP, and TFTP (GSS)). For example, an application firewall can block unauthorized protocols that attempt to communicate over standard ports (e.g., unauthorized / non-compliant protocols that attempt to sneak through using non-standard ports for the protocol can generally be identified using an application firewall).

[0018] A stateful firewall can also perform state-based packet inspection, where each packet is inspected in the context of a series of packets related to the packet stream transmitted by the network. This firewall technology is often called stateful packet inspection because it maintains a record of all connections passing through the firewall and is able to determine whether a packet is the beginning of a new connection, part of an existing connection, or an invalid packet. For example, the connection state itself can be one of the criteria for triggering a rule in a policy.

[0019] As discussed above, advanced or next-generation firewalls can perform stateless and stateful packet filtering as well as application layer filtering. Next-generation firewalls can also perform additional firewall technologies. For example, some newer firewalls, sometimes referred to as advanced or next-generation firewalls, can also identify users and content (e.g., next-generation firewalls). In particular, some next-generation firewalls are expanding the list of applications that these firewalls can automatically identify to thousands of applications. Examples of such next-generation firewalls are available from Palo Alto Networks (e.g., Palo Alto Networks' PA series firewalls). For example, Palo Alto Networks' next-generation firewalls enable enterprises to use a variety of identification technologies to identify and control applications, users, and content, not just ports, IP addresses, and packets, such as the following: APP-ID for accurately identifying applications, User-ID for identifying users (e.g., by user or user group), and Content-ID for real-time content scanning (e.g., controlling web surfing and limiting data and file transfers). These identification technologies allow enterprises to safely enable applications using business-related concepts rather than following the traditional methods provided by traditional port blocking firewalls. In addition, specialized hardware for next-generation firewalls (e.g., implemented as dedicated appliances) typically provides higher levels of application inspection performance than software executing on general-purpose hardware (e.g., security appliances such as those provided by Palo Alto Networks, which use dedicated, function-specific processing that is tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency).

[0020] Advanced or next-generation firewalls can also be implemented using virtualized firewalls. Examples of such next-generation firewalls are available from Palo Alto Networks (e.g., Palo Alto Networks' VM series firewalls, which support a variety of commercial virtualization environments, including, for example, VMware® ESXi. TM and NSX TM 、Citrix® Netscaler SDX TM, KVM / OpenStack (Centos / RHEL, Ubuntu®), and Amazon Web Services (AWS). For example, a virtualized firewall can support similar or identical next-generation firewall and advanced threat prevention capabilities available in a physical form factor, allowing enterprises to securely enable applications to flow into and across their private, public, and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups, and REST-based APIs allow enterprises to proactively monitor VM changes, dynamically feeding that context back into security policy, eliminating policy lag that can occur when VMs change.

[0021] 2. Sample Environment

[0022] Figure 1 An example of an environment in which malware is detected and its damage is reduced is illustrated. In the example shown, client devices 104-108 (respectively) are laptops, desktop computers, and tablets present in an enterprise network 110 (belonging to "Acme Company"). Data device 102 is configured to implement policies regarding communications between client devices (such as client devices 104 and 106) and nodes outside of enterprise network 110 (e.g., reachable via external network 118). Examples of such policies include policies that control traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies, such as policies that require scanning for threats in incoming (and / or outgoing) email attachments, website content, files exchanged through instant messaging programs, and / or other file transfers. In some embodiments, data device 102 is also configured to implement policies for traffic that stays within enterprise network 110.

[0023] Data device 102 may be configured to work in conjunction with remote security platform 150. Security platform 150 may provide various services, including performing static and dynamic analysis on malware samples, and providing signature lists of known malicious files to data devices (such as data device 102) as part of a subscription.

[0024] Figure 2AAn embodiment of a data device is shown. The example shown is a representation of the physical components included in the data device 102 in various embodiments. Specifically, the data device 102 includes a high-performance multi-core central processing unit (CPU) 202 and a random access memory (RAM) 204. The data device 102 also includes a storage device 210 (such as one or more hard disks or solid-state storage units). In various embodiments, the data device 102 stores (whether in RAM 204, storage device 210 and / or other appropriate locations) information for monitoring the enterprise network 140 and implementing the disclosed technology. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policies and other configuration information, signatures, host name / URL classification information, malware profiles, and machine learning models. The data device 102 may also include one or more optional hardware accelerators. For example, the data device 102 may include a cryptographic engine 206 configured to perform encryption and decryption operations, and one or more field programmable gate arrays (FPGAs) 208 configured to perform matching, act as a network processor, and / or perform other tasks.

[0025] The functions described herein as being performed by data device 102 may be provided / implemented in a variety of ways. For example, data device 102 may be a dedicated device or set of devices. The functions provided by data device 102 may also be integrated into a general purpose computer, computer server, gateway, and / or network / routing device, or executed as software thereon. In some embodiments, at least some of the services described as being provided by data device 102 are alternatively (or additionally) provided to a client device (e.g., client device 104 or client device 110) by software executed on the client device.

[0026] Whenever the data device 102 is described as performing a task, a single component, a subset of components, or all components of the data device 102 may collaborate to perform the task. Similarly, whenever a component of the data device 102 is described as performing a task, a subcomponent may perform the task and / or the component may perform the task in conjunction with other components. In various embodiments, portions of the data device 102 are provided by one or more third parties. Depending on factors such as the amount of computing resources available to the data device 102, various logical components and / or features of the data device 102 may be omitted, and the techniques described herein may be adapted accordingly. Similarly, additional logical components / features may be included in embodiments of the data device 102, if applicable. In various embodiments, an example of a component included in the data device 102 is an application identification engine that is configured to identify applications (e.g., using various application signatures for identifying applications based on packet flow analysis). For example, the application identification engine may determine what type of traffic a session involves, such as Web browsing—social networking; Web browsing—news; SSH; and the like.

[0027] Figure 2B 102 is a functional diagram of the logical components of an embodiment of a data device. The examples shown are representations of the logical components that may be included in the data device 102 in various embodiments. Unless otherwise noted, the various logical components of the data device 102 are generally implementable in various ways, including as a collection of one or more scripts (e.g., written in Java, Python, etc., if applicable).

[0028] As shown, the data device 102 includes a firewall, and includes a management plane 232 and a data plane 234. The management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling.

[0029] The network processor 236 is configured to receive packets from a client device such as the client device 108 and provide them to the data plane 234 for processing. Whenever the flow module 238 identifies a packet as part of a new session, it creates a new session flow. Based on the flow lookup, subsequent packets will be identified as belonging to the session. If applicable, SSL decryption is applied by the SSL decryption engine 240. Otherwise, the processing by the SSL decryption engine 240 is omitted. The decryption engine 240 can help the data device 102 inspect and control SSL / TLS and SSH encrypted traffic, and thereby help prevent threats that may otherwise be hidden in encrypted traffic. The decryption engine 240 can also help prevent sensitive content from leaving the enterprise network 140. Decryption can be selectively controlled (e.g., enabled or disabled) based on parameters such as URL categories, traffic sources, traffic destinations, users, user groups, and ports. In addition to decryption policies (e.g., specifying which sessions are decrypted), decryption profiles can be assigned to control various options for policy-controlled sessions. For example, it may be necessary to use a specific cipher suite and encryption protocol version.

[0030] The application identification (APP-ID) engine 242 is configured to determine what type of traffic the session involves. As an example, the application identification engine 242 can identify a GET request in the received data and conclude that the session requires an HTTP decoder. In some cases, such as in the case of a web browsing session, the identified application can change, and such changes will be recorded by the data device 102. For example, a user may initially browse a company Wiki (classified as "Web Browsing - Productivity" based on the URLs visited), and subsequently browse a social networking site (classified as "Web Browsing - Social Networking" based on the URLs visited). Different types of protocols have corresponding decoders.

[0031] Based on the determination made by the application identification engine 242, the packet is sent by the threat engine 244 to the appropriate decoder, which is configured to assemble the packets (which may be received out of order) into the correct order, perform tokenization, and extract the information. The threat engine 244 also performs signature matching to determine what should happen to the packet. The SSL encryption engine 246 can re-encrypt the decrypted data as needed. The forwarding module 248 is used to forward the packet for transmission (e.g., to a destination).

[0032] Likewise Figure 2BAs shown, policies 252 are received and stored in the management plane 232. Policies may include one or more rules, which may be specified using domains and / or host / server names, and the rules may apply one or more signatures or other matching criteria or heuristics, such as for enforcing security policies on subscriber / IP flows based on various parameters / information extracted from monitored session traffic flows. An interface (I / F) communicator 250 is provided for management communications (e.g., via (REST) ​​APIs, messages or network protocol communications, or other communication mechanisms).

[0033] 3. Algorithm-generated domains

[0034] Back to Figure 1 , assume that a criminal (using system 120) has created malware 130. The criminal hopes that a client device, such as client device 104, will execute a copy of malware 130, thereby compromising the client device and causing the client device to become a zombie in a botnet. The compromised client device can then be instructed to perform tasks (e.g., cryptocurrency mining, or engaging in a denial of service attack) and report information to an external entity (such as a command and control (C&C) server 150), as well as receive instructions from the C&C server 150 (if applicable).

[0035] Assume that the domain "kjh2398sdfj.com" registered by the malware author using stolen identity / credit card information on Monday morning (e.g., 00:01) is reachable to the C&C server 150. Although the malware 130 may explicitly include the domain "kjh2398sdfj.com" in its code, techniques such as static / dynamic analysis of the malware 130 (e.g., performed by the security platform 140) may enable a security company (or other applicable entity, such as a security researcher) to potentially identify the domain "kjh2398sdfj.com" as being associated with the C&C server and take remedial action (e.g., publish the domain "kjh2398sdfj.com" on a blacklist, and / or take action to make the C&C server down / unreachable). Furthermore, if the domain "kjh2398sdfj.com" is hard-coded into the malware 130, then once the C&C server 150 is shut down, the malware author would potentially be unable to switch the command and control server used by the malware 130 (e.g., switch the malware from contacting "kjh2398sdfj.com" to another domain that is still reachable), making the malware less useful to the malware author.

[0036] Instead of hard-coding the domain "kjh2398sdfj.com" into the malware 130, another approach is for the malware author to utilize algorithmically generated domains ("AGD"). Utilizing AGD, the malware 130 can programmatically generate multiple domain names and attempt to connect to each generated domain name in turn until a successful connection is made, rather than attempting to contact a specific predetermined domain. Additionally, the malware can continue to generate domain names so that in the event that "kjh2398sdfj.com" becomes no longer reachable, the malware can successfully contact the C&C server at the new domain.

[0037] In the following example, assume that malware 130 generates an ASCII string every five minutes using the system clock time of client device 104 as a seed, and then attempts to connect to the generated string (after adding the appropriate top-level domain to the string, such as ".com", if applicable). Malware 130 (e.g., when executed on a client device such as client device 104) first generates "dwk2648vkwh.com" and attempts to connect to it at 0:00 a.m. on Monday morning. Since the malware author did not register "dwk2648vkwh.com" (and C&C server 150 is not reachable via "dwk2648vkwh.com"), client device 104 will not connect to C&C server 150 via "dwk2648vkwh.com". At the next five-minute mark, malware 130 (e.g., when executed on client device 104) will generate the domain "gwd4734qj5i.com" and attempt to connect to that domain (e.g., at 0:05). The malware 130 will continue to generate domain names (and attempt to connect to those domain names) every five minutes until (e.g., at 1:15) it generates and is able to connect to "kjh2398sdfj.com" (registered and online by the malware author at 0:01 on Monday).

[0038] Typically, the malware author will use a first domain (e.g., "kjh2398sdfj.com") for a period of time, such as two or three days (or a week), and then periodically switch the C&C server (or launch other C&C servers, if applicable) to a new domain (e.g., "43hfd83hd3.com") to defeat efforts to shut down / block access to the C&C server. The malware's domain generation algorithm will correspondingly generate appropriate new, reachable C&C domains (e.g., "43hfd83hd3.com") and other domains that the author will not register (e.g., every five minutes), thereby rotating the domain names that the malware will use to successfully reach the appropriate C&C server. Because the malware 130 author selects the domain generation algorithm (DGA) used by the malware 130, the malware author is able to programmatically determine which domains will be generated by the compromised machine (and at what dates / times the malware copies will attempt to communicate with those generated domains), and can therefore register a single appropriate domain for C&C use during a given period of time. Typically, malware authors will register new domains before the domains are needed (e.g., within a few hours of clients executing the domain generation algorithm potentially starting trying to connect to "43hfd83hd3.com").

[0039] The AGDs generated by the malware 130 appear to be random (e.g., to a researcher or other observer), and are therefore problematic for security companies, particularly in cases where the malware generates a large number of domains in a short period of time. If a security company can determine how AGDs are generated by a particular malware, the security company can potentially take remedial actions against those domains. Unfortunately, malware authors typically obfuscate their domain generation algorithms, and do so at a level of complexity that makes it difficult, if not impossible, to reverse engineer the malware (and the domain generation algorithm) in a timely manner. For example, a talented security researcher may need to spend months of effort to reverse engineer a single domain generation algorithm. In contrast, malware authors can relatively easily / quickly modify the way their domain generation algorithms work (e.g., changing the algorithm every week). When researchers discover how the domain generation algorithm works, malware authors can easily switch to a new algorithm, which means that researchers may have to analyze the new algorithm from scratch—potentially spending months again to discover how the new algorithm works. As will be described in more detail below, using the techniques described herein, attempts to contact an AGD (e.g., by a compromised client device 104) can be effectively detected and various remedial actions taken in response to their detection, without requiring a researcher to determine (e.g., via reverse engineering) how the algorithm used to generate the AGD works.

[0040] A. DNS resolution

[0041] Figure 1 The illustrated environment includes two Domain Name System (DNS) servers (122 and 124). As shown, DNS server 122 is under the control of ACME (for use by computing assets located within network 110), while DNS server 124 is publicly accessible (and may also be used by computing assets located within network 110 as well as other devices, such as those located within other networks (e.g., networks 114 and 116)). Enterprise DNS server 122 is configured to resolve enterprise domain names into IP addresses, and is further configured to communicate with one or more external DNS servers (e.g., DNS server 124) to resolve domain names, if applicable.

[0042] In order to connect to the website 126 (e.g., www.example.com), a client device such as the client 104 will need to resolve the domain to a corresponding Internet Protocol (IP) address. One way such resolution can occur is for the client device 104 to forward a request to the DNS servers 122 and / or 124 to resolve the domain. In response to receiving a valid IP address for the requested domain name, the client 104 can connect to the website 126 using the IP address. Similarly, in order to connect to the malicious C&C server 150, the client device 104 will need to resolve the domain "kjh2398sdfj.com" to a corresponding Internet Protocol (IP) address.

[0043] In various embodiments, the data device 102 includes a DNS module 134 configured to facilitate determining whether a client device (e.g., client devices 104-108) is attempting to contact the AGD, and / or to block connections (e.g., by client devices 104-108) to the AGD. The DNS module 134 may be integrated into the device 102 (e.g., Figure 1 ), and in various embodiments may also operate as a standalone device. Figure 1 Like the other components shown in , the DNS module 134 can be provided by the same entity that provides the device 102 (or the security platform 140), and can also be provided by a third party (e.g., a third party different from the provider of the device 102 or the security platform 140). In addition, in addition to preventing connections to known / suspicious AGDs, the DNS module 134 can also take other actions, such as logging the client's attempt to access the AGD (an indication that the given client is compromised and should be quarantined or otherwise investigated by an administrator).

[0044] In various embodiments, when a client device (e.g., client 104) attempts to resolve a domain, the DNS module uses the domain as a query to the security platform 140. The query can be performed concurrently with the resolution of the domain (e.g., with requests sent to the DNS servers 122 and / or 124 and the security platform 140). As one example, the DNS module 134 can send a query (e.g., in JSON format) to the front end 142 of the security platform 140 via a REST API. Using the process described in more detail below, the security platform 140 will determine (e.g., using the AGD detector 138) whether the queried domain is an AGD and provide a result back to the DNS module 134 (e.g., "non-AGD" or "AGD").

[0045] B. Differences between benign domains and AGD

[0046] AGDs will typically have a different character distribution probability than benign domains. Typically, benign domains will include actual words, or at least pronounceable groupings of characters (e.g., "wikipedia.org" and "amazon.com"). In contrast, AGDs will typically contain random characters (e.g., "zkkfpkbbmihohix.com"). One way to determine whether a domain is algorithmically generated is to evaluate its characteristics. In various embodiments, the security platform 140 includes a Markov chain analyzer 144 that is configured to evaluate the likelihood that a given domain is an AGD.

[0047] Figure 3 A visual representation of a portion of an example Markov chain model is depicted in . In particular, it depicts the corresponding probabilities of transitions involving "ee", "ea", "ae", and "aa" in both AGD and benign domains. Such a Markov chain model can be generated from training data that includes known benign domains and known AGD. A Markov chain model can be used to calculate a score (e.g., -0.35) for a given domain, and apply a threshold (e.g., -0.44 or lower) to assign a decision of "benign" or "AGD" to the domain.

[0048] AGD analysis using Markov chains is fast enough that security platform 140 can provide real-time results to data device 102. Unfortunately, Markov chain analysis can also result in false positives. As an example, a domain such as "exampleeee.com" may actually be a benign domain, but may be incorrectly flagged as AGD using Markov chain analysis.

[0049] In various embodiments, before returning a determination of "AGD" in response to a query, "AGD detector 138" evaluates historical information associated with the domain. Figure 4A and 4BAs shown, AGDs and benign sites typically exhibit very different resolution statistics. For example, a given AGD will have very few, if any, successful resolutions (402), while benign sites, and particularly popular sites, will have many resolutions (404). In addition, the length of time between the first time an AGD is resolved and the last time it is resolved (452) is typically much shorter than for benign domains (454). The AGD detector 138 can use such historical information to reduce false positives. As an example, when a domain is determined (by the Markov chain analyzer 144) to be an AGD, the domain history checker 146 queries the database 160 for resolution information associated with the domain. A threshold may be used by the decision engine 152 to determine the final decision on the domain. As an example, assume that a given domain has a Markov chain analysis score of -0.48. Such a score (below the threshold of -0.44) would cause the Markov chain analyzer 144 to mark the domain as an AGD. If the resolution count of a domain is above a given threshold (e.g., 20 or more resolutions) or the interval is above a given threshold (e.g., 1 year), the determination of AGD can be overturned as a false positive.

[0050] C. Example Process

[0051] Figure 5 An example of a process for detecting algorithmically generated domains is illustrated. In various embodiments, process 500 is performed by security platform 140. If applicable, process 500 may also be performed by other types of platforms / devices, such as data device 102, client device 104, etc. Process 500 begins at 502 when a DNS query is received. As an example, the DNS query is received by front end 142 at 502 when DNS module 134 receives a DNS resolution request from client device 104 (actively or passively). In some embodiments, DNS module 134 provides all DNS resolution requests as queries to platform 140 for analysis. DNS module 134 may also provide such requests to platform 140 more selectively. An example reason why DNS module 134 may not query platform 140 for a domain is that information associated with the domain is cached at a location in data device 102 (e.g., because client device 106 previously requested resolution of the domain and process 500 was previously performed for the domain). Another reason is that the domain is in a whitelist / blacklist, etc., and therefore no additional processing is required.

[0052] At 504, a Markov chain analysis is performed on the domain received at 502. One example way to perform such an analysis is to use a Markov chain analyzer (144) written in Go or another suitable language. As discussed above, a training set including known benign and known algorithmically generated domains can be used to generate a Markov chain model for use by the Markov chain analyzer 144.

[0053] At 506, a determination is made as to whether the domain received at 502 relates to an algorithmically generated domain. As an example, if the Markov chain analyzer 144 has determined (e.g., by comparing the score to a threshold) that the domain is not algorithmically generated, the decision engine 152 (written in Go or another appropriate language) may return a "benign" determination. As discussed above, one potential disadvantage of using the Markov chain analyzer 144 exclusively for determination is that false positives may occur. In various embodiments, the decision engine 152 also considers additional information before returning an AGD result. For example, the decision engine 152 may apply a threshold to historical information stored in a database 160 and retrieved by a domain history checker 146 (also written in Go or another appropriate language). An example of a database 160 is a Redis database, and example information included in the database 160 is each date / time stamp for a request made for a given domain, and whether the resolution was successful (or other appropriate information, such as the resolved IP address for the domain). The historical information stored in the database may be collected by security platform 140 (e.g., by collecting information from each of data devices 102, 136, and 148 regarding resolution requests made by clients within their respective networks 110, 114, and 116). The historical information stored in the database may also be provided, at least in part, by one or more third parties (e.g., provided by DNS server 124), if applicable.

[0054] In response to the decision engine 152 determining that the domain is algorithmically generated, various actions may be taken. As one example, the security platform 140 may respond to the data device 102 with an appropriate result (e.g., a determination of "AGD"). The data device may then take action based on the policy 252, such as blocking communications between a client device (e.g., client device 104) and the AGD. The data device 102 may also take other actions, such as alerting an administrator that a given client device has attempted to contact the AGD (and therefore may be compromised / have malware executing on it), isolating the client device from other nodes on the network 110, etc.).

[0055] The security platform 140 may also take additional actions in response to the decision engine 152 determining that the domain is algorithmically generated. As an example, the security platform 140 may attempt to determine whether the domain belongs to a particular DGA family. This helps determine, for example, the nature of malware that has (potentially) compromised the client 104. One way to classify a given domain as a family is to extract features associated with the domain and use a machine learning model.

[0056] like Figure 1As shown, the security platform 140 includes a DGA family tagger 156 (written in python or another appropriate language). The DGA family tagger 156 utilizes a random forest model 158 that is trained using information from a set of known DGA families. Examples of such features include what the TLD of the domain is (e.g., ".com" versus ".so"), the number of occurrences of a particular character in the domain (e.g., the number of times "-" is used), the length of the domain, the number of different characters in the domain, the ratio of numbers to non-numbers in the domain, whether the first character of the root domain is a number, etc. Such features can be extracted by a feature extractor 156 (written in python or another appropriate language). Other approaches can also be used, such as by applying heuristics, or using other types of machine learning models, such as support vector machines, if applicable.

[0057] If the random forest model indicates a match between the domain and a known family, the domain can be associated with the family (e.g., as information stored in database 160), and other appropriate actions can be taken (e.g., alerting an administrator that client device 104 is seen exhibiting behavior associated with a particular family).

[0058] Although the foregoing embodiments have been described in detail for the purpose of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative rather than restrictive.

Claims

1. A system for detecting algorithmically generated domains (AGDs), comprising: The processor is configured as: receiving a DNS query in response to a client device making a DNS resolution request; performing a Markov chain analysis on the domains included in the received query; determining, based at least in part on the results of the Markov chain analysis, that the received query relates to the algorithmically generated domain AGD; and including, in a response to the query, an indication of domain AGD activity generated by an algorithm indicating a DNS resolution request made by the client device; The memory is coupled to the processor and configured to provide instructions to the processor. 2 . The system of claim 1 , wherein determining that the received query relates to the algorithmically generated domain comprises evaluating historical parsing information. The system of claim 2 , wherein the historical resolution information comprises resolution counts. The system of claim 2 , wherein the historical parsing information includes an interval between a first parsing and a last parsing.

5. The system of claim 1, wherein the Markov chain model is trained at least in part using a collection of known algorithmically generated domains.

6. The system of claim 1, wherein the Markov chain model is trained at least in part using a set of known benign domains. 7 . The system of claim 1 , wherein the processor is further configured to determine whether the domain is associated with a family of algorithmically generated domains.

8. The system of claim 7, wherein determining that the domain is associated with the family of algorithmically generated domains comprises using a random forest trained using features extracted from the family of algorithmically generated domains.

9. The system of claim 7, wherein at least one characteristic comprises a domain suffix.

10. The system of claim 7, wherein at least one feature comprises a count of hyphens.

11. The system of claim 7, wherein at least one characteristic comprises domain length.

12. The system of claim 7, wherein at least one feature comprises a different number of characters.

13. The system of claim 7, wherein at least one characteristic comprises a ratio of numbers to other characters.

14. The system of claim 7, wherein the at least one characteristic comprises whether a first character of the root domain is a number.

15. A method for detecting an algorithmically generated domain (AGD), comprising: receiving a DNS query in response to a client device making a DNS resolution request; performing a Markov chain analysis on the domains included in the received query; determining, based at least in part on the results of the Markov chain analysis, that the received query relates to the algorithmically generated domain AGD; and In the response to the query, an indication of domain AGD activity generated by the DNS resolution request indication algorithm made by the client device is included.

16. The method of claim 15, wherein determining that the received query relates to the algorithmically generated domain comprises evaluating historical parsing information. The method of claim 16 , wherein the historical resolution information comprises resolution counts. The method of claim 16 , wherein the historical parsing information includes an interval between a first parsing and a last parsing.

19. The method of claim 15, wherein the Markov chain model is trained at least in part using a collection of known algorithmically generated domains.

20. The method of claim 15, further comprising determining whether the domain is associated with a family of algorithmically generated domains.

21. A computer program product embodied in a tangible computer readable storage medium, comprising computer instructions which, when executed by a processor, cause the processor to perform the following steps: receiving a DNS query in response to a client device making a DNS resolution request; performing a Markov chain analysis on the domains included in the received query; determining, based at least in part on the results of the Markov chain analysis, that the received query relates to an algorithmically generated domain; and In the response to the query, an indication of domain AGD activity generated by the DNS resolution request indication algorithm made by the client device is included.

Images