US9270693B2 - Detection of infected network devices and fast-flux networks by tracking URL and DNS resolution changes - Google Patents

Abstract

A system and method for detecting Fast-Flux malware are presented. Domain name system (DNS) lookup requests to DNS servers from a local area network (LAN) to a wide area network (WAN) are monitored. The DNS lookup requests comprise requests to resolve uniform resource locators (URLs) to network addresses. The network addresses (IP) received from the DNS servers for the DNS lookup requests are monitored provide a URL-to-IP associations list. The DNS servers used for the DNS lookup requests for the URLs are monitored to provide a DNS Domain-to-DNS server associations list. A suspicious URL log based on the URL-to-IP associations list, and a suspicious DNS log based on the DNS Domain-to-DNS server associations list are generated.

Description

FIELD

Embodiments of the present disclosure relate generally to detection of threats in network devices. More particularly, embodiments of the present disclosure relate to detecting Advanced Persistent Threats.

BACKGROUND

On a company network where there may be valuable assets to be protected, many techniques and software and hardware solutions are employed to prevent the loss of those valuable assets, but the current solutions have proven ineffective at stopping the infiltration and exfiltration attempts of intellectual property and data. One technique used by attacking hackers, commonly referred to as Advanced Persistent Threats (hereafter referred to as “APT” or “APTs”), is to infect a target machine by some mechanism to install malware to perform actions on behalf of the attacking hacker. The APT will then begin to “call out” or “beacon” to a host or list of hosts on the internet on a recurring basis.

A purpose of these callouts is to get through firewalls (which tend to prevent much incoming traffic but allow most outgoing traffic) and allow the attacker to instruct or control the victim device to carry out actions such as surveying other systems, collecting data from the infected system, further infiltrating the network, and sending information back to the attacker. Attackers have over time evolved better techniques for performing this call-back so that it is more difficult to catch where infected hosts may be attempting to connect to.

One of the most advanced current techniques uses techniques referred to as “Fast-Flux” network systems for avoiding detections. Existing systems do not effectively identify Uniform Resource Locators (URLs) that frequently change Internet Protocol (IP) addresses or changing authoritative Domain Name System (DNS) servers. The existing systems generally use pre-defined lists of known suspicious URLs, IPs or Domain Name System to perform detections.

SUMMARY

A system and methods for detecting Fast-Flux malware are presented. Domain name system (DNS) lookup requests to DNS servers from a local area network (LAN) to a wide area network (WAN) are monitored. The DNS lookup requests comprise requests to resolve uniform resource locators (URLs) to network addresses. The network addresses received from the DNS servers for the DNS lookup requests are monitored to provide a URL-to-IP associations list. The authoritative DNS servers used for the DNS lookup requests for the URLs are monitored to provide a DNS Domain-to-DNS server associations list. A suspicious URL log based on the URL-to-IP associations list and a suspicious DNS log based on the DNS Domain-to-DNS server associations list are generated.

In this manner, embodiments of the disclosure use only algorithms to determine suspicious behaviors which allows for previously unknowingly bad URLs, internet protocol addresses (IPs), or DNS servers to be identified. Embodiments address a gap in current security monitoring and analysis systems and aims to identify Single-Flux and Double-Flux networks of the Fast-Flux network with a purpose of identifying internally infected network devices, which is a task that is not being performed by any service and system today. Embodiments of the disclosure detect APT computer malware by examining and tracking URL-to-IP resolution requests as well as the authoritative DNS servers which are providing the URL resolutions.

There may be expected to be many DNS servers in a DNS resolution chain which may be used, and many may not be known (e.g., as they may generally not be provided in a URL resolution response), but ones of interest are the authoritative DNS servers. By looking for changes in pairings, URL-to-IP and DNS Domain-to-DNS server embodiments identify the URLs and DNS servers most likely involved in a Fast-Flux malware network. Filters and control parameters are applied to this identification process to limit a number of false positive detections, and detected cases are used to identify network devices that may have been compromised.

In an embodiment, a method for detecting Fast-Flux malware monitors domain name system (DNS) lookup requests to DNS servers from a local area network (LAN) to a wide area network (WAN). The DNS lookup requests comprise requests to resolve uniform resource locators (URLs) to received network addresses (IP). The method further monitors the received network addresses (IP) received for the URLs from the DNS servers for the DNS lookup requests to provide a URL-to-IP associations list, and monitors the DNS servers used for the DNS lookup requests for the URLs to provide a DNS Domain-to-DNS server associations list. The method further generates a suspicious URL log based on the URL-to-IP associations list and a suspicious DNS log based on the DNS Domain-to-DNS server associations list.

In another embodiment, a system for detecting Fast-Flux malware comprises a network traffic monitor and a malware detector. The network traffic monitor monitors domain name server (DNS) lookup requests to DNS servers from a local area network (LAN) to a wide area network (WAN). The DNS lookup requests comprise requests to resolve uniform resource locators (URLs) to received network addresses (IP). The network traffic monitor further monitors the received network addresses (IP) received from the DNS servers for the DNS lookup requests to provide a URL-to-IP associations list, and monitors the DNS servers used for the DNS lookup requests for the URLs to provide a DNS Domain-to-DNS server associations list. The malware detector generates a suspicious URL log based on the URL-to-IP associations list and a suspicious DNS log based on the DNS Domain-to-DNS server associations list. The malware detector also indicates a presence of a malware program in the LAN based on the suspicious URL log and the suspicious DNS log.

In a further embodiment, a non-transitory computer readable storage medium comprising computer-executable instructions for detecting Fast-Flux malware. The computer-executable instructions monitor domain name server (DNS) lookup requests to DNS servers from a local area network (LAN) to a wide area network (WAN). The DNS lookup requests comprise requests to resolve uniform resource locators (URL)s to received network addresses (IP). The computer-executable instructions further monitor the received network addresses (IP) received from the DNS servers for the DNS lookup requests to provide a URL-to-IP associations list. The computer-executable instructions further monitor the DNS servers used for the DNS lookup requests for the URLs to provide a DNS Domain-to-DNS server associations list. The computer-executable instructions further generate a suspicious URL log based on the URL-to-IP associations list and a suspicious DNS log based on the DNS Domain-to-DNS server associations list.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF DRAWINGS

