DNS Early Threat Response

Abstract

Various technologies for providing a DNS Early Threat Executive Response System (DETERS) are disclosed. In some embodiments, DETERS is a comprehensive DNS threat detection, response, and reporting system with a modular analytical architecture that enables near real-time early detection of suspicious activity. DETERS can identify threats before they can spread to the system or gain unauthorized access to it. DETERS utilizes a combination of streaming and batch processing along with historical DNS information. The DNS-centric design allows DNS resolvers to quickly mitigate threats and reporting systems to alert users, enabling users to take further action reflected in DNS resolver policies.

Description

Cross-reference to other applications

[0001] This application claims priority based on U.S. Provisional Patent Application No. 63 / 521,437, filed on June 16, 2023, entitled "DNS EARLY THREAT RESPONSE", which is incorporated herein by reference in its entirety for all purposes.

Background Art

[0002] Network services of the Domain Name System are generally ubiquitous in IP-based networks. Generally, a client (e.g., a computer device) attempts to connect to a server on the Internet using a web address (a Uniform Resource Locator (URL) including a domain name or a fully qualified domain name). The web address is converted into an IP address. The Domain Name System (DNS) is involved in performing this conversion from the web address to the IP address. Specifically, a request including a web address is sent to a DNS server, and the DNS server responds with the corresponding IP address or, in the case of a domain that is not registered, i.e., a non-existent domain, responds with an error message.

Brief Description of the Drawings

[0003] In the following detailed description and the accompanying drawings, various embodiments of the present invention are disclosed.

[0004] [Figure 1] A diagram showing the overall data flow of a DNS early threat response system according to some embodiments.

[0005] [Figure 2] A diagram showing a timeline of use cases of DETERs for spear phishing according to some embodiments.

[0006] [Figure 3]A diagram illustrating the logical flow of primary DETERS detection of suspicious domains according to several embodiments.

[0007] [Figure 4] A diagram showing secondary detectors within DETERS that, according to several embodiments, are involved in refining what the primary detectors find, annotating those detections, and creating results available in the response system.

[0008] [Figure 5] Flowcharts for DNS early threat response systems according to several embodiments.

[0009] [Figure 6] Another flowchart for a DNS early threat response system according to several embodiments. [Modes for carrying out the invention]

[0010] The present invention can be implemented in various forms, including processes, apparatus, systems, compositions of materials, computer program products embodied on computer-readable storage media, and / or processors (processors configured to execute instructions stored and / or provided by memory connected to the processor). In this specification, these embodiments or any other forms the present invention may take may be referred to as "technologies." Generally, the order of the processes of the disclosed processes may be modified within the scope of the invention. Unless otherwise specified, components such as processors or memory described as configured to perform a task may be implemented as general components temporarily configured to perform a task at a given time, or as specific components manufactured to perform a task. In this specification, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data such as computer program instructions.

[0011] The following provides a detailed description of one or more embodiments of the present invention, with reference to drawings illustrating the principles of the present invention. While the present invention is described in relation to such embodiments, it is not limited to any of these embodiments. The scope of the present invention is limited only by the claims, and the present invention includes many substitutes, variations, and equivalents. The following description includes many specific details to provide a complete understanding of the present invention. These details are illustrative, and the present invention can be implemented in accordance with the claims without some or all of these specific details. For simplicity, technical matters well known in the art related to the present invention are not described in detail, so as not to complicate the present invention unnecessarily.

[0012] Domain Name System (DNS) network services are generally ubiquitous on IP-based networks. Typically, a client (e.g., a computer device) attempts to connect to a server on the internet using a web address (a Uniform Resource Locator (URL) containing a domain name or fully qualified domain name (FQDN)). The web address is translated into an IP address. The Domain Name System (DNS) is involved in this web address-to-IP address translation. Specifically, a request containing a web address is sent to a DNS server, which either responds with the corresponding IP address or, if the domain is not registered, i.e., does not exist, responds with an error message (for example, an NX Domain response is returned by the DNS server for a non-existent domain).

[0013] Technical Overview for DNS Early Threat Executive Response System (DETERS)