A more complete understanding of embodiments of the present disclosure may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures. The figures are provided to facilitate understanding of the disclosure without limiting the breadth, scope, scale, or applicability of the disclosure. The drawings are not necessarily made to scale.

FIG. 1 is an illustration of an exemplary flowchart showing a Fast-Flux malware detection process according to an embodiment of the disclosure.

FIG. 2 is an illustration of an exemplary flowchart showing a clearing process of the Fast-Flux malware detection process ofFIG. 1 in more detail according to an embodiment of the disclosure.

FIG. 3 is an illustration of an exemplary flowchart showing a Single-Flux URL-IP changes detection process of the Fast-Flux malware detection process ofFIG. 1 in more detail according to an embodiment of the disclosure.

FIG. 4 is an illustration of an exemplary flowchart showing a Double-Flux authoritative DNS changes detection process of the Fast-Flux malware detection process ofFIG. 1 in more detail according to an embodiment of the disclosure.

FIG. 5 is an illustration of an exemplary flowchart showing an identifying overlap process of the Fast-Flux malware detection process ofFIG. 1 in more detail according to an embodiment of the disclosure.

FIG. 6 is an illustration of an exemplary table showing possible raw storage results for use with Fast Flux and Double Flux tracking according to an embodiment of the disclosure.

FIG. 7 is an illustration of an exemplary table showing data in a suspicious URLs storage according to an embodiment of the disclosure.

FIG. 8 is an illustration of an exemplary table showing data in a suspicious DNS domain storage according to an embodiment of the disclosure.

FIG. 9 is an illustration of an exemplary functional block diagram of a Fast-Flux malware detection system according to an embodiment of the disclosure.

FIG. 10 is an illustration of an exemplary flowchart showing a Fast-Flux malware detection process according to an embodiment of the disclosure.

DETAILED DESCRIPTION

The following detailed description is exemplary in nature and is not intended to limit the disclosure or the application and uses of the embodiments of the disclosure. Descriptions of specific devices, techniques, and applications are provided only as examples. Modifications to the examples described herein will be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the disclosure. The present disclosure should be accorded scope consistent with the claims, and not limited to the examples described and shown herein.

Embodiments of the disclosure may be described herein in terms of functional and/or logical block components and various processing steps. It should be appreciated that such block components may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For the sake of brevity, conventional techniques and components related to signal processing, network and data communication, the Internet, Local Area Network (LAN), Wide Area Network (WAN), and other functional aspects of systems described herein (and the individual operating components of the systems) may not be described in detail herein. In addition, those skilled in the art will appreciate that embodiments of the present disclosure may be practiced in conjunction with a variety of hardware and software, and that the embodiments described herein are merely example embodiments of the disclosure.

Embodiments of the disclosure are described herein in the context of some non-limiting applications, namely, client. Embodiments of the disclosure, however, are not limited to such applications, and the techniques described herein may also be utilized in other applications. For example but without limitation, embodiments may be applicable to cloud services, cyber-security services, or other internet communication.

As would be apparent to one of ordinary skill in the art after reading this description, the following are examples and embodiments of the disclosure and are not limited to operating in accordance with these examples. Other embodiments may be utilized and structural changes may be made without departing from the scope of the exemplary embodiments of the present disclosure.

The Domain Name System (DNS) is a standard technology for managing the names of Web sites and other Internet domains. DNS technology allows a user to type names into the user Web browser like “compnetworking.about.com” and the user computer to automatically find that address on the Internet. An important element of the DNS is a worldwide collection of DNS servers. A DNS server is any computer registered to join the Domain Name System. A DNS server runs special-purpose networking software, features a public IP address, and contains a database of network names and addresses for other Internet hosts.

As mentioned above, attackers have over time evolved better techniques for performing call-backs so that it is more difficult to catch where infected hosts may be attempting to connect to. One of the most advanced current techniques uses techniques referred to as “Fast-Flux” and may comprise a “Single-Flux” and/or a “Double-Flux” network system for avoiding detections. Embodiments of the disclosure detect these Single-Flux and Double-Flux systems. These Flux networks work by using DNS networks to resolve URL values to IP addresses. Infected hosts do not need to have IP addresses pre-programmed, instead the URL or URL list remains static while the IP address that it resolves to can change on a regular and sometimes rapid basis.

A simplest type of Fast Flux, named “Single-Flux”, is characterized by multiple individual nodes within a network registering and de-registering their addresses as part of the DNS (address) record list for a single DNS name. This combines round robin DNS with a short (e.g., less than five minutes (300 s)) time-to-live (TTL) values to create a constantly changing list of destination addresses for that single DNS name. The list can be hundreds or thousands of entries long. A time frame that the TTL values will change may be difficult to determine, and isn't necessarily this short. A frequency of change may be significant.

A more sophisticated type of Fast-Flux, referred to as “Double-Flux”, is characterized by multiple nodes within the network registering and de-registering their addresses as part of the DNS Name Server record list for the DNS zone. This provides an additional layer of redundancy and survivability within a malware network.

Double-Flux systems resolve entire domains, and change the DNS server resolution to further increase volatility of a communication line, allowing more servers to participate in a command and control structure. A complexity and robustness of this communication structure makes it extremely difficult for network administrators and security personnel to identify infected devices which may be using this form of communication. Additionally, web and DNS traffic is often entirely overlooked by security personnel due to the volume and frequency that it occurs. Embodiments of the disclosure, address a problem of not being able to identify these infected devices by tracking URL-to-IP and DNS Domain-to-DNS server pairs and changes that they undergo, attempting to identify a communication system (i.e., identification of suspect URLs and DNS domains) that an infection uses so that infected devices can then be tracked and cleaned.

Identification of infected devices is currently performed using largely signature-based detection and human-in-the-loop examination. A problem of communication through the use of Single-Flux (URL-IP) and Double-Flux (DNS Domain) networks is not addressed in existing systems. Firewalling and blocking of suspect IPs is done using standard firewalls, whereas blocking URLs and DNS can be performed using services such as WebSense™, however these services require one or more of: 1) A subscription to the WebSense™ service, which provides a list and groupings of various URLs and Domains, which then allow administrators to block or approve connections based on specific URLs or URL groupings, and 2) Manual input and tuning of a WebSense™ URL Filtering device, to add and/or remove specific URLs and domains. Additionally, tools such as WebSense™ (or other whitelist/blacklist URL filters) use a pre-defined URL name list. In contrast, Embodiments dynamically discover suspected URLs automatically.

Moreover, existing systems do not effectively identify URLs that frequently change IP addresses or change authoritative DNS servers. The existing systems generally use pre-defined lists of known suspicious URLs, IPs, or DNS Domains to perform detections. In contrast, embodiments of the disclosure use only algorithms to determine suspicious behaviors which allows for previously unknowingly bad URLs, IPs, or DNS Domains to be identified. As mentioned above, embodiments address a gap in current security monitoring and analysis systems and aims to identify Single-Flux and Double-Flux networks with the purpose of identifying internally infected network devices, which is a task that is not being performed by any service today.

Furthermore, the existing systems rely on security personnel to discover some anomaly prior to investigating beaconing attempts. Beaconing attempts are inherently difficult to find due to the amount of traffic data seen on a corporate-size network. In contrast, embodiments of the disclosure use automated algorithms to detect these suspicious URLs, IPs, and DNS Domains. Security personnel are difficult to train and employees are a relatively high expense. Often security personnel are overworked and don't have time to address non-critical issues, so finding possibly infected hosts takes a back seat to more imminent non-optimality. In this manner, embodiments of the disclosure provide a means for security personnel to identify the infected devices without having to spend time doing so themselves, reducing their overall workload while allowing them to spend time more judiciously and increasing security on a monitored network.