[0014] Various technologies for providing a DNS Early Threat Executive Response System (DETERS) are disclosed. The disclosed DETERS solutions can be implemented in various system, process, and / or computer program embodiments, including those detailed later in relation to various embodiments.

[0015] DETERS is a comprehensive DNS threat detection, response, and reporting system with a modular analytical architecture that enables near real-time (almost real-time) early detection of suspicious activity. The system's objective is to identify threats before they can spread to or gain unauthorized access to the system. To achieve this, DETERS utilizes a combination of streaming and batch processing along with historical DNS information. The DNS-centric design allows DNS resolvers to quickly mitigate threats and the reporting system to alert users, enabling users to take further action reflected in their DNS resolver policies. DETERS has three main functions: (1) detection, (2) response, and (3) reporting.

[0016] DETERS is designed as a security architecture to support recursive DNS resolvers serving one or more independent networks. DETERS consumes DNS query response data from recursive resolvers. Resolvers can distinguish which network a query originates from and forward this information to DETERS. That is, when a resolver serves DNS queries for two different networks A and B, it provides enough information to differentiate queries from network A and network B. This information is used by the DETERS detector system, as shown in Figure 1 below, which works to identify suspicious behavior in the remaining queries after filtering large volumes of DNS traffic into smaller subsets. From the suspicious behavior, DETERS has a configurable response system for each network that determines how the resolver should handle all future queries. After policy enforcement, the DETERS reporting system aggregates the suspicious behavior and issues warnings.

[0017] Thus, novel and improved technologies for DETERS are disclosed. Examples of embodiments for DETERS solutions are further described below.

[0018] Example of a system embodiment for a DNS Early Threat Executive Response System (DETERS)

[0019] Figure 1 shows the overall data flow of a DNS early threat response system according to several embodiments. Referring to Figure 1, DETERS consumes DNS from a recursive resolver, shown as a central resolver 104, that is, from a potentially large number of different networks, shown as multiple networks 102, filters it through a detector system including a DETERS primary detector 106 and a DETERS secondary detector 108, which will be detailed later, and performs responses to high-risk domains as shown in 110, based on a policy 112 (e.g., a DNS security policy), and provides preferential alerts and reports as shown in 114.