Additionally, the existing systems provide only ways to block access to problematic IP addresses and URLs, but do not address finding those problematic values. An existing technique requires subscriptions, licenses, and proprietary hardware, all which cost additional money, and which ultimately only provides a list of probable-cause values, without identifying either the Single-Flux or Double-Flux networks, or locally infected devices. The locally infected devices therefore are not cleaned of the infection, even if they are placated by an inability to communicate (and assuming that other communication methods aren't already in place as a command-and-control backup system).

As explained in more detail below, embodiments of the disclosure detect Fast-Flux computer malware by examining and tracking URL-to-IP resolution requests as well as the authoritative DNS servers which are providing the URL resolutions. By looking for changes in the pairings URL-to-IP, and DNS Domain-to-DNS server embodiments identify the URLs and DNS servers most likely involved in a Fast-Flux malware network. Filters and control parameters are applied to the Fast-Flux detection process to limit the number of false positive detections, and the detected cases are used to identify network devices that may have been compromised.

FIGS. 1-5 are illustrations of exemplary flowcharts showing Fast-Flux malware detection processes100-500 according to an embodiment of the disclosure. The various tasks performed in connection with the processes100-500 may be performed by software, hardware, firmware, a computer-readable medium having computer executable instructions for performing the process method, or any combination thereof. The processes100-500 may be recorded in a non-transitory computer-readable medium such as a semiconductor memory, a magnetic disk, an optical disk, and the like, and can be accessed and executed, for example, by a computer CPU such as the processor module906 (FIG. 9) in which the computer-readable medium is stored.

It should be appreciated that the processes100-500 may include any number of additional or alternative tasks, the tasks shown inFIGS. 1-5 need not be performed in the illustrated order, and the processes100-500 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. In some embodiments, portions of the processes100-500 may be performed by different elements of a Fast-Flux detection system900 (FIG. 9) such as: anetwork traffic monitor902, amalware detector904, aprocessor module906, amemory module908, acommunication module910, etc. Processes100-500 may have functions, material, and structures that are similar to the embodiments shown inFIGS. 1-5. Therefore common features, functions, and elements may not be redundantly described here.

FIG. 1 is an illustration of an exemplary flowchart showing a Fast-Fluxmalware detection process100 according to an embodiment of the disclosure.Process100 shows a high level Fast-Fluxmalware detection process100, its expected inputs and outputs and the high level functionality of the Fast-Fluxmalware detection process100.

Process100 may begin by providing an input data such as the input data103 (task102). Theinput data103 to theprocess100 may comprise DNSresolutions information sources103A (DNS resolution information103A), which have occurred though some means. This information comprises most importantly an association of a URL to a specific internet IP address (URL-to-IP) as well as associations of DNS Domains to authoritative DNS servers (DNS Domain-to-DNS server). Theinput data103 may be obtained, for example but without limitation, by logging the DNS queries andresults103B (DNS server logging103B) from a localized DNS server (either on a local machine as inLocal DNS resolutions103C or a dedicated server on a regional network), performing analysis of DNS traffic from packet captures103D (DNSpacket capture analysis103D) or performing automated, intentional DNS queries103E (deliberate DNS resolution testing103E) for URLs or domains which may be suspect, or other means of collecting the input.

Process100 may continue by collecting theinput data103 from any feeder sources and run raw data through an initial filtering mechanism (task104). Filtering is performed based on a DNS collection filtering configuration list105 (filter105) maintained manually or automatically. Thefilter105 is used to limit theinput data103 from thetask102 to be free from DNS resolution information that has already been investigated and determined not to be suspicious. If the incomingDNS resolution information103A of theinput data103 is marked to be filtered out (Yes branch of inquiry task104), then it is ignored (task106), otherwise (No branch of inquiry task104), theinput data103 is normalized (task108) to provide normalized input data.

Thenormalization task108 converts theinput data103 into a standard form to provide the normalized input data that can be stored in a DNSinformation storage database110. Exemplary normalized input data are shown in table600 (FIG. 6) below.

The normalized input data from the DNSinformation storage database110 is removed from the DNS information storage database110 (task124) usually on a time interval (e.g., all data arriving in the last 10 minutes) and is processed in parallel by both a URL-to-IP change-over-time detector (aka Single-Flux APT) (task112) and an authoritative DNS server change-over-time detector (aka Double-Flux APT) (task114).Tasks112 and114 are shown below in more detail in the context of discussion ofFIGS. 3 and 4 respectively.

Process100 may continue by providing output data (task116). The output data or event list may comprise, for example but without limitation, data in a form of security events that indicate that specific URLs, specific Domains, or both a specific URL and a specific Domain, are suspected as being part of an APT botnet. A botnet is a collection of internet-connected programs communicating with other similar programs in order to perform tasks.

Output data from thetasks112 and114 comprise both event lists and tracking data. The tracking data for suspicious URL is stored in a suspiciousURL storage database118 as shown in an exemplary table700 (FIG. 7) below. The tracking data for suspicious DNS domain is stored in an authoritativeDNS storage database120 as shown in an exemplary table800 (FIG. 8).

Process100 may then continue by identifying overlapping findings (task122) from the Single-Flux detector (task112) and the Double-Flux detector (task114). The suspiciousURL storage database118 and the authoritativeDNS storage database120 provide input to thetask122 to identify overlapping findings from the Fast-Flux and Double-Flux detectors which then may output additional event list (task116) items.

Process100 may continue by database cleanup processes (tasks124,126 and128) as explained in more detail in the context of discussion ofFIG. 2 below. The database cleanup processestasks124,126 and128 keep the data in their respective storages trimmed and storing only appropriate data.

FIG. 2 is an illustration of an exemplary flowchart showing a clearing (cleanup)process200 of the Fast-Fluxmalware detection process100 ofFIG. 1 in more detail according to an embodiment of the disclosure. Theclearing process200 performs thetasks124,126, and128 of thedetection process100 to keep the data trimmed and stores only appropriate data in the threerespective storage databases110,118, and120. The same process is used for each of thetasks124,126,128.

All data is reviewed one element (row) at a time (202,214, and226). Each element (row) is checked to determine it is older than a time limit (inquiry tasks204,216, and228). The time limit (210,222, and234) may be configured manually. For example but without limitation, a nominal time limit may be configured to keep data no more than 12 months, or other time limit. If the element is older than the time limit (Yes branch ofinquiry tasks204,216, and228) then that row is deleted (removed) from the storage (tasks208,220, and232). If the element is not older than the time limit (No branch ofinquiry tasks204,216, and228) then it is further compared (inquiry tasks206,218, and230) to a list of known non-suspicious URLs and non-suspicious domains and/or non-suspicious authoritative DNS servers (212,224, and236). If the data element (row) from the data storage contains information that is now believed to be no longer suspicious (i.e., marked as now filtered, Yes branch ofinquiry tasks206,218, and230) then the data element (row) is deleted (removed) from the data store (tasks208,220,232).

FIG. 3 is an illustration of an exemplary flowchart showing a Single-Flux URL-IPchanges detection process300 of the Fast-Fluxmalware detection process100 ofFIG. 1 in more detail according to an embodiment of the disclosure.

Process300 may begin by collecting a list (task302) of all of the new URL-IP associations added to the DNSinformation storage database110 since the last time the processing was performed (or, in the case that processing is continually being performed, the next newest result from the storage). For each result retrieved, a series of actions and analysis is then performed based on the data provided by the result and the historical data stored (from other results) in order to determine whether a change in the IP address for the URL is suspicious (or not) as explained below.

For each new result, data is passed in parallel to four different processes: total quantity of URL-to-IP association changes (tasks306-312), quantity of URL-to-IP association changes in a time period (tasks314-322), frequency of URL-to-IP association changes (tasks326 to334), and patterns of URL-to-IP association changes (tasks336 to342).

Each URL-to-IP mapping data element such as arow602 in the table600 (FIG. 6) is checked atinquiry task306 to determine if the total quantity of changes detection should be performed for this URL and/or IP. This additional filtering step allows restrictions to be placed on results for only this type of detection, not all detections. This filter is controlled from afilter list304 that may be manually controlled. If this result is filtered out (Yes branch of inquiry task306) then it is ignored (task324) andprocess300 continues with the next new item (new URL-TO-IP-mapping) (task302). If the result is not filtered out (No branch of inquiry task306) then an entire storage history from the DNSinformation storage database110 is searched for other occurrences where the URL is a match, and a number of results returned are counted counting a total number of association changes (total number of URL-IP Mapping changes) (task308) and compared to a configured total-association-change-threshold (inquiry task310) for this type of detection.

The total-association-change-threshold configuration (312) is suitably set for operation of thesystem900. For example but without limitation, total-association-change-threshold may be 500 changes (e.g., where the total stored timeframe is 12 months). Total changes may be loosely dependent on a total timeframe for data stored. If the number of results (number of total changes) (task308) is greater than the total-association-change-threshold (Yes branch of inquiry task310), theprocess300 proceeds totask346 and logs suspicious URL data to provide a suspicious resource log.

Each URL-to-IP mapping data element such as therow602 in table600 is checked atinquiry task314 to determine if the quantity of changes within a time period detection should be performed for this URL and/or IP. This additional filtering step allows restrictions to be placed on results for only this type of detection, not all detections. This filter is controlled from afilter list316 that may be manually controlled. If this result is filtered out (Yes branch of inquiry task314), then it is ignored (task324) andprocess300 continues with the next new item (task302). If the result is not filtered out (No branch of inquiry task314), then the entire storage history from the DNSinformation storage database110 is searched for other occurrences where the URL is a match, and the number of results returned are counted, counting a number of association changes in a time-period (task318) and compared to a configured time-period-association-changes-threshold (inquiry task320) for this type of detection.

The time-period-association-changes-threshold (322) is suitably set for operation of thesystem900. For example but without limitation, the time-period-association-changes-threshold may be 50 changes for a 1 hour time period. The threshold is a single value against which a number of changes is compared. If the number of results (task318) is greater than the time-period-association-changes-threshold (Yes branch of inquiry task320), theprocess300 proceeds totask346.

Each URL-to-IP mapping data element such as therow602 in the table600 is checked atinquiry task326 to determine if the frequency of changes detection should be performed for this URL and/or IP. This additional filtering step allows restrictions to be placed on results for only this type of detection, not all detections. This filter is controlled from afilter list328 that may be manually controlled. If this result is filtered out (Yes branch of inquiry task326) then it is ignored (task352) andprocess300 continues with the next new item (task302). If the result is not filtered out (No branch of inquiry task326) then the entire storage history is searched for other occurrences where the URL is a match, and the frequency of changes of the URL-to-IP mapping is calculated calculating an association change frequency (task330) and compared to a configured association-change-frequency-threshold (inquiry task332) for this type of detection.

The association-change-frequency-threshold334 is suitably set for operation of thesystem900. For example, but without limitation, the association-change-frequency-threshold may be 5 minutes, indicating that a change of the URL-to-IP mapping occurs usually more frequently than once every 5 minutes. This change frequency may be represented in a different manner, but the association-change-frequency-threshold334 may indicate a limit on how often the change occurs, and results pass the association-change-frequency-threshold334 if the change of the URL-to-IP mapping occurs more often than the association-change-frequency-threshold334 specifies. If the frequency of changes of the URL-to-IP mapping (task330) is less than the association-change-frequency-threshold334 (Yes branch of inquiry task332), theprocess300 proceeds totask346.

Each URL-to-IP mapping data element such as therow602 in table600 is checked atinquiry task336 to determine if the patterns of changes of URL-to-IP association detection should be performed for this URL and/or IP. This additional filtering step allows restrictions to be placed on results for only this type of detection, not all detections. This filter is controlled from afilter list338 that may be manually controlled. If this result is filtered out (Yes branch of inquiry task336) then it is ignored (task338) andprocess300 continues with the next new item (task302). If the result is not filtered out (No branch of inquiry task336) then the entire storage history from the DNSinformation storage database110 is searched for any items that match the URL (task340). The found items are organized chronologically and examined to determine if a pattern, or patterns, is present (inquiry task342).

Apattern configuration344 is suitably set for operation of thesystem900. For example, but without limitation, thepattern configurations344 may be a consistent amount of time between changes in the URL-IP resolution, or other pattern. If the pattern, or patterns, are present (Yes branch of inquiry task342), theprocess300 proceeds totask346.

For each resultpath reaching process300 logs suspicious URL data (task346) in suspicious resource log, stores suspicious URL in the suspicious URL storage354 (task348) for later use. Then process300 searches the entire DNSinformation storage database110 and retrieves a list of all client devices that have queried this suspicious URL within a time period (task350). This provides information if there were more than one infected client device that is performing the same suspicious access. This data is then provided to an event generation process (task352) which will consolidate detected suspicious URLs so that there are not unnecessary duplicate events generated to the external event list (task116).

FIG. 4 is an illustration of an exemplary flowchart showing a Double-Flux authoritative DNSchanges detection process400 of the Fast-Flux malware detection process ofFIG. 1 in more detail according to an embodiment of the disclosure.Process400 may have functions, material, and structures that are similar to the embodiments shown inprocess300. Therefore common features, functions, and elements may not be redundantly described here. The principal difference betweenprocess300 and400 is that theprocess400 is performed using an association between a Domain and an authoritative DNS server location address (such as IP).

Instead of the URLs,process400 uses Domains, and instead of device IP addresses corresponding to the URLs, a location address of the authoritative DNS server is used. Theprocess400 uses data similar to process300 such as input and output events as well as inserting information about suspicious domains into a storage database. So process400 is not redundantly described herein.

For example,process400 configures a resource association list comprising the DNS Domain-to-DNS server associations list instead of URL-to-IP associations list configured by theprocess300.Process400 configures a suspicious DNS log instead of a suspicious URL log configured by theprocess300.

FIG. 5 is an illustration of an exemplary flowchart showing the overlap identifying process500/122 of the Fast-Flux detection process ofFIG. 1 in more detail according to an embodiment of the disclosure. Theprocess122 identifies Single-Flux URL and Double-Flux authoritative DNS server domain overlap. Theprocess122 uses thesuspicious URL storage354 outputted in theprocess300 and the suspiciousauthoritative DNS storage454 outputted in theprocess400 as input and produces theevent list116 for use by the external systems.

Theprocess122 may begin by gathering a list of new (unprocessed) items from the suspicious URL storage354 (task502) and from the suspicious authoritative DNS storage454 (task512) and iterating through each item.

For each suspicious URL items from the task502 a search is performed in the suspiciousauthoritative DNS storage454 for Double-Flux results which occurred during the same time period that the URL was considered suspicious (task504). Finding both at the same time indicates that both the URL and the domain underwent changes during the same period of time, indicating that both single-Flux and Double-Flux actions were active. If a match is not found (No branch of inquiry task506) then this element is ignored (task508) andprocess122 continues processing with the next element. If a match is found (Yes branch of inquiry task506) then combine all known data and generate an event for combination found (task510) to be output to an external event list (task116).

For the suspicious domain items from task512 a search is performed in thesuspicious URL storage354 for Single-Flux results which occurred during the same time period that the domain was considered suspicious (task514). Finding both at the same time indicates that both the domain and URL underwent address changes during the same period of time, indicating that both Double Flux and Single Flux actions were active. If a match is not found (No branch of inquiry task516) then this element is ignored (task508) andprocess122 continues with the next element. If a match is found (Yes branch of inquiry task516) then process122 combine all known data and generate an event for the combination found (task518) to be output to the external event list (task116).

FIG. 6 is an illustration of an exemplary table600 showing possible raw storage results for use with Single-Flux and Double-Flux tracking according to an embodiment of the disclosure. The table600 shows an example of a possible storage solution for storing the DNS data in DNSinformation storage database110. Row602 shows exemplary normalized records stored in the DNSinformation storage database110. Other database formats and data suitable for operation ofsystem900 may also be used to generate the table600.

FIG. 7 is an illustration of an exemplary table700 showing data in a suspicious URLs storage according to an embodiment of the disclosure. The table700 provides an example of a possible storage solution for the list of suspiciousURL storage database118 and354. Other database formats and data suitable for operation ofsystem900 may also be used to generate the table700.

FIG. 8 is an illustration of an exemplary table showing data in a suspicious DNS domain storage according to an embodiment of the disclosure. The table800 shows an example of a possible storage solution for the list of the tracking data for suspicious DNS domains stored in the authoritativeDNS storage database120 and448. Other database formats and data suitable for operation ofsystem900 may also be used to generate the table800.

FIG. 9 is an illustration of an exemplary functional block diagram of a Fast-Flux detection system900 according to an embodiment of the disclosure. The Fast-Flux detection system900 may comprise: anetwork traffic monitor902, amalware detector904, aprocessor module906, amemory module908, and acommunication module910.

Thenetwork traffic monitor902 is configured to monitor a plurality of domain name system (DNS)lookup requests914 to one ormore DNS servers916 from a local area network (LAN)918 to a wide area network (WAN)920, the DNS lookup requests914 comprising a plurality of requests to resolve one or more uniform resource locators (URLs) to one or more received network addresses (e.g., internet protocol (IP) addresses). Thenetwork traffic monitor902 is further configured to monitor the received network addresses (IP)922 received for theURLs924 from theDNS servers916 for the DNS lookup requests914 to provide a URL-to-IP associations list928. The received network addresses (IP)922 may comprise, for example but without limitation, an internet protocol address, an Ethernet address, or other network address. Thenetwork traffic monitor902 is further configured to monitor theDNS servers916 used for the DNS lookup requests914 for theURLs924 to provide a DNS Domain-to-DNS server associations list926.

Themalware detector904 is configured to generate the suspicious URL log346 based on the URL-to-IP associations list928 and the suspicious DNS log446 based on the DNS Domain-to-DNS server associations list926 and indicate a presence of a malware program in theLAN918 based on thesuspicious URL log346 and thesuspicious DNS log446.

Theprocessor module906 comprises processing logic that is configured to carry out the functions, techniques, and processing tasks associated with the operation of thesystem900. In particular, the processing logic is configured to support thesystem900 described herein. For example, theprocessor module906 may direct thenetwork traffic monitor902 and themalware detector904 in thesystem900.

Theprocessor module906 may be implemented, or realized, with a general purpose processor, a content addressable memory, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In this manner, a processor may be realized as a microprocessor, a controller, a microcontroller, a state machine, or the like. A processor may also be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration.

Thememory module908 may comprise a data storage area with memory formatted to support the operation of thesystem900. Thememory module908 is configured to store, maintain, and provide data as needed to support the functionality of thesystem900. For example but without limitation, thememory module908 may store data, such as but without limitation, thenetwork address922, the suspiciousURL storage database118, the suspicious DNSdomain storage database120/454, thesuspicious URL log346, thesuspicious DNS log446, the URL-to-IP list928, the DNS-To-DNSserver association list926, time, date, frequency, pattern, or other data.

In some embodiments, thememory module908 may comprise, for example but without limitation, a non-volatile storage device (e.g., non-volatile semiconductor memory, hard disk device, optical disk device, and the like), a random access storage device (for example, SRAM, DRAM), or any other form of non-transitory storage medium known in the art.

Additionally, thememory module908 may represent dynamically updating databases containing tables for updating the databases, and the like. Thememory module908 may also store, a computer program that is executed by theprocessor module906, an operating system, an application program, tentative data used in executing a program, or other application.

Thememory module908 may be coupled to theprocessor module906 such that theprocessor module906 can read information from and write information to thememory module908. For example, theprocessor module906 may access thememory module908 to access the data stored in thememory module908 as explained above.

As an example, theprocessor module906 andmemory module908 may reside in respective application specific integrated circuits (ASICs). Thememory module908 may also be integrated into theprocessor module906. In an embodiment, thememory module908 may comprise a cache memory for storing temporary variables or other intermediate information during execution of instructions to be executed by theprocessor module906.

Thecommunication module910 is operable to transmit and receive a plurality of communication signals comprising data signals via a transceiver (not shown) under control of theprocessor module906. Thecommunication module910 operates with anantenna912 to carry out a radio communication with a network side device via a base station communicatively coupled to a wireless communication network (not shown).

Thecommunication module910 can transmit a signal from theprocessor module906 as a transmitted radio signal to a base station through theantenna912, and can demodulate a received radio signal received from the base station through theantenna912. Theprocessor module906 receives a demodulated signal form thecommunication module910.

Thecommunication module910 may also comprise an Ethernet/USB communication module (not shown) configured to provide communication between thesystem900 and the electronic resources via Ethernet. The Ethernet/USB communication module communicates with the Internet through an access port to download documents, and to interact with Web-based services.

Those skilled in the art will understand that the various illustrative blocks, modules, circuits, and processing logic described in connection with the embodiments disclosed herein may be implemented in hardware, computer-readable software, firmware, or other combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps are described generally in terms of their functionality.

In some embodiments, thesystem900 may comprise any number of processor modules, any number processing modules, any number of memory modules, any number of transmitter modules, and any number of receiver modules suitable for their operation described herein. The illustratedsystem900 depicts a simple embodiment for ease of description. These and other elements of thesystem900 are interconnected together, allowing communication between the various elements ofsystem900. In one embodiment, these and other elements of thesystem900 may be interconnected together via a respectivedata communication bus926.

A transmitter module and a receiver module may be located in theprocessor module906 coupled to a sharedantenna912. Although in a simple module only one sharedantenna912 may be provided, more sophisticated modules may be provided with multiple and/or more complex antenna configurations. Additionally, although not shown in thisFIG. 9, those skilled in the art will recognize that a transmitter may transmit to more than one receiver, and that multiple transmitters may transmit to a same receiver.

Whether such functionality is implemented as hardware, firmware, or software depends upon the particular application and design constraints imposed on the overall system. Those familiar with the concepts described herein may implement such functionality in a suitable manner for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

FIG. 10 is an illustration of an exemplary flowchart showing a Fast-Flux malware detection process (process1000) according to an embodiment of the disclosure. The various tasks performed in connection withprocess1000 may be performed mechanically, by software, hardware, firmware, computer-readable software, computer readable storage medium, or any combination thereof. It should be appreciated thatprocess1000 may include any number of additional or alternative tasks, the tasks shown inFIG. 10 need not be performed in the illustrated order, and theprocess1000 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein.

For illustrative purposes, the following description ofprocess1000 may refer to elements mentioned above in connection withFIG. 9. In some embodiments, portions of theprocess1000 may be performed by different elements of thesystem900 such as: thenetwork traffic monitor902, themalware detector904, theprocessor module906, thememory module908, thecommunication module910, etc. It should be appreciated thatprocess1000 may include any number of additional or alternative tasks, the tasks shown inFIG. 2 need not be performed in the illustrated order, and theprocess1000 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein.

Process1000 may begin by monitoring a plurality of domain name system (DNS) lookup requests to one or more DNS servers from a local area network (LAN) to a wide area network (WAN), the DNS lookup requests comprising a plurality of requests to resolve one or more uniform resource locators (URLs) to one or more received network addresses (IP) (task1002).

Process1000 may continue by monitoring the received network addresses (IP) received for the URLs from the DNS servers for the DNS lookup requests to provide a URL-to-IP associations list (task1004).

Process1000 may continue by monitoring the DNS servers used for the DNS lookup requests for the URLs to provide a DNS Domain-to-DNS server associations list (task1006).

Process1000 may continue by generating a suspicious URL log based on the URL-to-IP associations list and a suspicious DNS log based on the DNS Domain-to-DNS server associations list (task1008).

Process1000 may continue by indicating a presence of a malware program in the LAN based on the suspicious DNS log and the suspicious URL log (task1010).

Process1000 may continue by configuring a resource association list comprising the URL-to-IP associations list or the DNS Domain-to-DNS server associations list (task1012).

Process1000 may continue by configuring a suspicious resource log comprising the suspicious URL log or the suspicious DNS log (task1014).

Process1000 may continue by counting a total number of association changes in the resource association list (task1016).

Process1000 may continue by logging the suspicious resource log, if the total number of association changes is greater than a total-association-change threshold (task1018).

Process1000 may continue by counting a number of association changes in the resource association list in a time-period (task1020).

Process1000 may continue by logging the suspicious resource log, if the number of association changes in the time-period is greater than a time-period-association-changes threshold (task1022).

Process1000 may continue by calculating an association change frequency of the resource association list (task1024).

Process1000 may continue by logging the suspicious resource log, if the association change frequency is greater than an association-change-frequency threshold (task1026).

Process1000 may continue by calculating a pattern in the resource association list (task1028).

Process1000 may continue by logging the suspicious resource log, if the pattern is found among a pattern history (task1030).

In this manner, a system and method are provided to identify Single-Flux and Double-Flux networks with the purpose of identifying internally infected network devices, which is a task that is not being performed by existing systems. Embodiments of the disclosure detect APT computer malware by examining and tracking URL-to-IP resolution requests as well as the authoritative DNS servers which are providing the URL resolutions. By searching for changes in the pairings, embodiments identify the URLs and DNS servers most likely involved in a Fast-Flux malware network.

Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future.

Likewise, a group of items linked with the conjunction “and” should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as “and/or” unless expressly stated otherwise. Similarly, a group of items linked with the conjunction “or” should not be read as requiring mutual exclusivity among that group, but rather should also be read as “and/or” unless expressly stated otherwise. Furthermore, although items, elements or components of the disclosure may be described or claimed in the singular, the plural is contemplated to be within the scope thereof unless limitation to the singular is explicitly stated. The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent.

The above description refers to elements or nodes or features being “connected” or “coupled” together. As used herein, unless expressly stated otherwise, “connected” means that one element/node/feature is directly joined to (or directly communicates with) another element/node/feature, and not necessarily mechanically. Likewise, unless expressly stated otherwise, “coupled” means that one element/node/feature is directly or indirectly joined to (or directly or indirectly communicates with) another element/node/feature, and not necessarily mechanically. Thus, althoughFIG. 9 depicts example arrangements of elements, additional intervening elements, devices, features, or components may be present in an embodiment of the disclosure.

In this document, the terms “computer program product”, “computer-readable medium”, “computer readable storage medium”, and the like may be used generally to refer to media such as, for example, memory, storage devices, or storage unit. These and other forms of computer-readable media may be involved in storing one or more instructions for use by theprocessor module906 to cause theprocessor module906 to perform specified operations. Such instructions, generally referred to as “computer program code” or “program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable thesystem900.

As used herein, unless expressly stated otherwise, “operable” means able to be used, fit or ready for use or service, usable for a specific purpose, and capable of performing a recited or desired function described herein. In relation to systems and devices, the term “operable” means the system and/or the device is fully functional and calibrated, comprises elements for, and meets applicable operability requirements to perform a recited function when activated. In relation to systems and circuits, the term “operable” means the system and/or the circuit is fully functional and calibrated, comprises logic for, and meets applicable operability requirements to perform a recited function when activated.

Claims (20)

The invention claimed is:

1. A method for detecting Fast-Flux malware, the method comprising:

monitoring by a network traffic monitor a plurality of domain name system (DNS) lookup requests to one or more DNS servers initiated by one or more network devices in a local area network (LAN) to a wide area network (WAN), the DNS lookup requests comprising a plurality of requests to resolve one or more uniform resource locators (URLs) to one or more received network addresses (IP);

monitoring the one or more received network addresses (IP) resolved for the one or more URLs to provide a URL-to-IP associations list, wherein the URL-to-IP associations list is configured to store one or more suspicious URLs;

monitoring the one or more DNS servers used for the DNS lookup requests for resolving the URLs to provide a DNS Domain-to-DNS server associations list;

generating a suspicious URL log based on the URL-to-IP associations list and a suspicious DNS log based on the DNS Domain-to-DNS server associations list;

determining whether a designated suspicious URL from the suspicious URL log matches designated data in the suspicious DNS log; and

after determining that the designated suspicious URL from the suspicious URL log matches the designated data in the suspicious DNS log, generating an event indicating a combination of flux actions are active.

2. The method ofclaim 1, further comprising indicating a presence of a malware program in the LAN based on the suspicious DNS log and the suspicious URL log.

3. The method ofclaim 1, further comprising:

configuring a resource association list comprising the URL-to-IP associations list or the DNS Domain-to-DNS server associations list; and

configuring a suspicious resource log comprising the suspicious URL log or the suspicious DNS log.

4. The method ofclaim 3, further comprising:

counting a total number of association changes in the resource association list; and

logging the suspicious resource log, if the total number of association changes is greater than a total-association-change threshold.

5. The method ofclaim 3, further comprising:

counting a number of association changes in the resource association list in a time-period; and

logging the suspicious resource log, if the number of association changes in the time-period is greater than a time-period-association-changes threshold.

6. The method ofclaim 3, further comprising:

calculating an association change frequency of the resource association list; and

logging the suspicious resource log, if the association change frequency is greater than an association-change-frequency threshold.

7. The method ofclaim 3, further comprising:

calculating a pattern in the resource association list; and

logging the suspicious resource log, if the pattern is found among a pattern history.

8. A system for detecting Fast-Flux malware, the system comprising:

at least one hardware processor; and

a network traffic monitor operating on the at least one hardware processor and configured to:

monitor a plurality of domain name system (DNS) lookup requests to one or more DNS servers initiated by one or more network devices in a local area network (LAN) to a wide area network (WAN), the DNS lookup requests comprising a plurality of requests to resolve one or more uniform resource locators (URLs) to one or more received network addresses (IP);

monitor the one or more received network addresses (IP) resolved for resolving the one or more URLs to provide a URL-to-IP associations list;

monitor the one or more DNS servers used for the DNS lookup requests for resolving the URLs to provide a DNS Domain-to-DNS server associations list; and

a malware detector configured to:

generate a suspicious URL log based on the URL-to-IP associations list and a suspicious DNS log based on the DNS Domain-to-DNS server associations list;

determine whether a designated suspicious URL from the suspicious URL log matches designated data in the suspicious DNS log;

after determining that the designated suspicious URL from the suspicious URL log matches the designated data in the suspicious DNS log, generate an event indicating a combination of flux actions are active; and

indicate a presence of a malware program in the LAN based on the suspicious URL log and the suspicious DNS log.

9. The system ofclaim 8, wherein:

a resource association list comprises the URL-to-IP associations list or the DNS Domain-to-DNS server associations list; and

a suspicious resource log comprises the suspicious URL log or the suspicious DNS log.

10. The system ofclaim 9, wherein the malware detector is further configured to:

count a total number of association changes in the resource association list; and

log the suspicious resource log, if the total number of association changes is greater than a total-association-change threshold.

11. The system ofclaim 9, wherein the malware detector is further configured to:

count a number of association changes in the resource association list in a time-period; and

log the suspicious resource log, if the number of association changes in the time-period is greater than a time-period-association-changes threshold.

12. The system ofclaim 9, wherein the malware detector is further configured to:

calculate an association change frequency of the resource association list; and

log the suspicious resource log, if the association change frequency is greater than an association-change-frequency threshold.

13. The system ofclaim 9, wherein the malware detector is further configured to:

calculate a pattern in the resource association list; and

log the suspicious resource log, if the pattern is found among a pattern history.

14. A non-transitory computer readable storage medium comprising computer-executable instructions for detecting Fast-Flux malware, the computer-executable instructions comprising:

monitoring by a network traffic monitor a plurality of domain name system (DNS) lookup requests to one or more DNS servers initiated by one or more network devices in a local area network (LAN) to a wide area network (WAN), the DNS lookup requests comprising a plurality of requests to resolve one or more uniform resource locators (URLs) to one or more received network addresses (IP);

monitoring the one or more received network addresses (IP) resolved for resolving the one or more URLs to provide a URL-to-IP associations list;

monitoring the one or more DNS servers used for the DNS lookup requests for resolving the URLs to provide a DNS Domain-to-DNS server associations list;

generate a suspicious URL log based on the URL-to-IP associations list and a suspicious DNS log based on the DNS Domain-to-DNS server associations list;

determining whether a designated suspicious URL from the URL-to-IP associations list matches designated data in the DNS Domain-to-DNS server associations list; and

after determining that the designated suspicious URL from the URL-to-IP associations list matches the designated data in the DNS Domain-to-DNS server associations list, generating an event indicating a combination of flux actions are active.

15. The non-transitory computer readable storage medium ofclaim 14, further comprising computer-executable instructions comprising: indicating a presence of a malware program in the LAN based on the suspicious DNS log or the suspicious URL log.

16. The non-transitory computer readable storage medium ofclaim 14, further comprising computer-executable instructions comprising:

configuring a resource association list comprising the URL-to-IP associations list or the DNS Domain-to-DNS server associations list; and

configuring a suspicious resource log comprising the suspicious URL log or the suspicious DNS log.

17. The non-transitory computer readable storage medium ofclaim 16, further comprising computer-executable instructions comprising:

counting a total number of association changes in the resource association list; and

logging the suspicious resource log, if the total number of association changes is greater than a total-association-change threshold.

18. The non-transitory computer readable storage medium ofclaim 16, further comprising computer-executable instructions comprising:

counting a number of association changes in the resource association list in a time-period; and

logging the suspicious resource log, if the number of association changes in the time-period is greater than a time-period-association-changes threshold.

19. The non-transitory computer readable storage medium ofclaim 16, further comprising computer-executable instructions comprising:

calculating an association change frequency of the resource association list; and

logging the suspicious resource log, if the association change frequency is greater than an association-change-frequency threshold.

20. The non-transitory computer readable storage medium ofclaim 16, further comprising computer-executable instructions comprising:

calculating a pattern in the resource association list; and

logging the suspicious resource log, if the pattern is found among a pattern history.

Images