[0020] DETERS is designed for various use cases where near real-time responses are desired and there are no prior decisions to rely on. Spear phishing is one example of the type of problem that DETERS can effectively and efficiently solve (for example, for a company / its employees / users' corporate network that may be targeted by spear phishing or other / similar attacks). In a spear phishing attack, a sophisticated actor may register a domain and immediately afterward use that domain when attacking a specific group of users (e.g., employees of a target company). For example, an attacker may try to convince a user to click a URL containing a spear phishing domain, ultimately attempting to gain unauthorized access to the user's system or steal their credentials (for example, the attacker can then use those credentials for malicious / unauthorized / undesirable activities, such as extracting data from the user's device and / or other devices on the target company's corporate network). Spear phishing differs from typical phishing attacks in that it targets a specific user or group of users, resulting in a smaller data trail in DNS.

[0021] However, in existing, traditional systems based on DNS, detecting such threats is typically slow due to the enormous amount of data involved (e.g., DNS data) and the complexity of the attacks.

[0022] Figure 2 shows a timeline of DETERS use cases for spear phishing according to several embodiments. As shown in this embodiment, DETERS can identify a spear phishing domain immediately after it is used, as shown in this timeline within one minute.

[0023] Referring to FIG. 2, a timeline of an advanced spear phishing attack and a comparison of the time required for detection between DETERSS and conventional systems are shown for this use case of spear phishing. As shown at 202, a domain (e.g., a newly registered domain) is registered for a spear phishing attack. At 204, the newly registered domain is utilized and DNS queries are observed. At 206, the disclosed DETERSS solution (e.g., simply referred to as DETERSS) identifies and blocks future queries to the newly registered domain (e.g., within one minute after the newly registered domain is first utilized / queried). At 208, further attacks are effectively blocked and DETERSS reports its activity.

[0024] Compared to the conventional existing DNS system, as shown at 210, the domain is first processed in batch at N hours after the first utilization of the newly registered domain (compared to detection within one minute after the first utilization by DETERSS). At 212, based on the batch process, discovery within the newly registered domain is performed, but it is substantially / potentially too late for a given enterprise / user targeted by a spear phishing attack using the newly registered domain. Specifically, the number of queries observed at large multi-enterprise resolvers can often exceed tens of billions per day, so the conventional process is generally resource-intensive and prohibitively costly (e.g., as shown in step 210). As a result, typically, it is handled in batch with some delay.

[0025] Using the disclosed DETERs solution, the system significantly reduces the processing volume by a complex algorithm to provide near real-time detection. Thus, DETERs utilizes a primary filter (also referred to as a primary filter / detector, such as that shown at 106 in FIG. 1 herein) based on the observed history of domains in DNS queries. Only newly observed domains are transferred for further processing. Since a recursive resolver alone cannot determine whether a domain has been seen for the first time, an external system provided by DETERs is used to make that determination. The DNS query log is sent from the resolver to DETERs, and DETERs then updates the DNS policy information available to the resolver (such as the resolver shown at 104 in FIG. 1).

[0026] When the primary filter uses the observed history data, DETERs also utilizes a cascade filter (also referred to as a secondary filter / detector, such as that shown at 108 in FIG. 1 herein) to continuously reduce the data size, as shown in FIG. 3 and as described below, enabling the application of increasingly complex algorithms and facilitating rapid threat classification.

[0027] FIG. 3 shows the logical flow of DETERs primary detection of suspicious domains according to some embodiments. The DETERs primary detector consumes DNS query response data from many networks and reduces that data to a small amount for use by the secondary detector. In this example, the DETERs primary detector uses an aggregation table of domains seen across all networks (such as multiple networks seen in DNS queries at a central DNS resolver (such as that shown at 104)) over all time and domain enrichment to filter to a manageable size for the large volumes, as detailed below.

[0028] Referring to Figure 3, the first (primary) detector 106 identifies a subset of domains that are being seen for the first time, as shown in 304, by checking and removing commonly observed domains that are new to the network (e.g., a corporate network), as shown in 302. This substantially reduces traffic (e.g., a 98% reduction in DNS traffic based on experiments, when only about 2% of domains are being seen for the first time). The second (secondary) detector 108 performs initial triage (e.g., using enrichment services along with fast lightweight weight analysis, such as DGA and / or domain similarity detection), and then checks domains by applying a DNS reputation filter 308B against a registration database 308A. Further checks (not shown) may be performed against other enrichments to help determine the potential of a domain to be potentially suspicious. For example, similarity or domain generation algorithm (DGA) filters (not shown) may be applied to further classify domains associated with spear phishing or malware, as shown in 306.

[0029] If the primary and secondary detectors identify a suspicious domain or other suspicious activity based on combining scores from various filters / detectors to determine a risk level / score as shown in 310, this is passed to the DETERS response component shown in 312. Otherwise (for example, if the domain is not determined to be potentially malicious), it is passed to the confirmation queue shown in 316 for confirmation / verification, or, if determined to be suspicious, to the response system shown in 314.

[0030] The DETERS response component is configured to perform response actions (e.g., immediate / rapid response actions) to mitigate potential attacks based on customized network configurations. For example, a domain in the response may be configured to block further DNS queries for a certain period of time, as shown in 318 (e.g., promoting it to a permanent response policy zone (RPZ), as a result, the recursive resolver may return a modified result and, by correcting the result, block access to the corresponding host). In this embodiment, the DETERS response is customizable for any subnetwork served by the DNS resolver. The response subsystem manages the suspicious domain list and network configuration and provides an interface that allows the DNS resolver to process further requests. As another example, the DETERS response system could also ensure that future requests for a domain are mitigated by forcing a flush of the resolver's cache.

[0031] Furthermore, domains are submitted to a verification queue to obtain further information, such as scanning services to discover open ports, screenshots, and / or other information to verify or disprove the suspicious nature of the domain, as shown in 316. For example, if a potential spear-phishing domain is determined to be a similar domain, but also determined to have an SSL certificate signed by the entity (e.g., a company) that owns the actual domain and similar domains, it may be disproven. In contrast, if a domain is determined to have an SSL certificate from a different signing authority and significantly different infrastructure, it will be verified. Disproven domains may then be returned to the response system for blocking and retraction of the report. Verified domains may be promoted to long-term blocking services outside the DETERS response system, as shown in 318.

[0032] Ultimately, the DETERS reporting component aggregates and prioritizes event notifications. In the case of a spear-phishing attack, the DETERS reporting component can highlight the likelihood that the attack occurred on a specific device at a specific time, and then aggregate subsequent mitigation efforts. The reporting component leverages an asset management system that enables administrators to identify affected devices for follow-up recovery.

[0033] Each of these aforementioned components will be described in detail below.

[0034] While the DETERS technology and disclosed systems described above may be applied to include security analysis based on newly registered domains, the DETERS technology and systems may similarly be applied to include detection of other types of anomalies, such as suspicious behavior by DNS clients and DNS name servers.

[0035] DETERS can operate in multiple environments. For example, DETERS can be implemented in a cloud environment where the network is an unrelated organization. Another example is DETERS being implemented in an on-premises environment (e.g., a corporate environment, a university environment, a government environment) where differentiation is made between the organization's subnetworks. Specifically, in a corporate environment, the network may represent different business components, such as the engineering department and the sales department, and in a university environment, it may be differentiated by faculty. Similarly, in a hybrid environment, DETERS can be used for early threat detection when comparing cloud and on-premises traffic within and across networks.

[0036] DETERS detection components

[0037] In one embodiment, the DETERS detection component identifies suspicious domain activity in a two-stage approach to provide near real-time protection to DNS resolvers and clients. The input to this component is DNS query data or query response data from a DNS resolver (e.g., DNS resolver 104 shown in Figures 1 and 3). Because the volume of DNS queries in enterprise or multi-enterprise environments is typically extremely large, the first stage of DETERS detection component processing (i.e., the stage using primary detectors) functions to substantially reduce the set of domains for further evaluation / processing. The second stage applies one or more detectors (i.e., using secondary detectors) to further refine the output of stage 1 and provide further insight and prioritization to the downstream DETERS response system.

[0038] We will first describe Stage 1, which is used to reduce the overall volume and identify suspicious domains, and then describe Stage 2, the secondary detector. The goal of Stage 1 is to significantly reduce the query volume (e.g., by about 98%), which facilitates more effective and efficient processing of the remaining domains that use more time-consuming checks, such as application programming interface (API) calls or machine learning (ML) models.

[0039] Stage 1. Primary detector

[0040] In one embodiment, the objective of the primary detection stage is to reduce the overall volume of query activity so that it can be analyzed in near real-time during the second stage. For example, a DNS resolver may serve hundreds of different networks and receive billions of queries per day. In our experiment, the system processed over 30 billion records per day. DETERS can identify threats that have not yet been detected through other existing conventional DNS security solutions and technologies. In the case of a malicious domain, this may be because the domain is newly registered or newly observed within the network served by the DNS resolver. In another example, this may be because a client requests an unusual domain or DNS query type. Figure 3 illustrates a possible decision flow for a use case involving a suspicious, recently registered domain (e.g., a domain used for spear phishing).

[0041] In this embodiment, as shown in Figure 3, the DETERS detector framework uses historical information about domains to make decisions regarding DNS queries and identify suspicious domains. Specifically, the queried domain is first checked against a list of common domains in memory and against the aggregated history of all domains that may have been resolved by the DNS resolver and are retrieved somewhere in the database cache if the domain does not exist in the aggregated history table. If the domain does not appear in either, it is promoted to a secondary detector for further security analysis / processing, as will be detailed later with respect to Figure 4.

[0042] The primary detector is a rapid filter to remove domains that have been observed in the customer network long enough to properly determine their behavior. In the final stage of the primary detector, DETERS identified domains based on new activity and domain age to nominate them for further checks at the second level.

[0043] Stage 2. Primary detector

[0044] Figure 4 shows secondary detectors within DETERS that, according to several embodiments, are involved in refining the findings of the primary detector, annotating those findings, and creating results available to the response system. In one embodiment, the secondary detectors are modular and can operate independently or sequentially, as detailed below with respect to Figure 4. Each secondary detector can make a determination, annotate and / or add properties to the findings, and provide results to the response system 312. For example, a secondary detector can evaluate any aspect of DNS query response data, such as a domain name, a resolved IP address, and / or a client IP address.

[0045] Referring to Figure 4, multiple secondary detectors 404A, 404B, 404C, and 404D for the DETERS system receive Stage 1 output of potentially suspicious domains shown in 402 and perform an initial determination of whether the domain is suspicious or not. For example, DETERS secondary detectors 404A-D can perform active checks on domains, including creation date, reputation, and / or other enrichments, by applying heuristic and / or machine learning (ML) techniques, etc. The DETERS secondary detectors exclude domains older than a certain period, such as older than 48 hours (e.g., or other threshold periods similarly available for this process). The remaining newly observed and registered domains undergo further secondary detector filtering, for example, based on various reputation scores. Examples of reputation scores may include reputation analysis / scoring based on associated name servers, TLD reputation (e.g., examples of malicious TLDs include .exe, .zip, etc.), and DGA or similarity scores, etc.

[0046] In this embodiment, the secondary detector performs various automated analyses to classify domains as suspicious, likely harmless, or unknown, providing further annotations on the domain's characteristics. The secondary detector can be implemented as a streaming algorithm. Individual analyses can be performed independently of DETERS, which can then provide a platform to which new analysis / classification techniques for DNS security can be applied. In this example, the secondary detector is modular and may be independent or part of a pipeline, as shown with respect to detector 1 of 404A and detector 2 of 404B, and with respect to detector 3 of 404C and detector 4 of 404D. Multiple detectors may consume the same data and draw different conclusions about the same domain or set of domains. For example, based on different characteristics used by individual detectors, one detector might classify a domain as a suspicious similar domain, while another analyzer might classify the same domain as suspicious phishing.

[0047] As shown in 406, detectors annotate their conclusions with further properties specific to the domain and the particular detector. For example, a detector may classify a domain as suspicious based on further properties such as DNS tunneling (DNST), legacy domain generation algorithms (DGA), registered DGAs, or similarity to another established domain (e.g., similar domains). Annotations may include information about the nature of the domain that led to the classification or the domain's query patterns. Annotations may also include features such as newly registered or low-reputation name servers.

[0048] Each detector can utilize various source and enrichment data, enabling it to discover and annotate domains for downstream use in DETERS and / or other DNS security products. In this embodiment, the DETERS detector operates in a streaming environment, but can also operate in different configurations. These algorithms can utilize one or more DNS query responses, as well as any data within packets and enrichment sources, to evaluate domains. These algorithms return near real-time classifications of domains or sets of domains.

[0049] Therefore, the disclosed DETERS streaming detector facilitates the provision of near real-time classification of domains with minimal latency. This, in turn, enables the DETERS response and reporting components to operate rapidly.

[0050] In a spear-phishing use case, the primary detector identifies recently registered domains deemed suspicious. Secondary detectors can then process these domains individually and make different decisions. For example, assuming the domain InfobIox[.]com (e.g., with lowercase L replaced by uppercase I in the domain name) is identified as suspicious by the reputation enrichment service, a second algorithm for similarity detection would further identify it as a suspicious similar domain, while a third algorithm for DGA detection would classify this domain as not a DGA domain. Reputation and similarity detectors can annotate what is found, such as DETERS response components acting on future queries of the domain, and DETERS reporting components providing threat intelligence to report on activity. The domain is then placed in a confirmation queue (e.g., shown as 316 in Figure 3), which allows for further (e.g., non-real-time) analysis and updates of the DETERS reporting and response system as available. However, the DETERS response system can operate with the given information until such an update arrives.

[0051] DETERS response components

[0052] Similarly, as described above, detected suspicious domains are made available to the DETERS response subsystem shown in Figure 4, 312, for executive action (e.g., response action based on corporate DNS security policies or other configurations / policies). In this embodiment, these actions are configurable on a per-network basis, and the design is modular. The response may include a variety of actions to further protect the affected network, including one or more of the following: (1) a network-specific policy to block, log, and / or redirect future queries to the suspicious domain; (2) completely disabling DNS resolution for one or more affected clients; (3) ensuring future queries are handled according to the DETERS policy action by clearing cached results from DNS content servers in the DNS resolver cache; (4) forwarding suspicious query and enrichment data to downstream security systems for further review; and (5) applying cross-network policy actions to all further queries to the suspicious domain.

[0053] The DETERS response subsystem may be configured to take further actions upon receiving updates from the acknowledgment queue, including: (1) all of the above actions, or (2) disabling one or more of the above actions.

[0054] In this embodiment, the DETERS response is also modular in design, and the network owner can configure response policies (e.g., DETERS / DNS security policies) from individual secondary detectors. For example, in the case of domain-based responses, the network owner can configure the following executive / response actions: (1) block a domain on a low-reputation TLD if it has recently registered and log further queries for the domain if it has recently registered on a high-reputation TLD, or alternatively, (2) block all newly observed similar domains on a low-reputation name server.

[0055] Therefore, because analyses can be structured in various ways and different responses from DNS resolvers can be applied accordingly, network administrators can have fine-grained control over their security at the DNS layer.

[0056] All further DNS queries can create logs of responses that are later used by the DETERS reporting component to notify network administrators of security events on those networks.

[0057] Stage 3. Confirmation Queue

[0058] After a secondary detector determines that a domain is potentially suspicious, the suspicious domain is sent to the confirmation queue component shown as 316 in Figure 3, the response component shown as 312 in Figures 3 and 4, and the reporting component shown as 114 in Figure 1. In the confirmation queue, further checks are performed to confirm or disprove the potentially suspicious nature of the domain. In one embodiment, these further checks may include performing further analysis of the source of DNS traffic, analyzing SSL certificates, utilizing scanning services, and / or various other potentially more time-consuming tasks that cannot generally be performed in real time or near real time.

[0059] In the example of the similar spear-phishing domain infobIox[.]com, further analysis / processing of the verification queue could be used with a combination of URL scanning services and computer vision to discover that the domain redirects to a login page, in which case the domain is flagged as malicious, promoted to a permanent RPZ (as shown in 318 in Figure 3, for example), and the reporting components are updated as the domain requires some further scrutiny.

[0060] However, if the domain infobIox[.]com resolves to the same IP address as the genuine infoblox.com and shares the same registration and SSL certificate information, the verification queue may determine that the similar domain was a defensive registration by the company. In that case, the response system will be notified so that it can change its policy, and the reporting system will be notified to reduce the severity level, for example, so that the Security Operations Center (SOC) does not waste time performing further investigations into this domain which was previously flagged as suspicious but has since been disproven.

[0061] DETERS Report Components

[0062] In this embodiment, to support the Security Operations Center (SOC) and executive audits (such as those conducted by the Chief Information Security Officer (CISO)), DETERS further provides a robust reporting component shown in Figure 1, section 114. The reporting serves both the purpose of immediate alert notification and event summarization. Similar to the response components described above, the reporting components of DETERS can be implemented as fully configurable. While the response components control the DNS resolver's response, the reporting components are an independent channel for providing network owners with information about events (e.g., DNS security-related events detected by DETERS).

[0063] Considering the example of spear phishing, DETERS reporting could be configured to send a warning to network administrators that a potential targeted phishing attack has occurred. This warning could include information on the devices involved, queries, and timing so that a suitable SOC can isolate and mitigate any damage from the event. Reports could also aggregate further events, such as queries made against the domain by other devices, to ensure that security organizations receive relevant information for a full understanding of the attack, including attempts blocked by DETERS.

[0064] The reporting components receive updates from the confirmation queue, and based on the additional information received, this may increase or decrease the severity of previously sent alerts. In this way, the additional information may allow security organizations to reprioritize previous alerts as needed.

[0065] Furthermore, DETERS reports can include a feedback loop that allows network administrators and security teams to downplay or disprove detections. This feedback can influence all aspects of the DETERS system. For example, in the case of a reported false positive, DETERS can facilitate or perform the following actions: (1) send the information to the confirmation queue; (2) invalidate the current response policy; (3) revert the DNS resolver to its previous state; (4) include feedback to the detector framework to ensure it is not detected again and can be used to train detectors in the future; and (5) archive the relevant report.

[0066] Here, various processing embodiments for DETERS are described in detail below.

[0067] Example of a processing embodiment for the DNS Early Threat Executive Response System (DETERS)

[0068] Figure 5 is a flowchart for a DNS early threat response system according to several embodiments. In some embodiments, the process shown in Figure 5 is performed by a DETERS system (e.g., primary detector 106, secondary detector 108, and / or other components), as well as by the techniques described above, as well as the embodiments described with respect to Figures 1 to 4.

[0069] In step 502, monitoring of Domain Name System (DNS) network activity at the central DNS resolver is performed, similarly to what was described above with respect to Figures 1 to 4.

[0070] In step 504, filtering of DNS network activity is performed at the primary detector to transfer a subset of domains that have not been previously analyzed or have recently been registered for further security analysis, as similarly described above with respect to Figures 1 to 4.

[0071] In step 506, the secondary detector identifies suspicious domains from a subset of domains, which is performed in near real-time, as described above with respect to Figures 1 to 4.

[0072] In step 508, actions are taken in response to the identified suspicious domain, as similarly described above with respect to Figures 1 to 4. For example, the response actions may include one or more of the following, as similarly described above: (1) blocking the suspicious domain in near real-time on the DNS security platform so that the suspicious domain is blocked for at least a predetermined period of time; (2) blocking the spear-phishing attack on the DNS security platform; (3) reporting the suspicious domain for the first network based on the DNS security policy associated with the first network; (4) generating a warning about the suspicious domain for the first network based on the DNS security policy associated with the first network; (4) conducting further analysis of the suspicious domain to verify whether the suspicious domain is a malicious domain or a false positive; and / or (5) various other response actions or combinations thereof may be performed.

[0073] Figure 6 is another flowchart for a DNS early threat response system according to several embodiments. In some embodiments, the process shown in Figure 6 is performed by a DETERS system (e.g., primary detector 106, secondary detector 108, and / or other components), as well as by the techniques described above, as well as the embodiments described with respect to Figures 1 to 4.

[0074] In step 602, as similarly described above with respect to Figures 1 to 4, Domain Name System (DNS) network activity at the central DNS resolver is received by the primary detector of the DNS security detection system (e.g., the DETERS system).

[0075] In step 604, filtering of DNS network activity is performed based on the historical profile of previously queried domains, similarly as described above with respect to Figures 1 to 4. For example, the primary detector may be configured to filter DNS network activity based on client IP address historical records that include one or more of the following: (1) the time when a device anomaly is detected, and (2) the unauthorized device and / or geolocation information.

[0076] In step 606, as described above with respect to Figures 1 to 4, multiple secondary detectors of the DNS security detection system receive the filtered DNS network activity from the primary detector.

[0077] In step 608, as similarly described above with respect to Figures 1 to 4, one or more aspects of the DNS query response data included in the filtered DNS network activity are evaluated to facilitate the identification of suspicious DNS network activity. For example, one or more of several secondary detectors may be configured to score each of a subset of domains based on one or more of the following: being hosted on a malicious top-level domain (TLD), being hosted on a reputation-based malicious name server, being associated with a known malicious ASN, DGA structure, being associated with a domain-like structure, and / or other DNS-related security analysis may be performed to evaluate any aspect of the DNS query response data (including domain name, resolution IP address, and / or client IP address, etc.).

[0078] In step 610, as similarly described above with respect to Figures 1 to 4, a further evaluation of suspicious DNS network activity is performed to verify whether it is malicious activity or a false positive. For example, as similarly described above with respect to Figures 3 and 4, further security analysis may be performed on the suspicious domain using a confirmation queue to verify that the suspicious domain is malicious and promote it to a longer-term block, or to determine that the domain is not suspicious and not block a domain whose legitimacy has been verified.

[0079] Although the embodiments described above have been explained in some detail for the sake of clarity, the present invention is not limited to the details provided. Many alternative methods exist for carrying out the present invention. The disclosed embodiments are illustrative and not intended to be limiting.

Claims

1. It is a system, It is a processor, Monitor Domain Name System (DNS) network activity at the central DNS resolver, The primary detector filters the DNS network activity to transfer a subset of domains that have not been previously analyzed or have recently been registered for further security analysis. In near real-time, the secondary detector identifies suspicious domains from a subset of the domains, A processor configured to perform an action in accordance with the identified suspicious domain, A memory connected to the processor and configured to provide instructions to the processor, A system equipped with these features.

2. The system according to claim 1, wherein the primary detector is configured to filter the DNS network activity based on a historical profile of previously queried domains.

3. The system according to claim 1, wherein the primary detector is configured to filter DNS network activity based on (1) the time at which a device anomaly is detected, and (2) a client IP address history record that includes one or more of the unauthorizedly accessed device and / or geolocation information.

4. A system according to claim 1, wherein the secondary detector is configured to score each of the subset of domains based on one or more of the following: being hosted on a malicious top-level domain (TLD), being hosted on a reputation-based malicious name server, being associated with a known malicious ASN, DGA structure, and being associated with a domain-like structure.

5. The system according to claim 1, wherein DNS network activity is filtered on a network basis for a plurality of monitored corporate, university, and / or government networks.

6. The system according to claim 1, wherein a cloud resolver forwards the DNS network activity to a cloud-based DNS security.

7. The system according to claim 1, wherein the processor further comprises A system configured to perform further security analysis on the suspicious domain using a confirmation queue in order to verify that the suspicious domain is malicious and promote it to a longer-term block, or to determine that the domain is not suspicious and not block the legitimate domain.

8. The system according to claim 1, wherein the processor is further configured to perform an action to block the suspicious domain in near real-time on the DNS security platform in response to the identification of the suspicious domain, The system blocks the aforementioned suspicious domain for at least a predetermined period of time.

9. The system according to claim 1, wherein the processor further, in response to confirmation that the suspicious domain is a malicious domain, A system configured to take action to block spear-phishing attacks using a DNS security platform.

10. The system according to claim 1, wherein the processor further comprises A system configured to report suspicious domains for the first network based on the DNS security policy associated with the first network.

11. It is a method, Monitor Domain Name System (DNS) network activity at the central DNS resolver, In order to transfer a subset of domains that have not been previously analyzed or have recently been registered for further security analysis, the primary detector filters the DNS network activity, In near real-time, the secondary detector identifies suspicious domains from a subset of the domains, Depending on the identified suspicious domain, take action. A method that includes [a certain feature].

12. A method according to claim 11, wherein the primary detector is configured to filter the DNS network activity based on a historical profile of previously queried domains.

13. A method according to claim 1, wherein the primary detector is configured to filter DNS network activity based on (1) the time at which a device anomaly is detected, and (2) a client IP address history record that includes one or more of the unauthorizedly accessed device and / or geolocation information.

14. A method according to claim 11, wherein the secondary detector is configured to score each of the subset of domains on one or more of the following: being hosted on a malicious top-level domain (TLD), being hosted on a reputation-based malicious name server, being associated with a known malicious ASN, DGA structure, and being associated with a domain-like structure.

15. A method according to claim 11, wherein the DNS network activity is filtered on a network basis for a plurality of monitored corporate, university, and / or government networks.

16. A method according to claim 11, wherein a cloud resolver forwards the DNS network activity to a cloud-based DNS security.

17. A computer program product embodied in a non-temporary computer-readable medium, Computer instructions for monitoring Domain Name System (DNS) network activity at a central DNS resolver, Computer instructions for filtering the DNS network activity in the primary detector in order to transfer a subset of domains that have not been previously analyzed or have recently been registered for further security analysis, A computer instruction for identifying suspicious domains from a subset of the domains in a secondary detector in near real-time, Depending on the identified suspicious domain, a computer instruction to perform an action, A computer program product that includes the following features.

18. A computer program product according to claim 17, wherein the primary detector is configured to filter DNS network activity based on a historical profile of previously queried domains.

19. A computer program product according to claim 1, wherein the primary detector is configured to filter DNS network activity based on (1) the time at which a device anomaly is detected, and (2) a client IP address history record that includes one or more of the unauthorizedly accessed device and / or geolocation information.

20. A computer program product according to claim 17, wherein the secondary detector is configured to score each of the subset of domains based on one or more of the following: being hosted on a malicious top-level domain (TLD), being hosted on a reputation-based malicious name server, being associated with a known malicious ASN, DGA structure, and being associated with a domain-like structure.

Images