Patent Publication Number: US-9894088-B2

Title: Data mining to identify malicious activity

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is based on and derives the benefit of the filing date of U.S. Provisional Patent Application No. 61/696,009, filed Aug. 31, 2012. The entire content of this application is herein incorporated by reference in its entirety. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  depicts a network according to an embodiment of the invention. 
       FIG. 2  depicts a monitoring process according to an embodiment of the invention. 
       FIG. 3A  depicts an analysis system according to an embodiment of the invention. 
       FIG. 3B  depicts an analysis system according to an embodiment of the invention. 
       FIG. 4  depicts an analysis process according to an embodiment of the invention. 
       FIG. 5  depicts a real time analysis process according to an embodiment of the invention. 
       FIG. 6  depicts an historical analysis process according to an embodiment of the invention. 
    
    
     DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS 
     Methods and systems described herein may detect malicious activity, for example malicious activity within computer networks, present users with evidence in order to confirm an identification of infection, and/or annotate a detection with information which may explain some or all of the infection cycle allowing users to revisit their security policies and/or understand the severity of the infection. Identification, capture, index, and/or examination of network summary information, including network summary information which might contribute to a detection or understanding of a threat, may be performed. Historical, present, and/or future network events may be compared to simulated data in order to discover effects and/or implications of malicious activity. Historical, present, and/or future network data may be re-examined, captured, and/or indexed to discover precursors to malicious activity, present malicious activity, and/or future malicious activity. Discovery and/or recovery of historical infector malware may be performed based on future network communications. The probability of maliciousness in network traffic patterns and/or the degree of automation within suspicious network activity may be determined. 
     Devices operating the various applications and performing the various processes described herein may comprise one or more computers. Computers may be linked to one another via a network or networks. A computer may be any programmable machine capable of performing arithmetic and/or logical operations. In some embodiments, computers may comprise processors, memories, data storage devices, and/or other commonly known or novel components. These components may be connected physically or through network or wireless links. Computers may also comprise software which may direct the operations of the aforementioned components. Computers may be referred to with terms that are commonly used by those of ordinary skill in the relevant arts, such as servers, PCs, mobile devices, and other terms. It will be understood by those of ordinary skill that those terms used herein are interchangeable, and any computer capable of performing the described functions may be used. For example, though the term “server” may appear in the following specification, the disclosed embodiments are not limited to servers. A network may be any plurality of completely or partially interconnected computers wherein some or all of the computers are able to communicate with one another. It will be understood by those of ordinary skill that connections between computers may be wired in some cases (i.e. via Ethernet, coaxial, optical, or other wired connection) or may be wireless (i.e. via WiFi, WiMax, or other wireless connection). Connections between computers may use any protocols, including connection oriented protocols such as TCP or connectionless protocols such as UDP. Any connection through which at least two computers may exchange data can be the basis of a network. 
       FIG. 1  depicts a network  100  according to an embodiment of the invention. The network  100  may be, for example, an internal network such as a business network, home network, educational network, or the like. The network  100  may include assets  110  such as computers, switches, routers, other networked devices, and/or other infrastructure to support internal and external network communications. Each asset  110  may be an individual endpoint ( 111 ,  112 , . . . n) within the network  100 . The network  100  may also include infrastructure  130  for facilitating external network communication, for example firewalls, proxy servers, DNS servers, routers, and/or switches. This infrastructure  130  may enable network traffic  120  to flow to and from external networks  150  such as the Internet or a private network. One or more computer systems  140  for identifying malicious network activity may also be included in the network  100 . As will be described in greater detail below, these systems  140  may have deep packet inspection, packet reassembly, and/or traffic analysis capabilities for monitoring assets  110  and traffic  120 . These systems  140  may identify and capture/index network summary information which might contribute to an increased detection or understanding of a threat: By storing summary attributes of certain network events, it may be possible to both efficiently capture/index attributes as well as search and correlate this data. The network  100  of  FIG. 1  may be a typical network description, but the systems and methods described herein are not limited to any specific network topology, network traffic, or destinations residing on the Internet. For example external networks  150  may include a private network, infrastructure  130  may represent varying combinations of network infrastructure and different topologies, and the network  100  may be a service provider network, an MPLS WAN network, or a higher-ed (EDU) network. 
     Capture and Index of Network Information 
       FIG. 2  depicts a monitoring process  200  according to an embodiment of the invention. This example process  200  may be performed by the computer systems  140  of  FIG. 1 . Network traffic  120  may be monitored  210 . Monitoring  210  may include, but is not limited to, monitoring the traffic&#39;s  120  transport protocol  211 , application protocol  212 , destination and/or source  213 , and/or content  214 . Monitoring  210  may include storing data for further analysis. The monitored data may be assessed  220 . Assessment  220  may be based on, but is not limited to, the destination and/or source  221  and content  222  of the monitored traffic. Based on the assessment  220 , suspicious traffic may be identified  230 . A determination of suspicion may be based on, for example, a low reputation score with respect to the destination of the network traffic; activity and files related to suspicious domain generation algorithm (DGA) clusters; and/or suspicious content such as files, headers, HTTP traffic, scripts, etc. 
     Many different techniques may be used to help determine traffic suspicion. For example, suspicion may be based on a low traffic destination reputation score. One or more databases may contain known malicious or legitimate domain reputations for the destination domain of a communication attempt. Also, reputations may be determined for unknown domains, for example by receiving passive DNS query information, utilizing the DNS query information to measure statistical features of known malicious and legitimate domain names, and utilizing the statistical features to determine a reputation of a new domain (for example, likely malicious or likely legitimate). For more information on systems and methods for determining suspicion based on a low reputation score, see U.S. Patent Application Publication 2012/0042381, “Method and System for Determining Whether Domain Names Are Legitimate or Malicious,” the entirety of which is incorporated by reference herein. 
     Suspicion may also be based on communications with unregistered domains and/or domains generated by domain generation algorithms. For example, NX domains (NXs) may be domains not registered with authoritative domain name servers. Malware may use NXs to facilitate communication between network assets and external criminal networks. Detecting suspicious activity surrounding NXs may be done by collecting NX domain names from an asset, using these NX domain names to create testing vectors, classifying the testing vectors as benign vectors or malicious vectors based on training vectors, and classifying the asset as infected if the NX testing vector created from the collected NX is classified as a malicious vector. Other NX testing methods may be possible. NX domains may be generated by DGA clusters. Malware on an asset may use DGA to contact external criminal networks. In one example, detecting infections by malware using DGA may be done by clustering randomly generated NX domains that may have been generated by a DGA based on common characteristics, determining which clustered randomly generated domains are correlated in network usage and time, and using this data to determine the DGA that generated the clustered randomly generated domain names. For more information on systems and methods for determining suspicion based on activities and files related to suspicious DGA clusters, see U.S. Patent Application Publication 2011/0167495, “Method and System for Detecting Malware” the entirety of which is incorporated by reference herein. 
     Both well-known techniques such as both static and dynamic file analysis, header anomalies, and script analysis as well as novel or unknown techniques may be employed as methods and procedures for determining suspicion based on content. For examples of other malware detection techniques which may be applicable to the systems and methods described herein, see U.S. Patent Application Publication 2012/0143650, “Method and System of Assessing and Managing Risk. Associated with Compromised Network Assets,” the entirety of which is incorporated by reference herein. Those of ordinary skill in the art will appreciate that other tests and criteria for suspicious activity may be possible. 
     If the activity is not regarded as suspicious, it may be disregarded  250 . If the activity is regarded as suspicious, then metadata associated with the activity may be captured and indexed  240 . This may be done using well known techniques in some embodiments. Examples of metadata that may be associated with the activity may include, but are not limited to: 
     Destination Inspection 
     
         
         
           
             Port (Source/Destination) 
             Transport Protocol (TCP/UDP) 
             Application Protocol (DNS, HTTP, FTP, SMTP, SMB, IRC, etc.) 
             Time stamp and/or duration 
             Source IP, MAC, hostname 
             Destination IP/Domain 
             Bytes in/Bytes out 
             Success/Status of the connection 
             DNS RR Set 
             For HTTP requests 
             Host, Referrer, URI, Verb, User Agent, etc. 
             For HTTP response 
             Server, Cache, Content Encoding, Content Type, etc.
 
For Content
 
             File or Content Itself 
             Subsequent Communications over period of time 
           
         
       
    
     Data that is captured and indexed may provide forensic information surrounding infections on assets  110  within the network  100  and may serve as the base activity for other methods and systems presented below. 
     Simulated Traffic Comparison 
     Once suspicious activity is identified, historical, present and/or future network events may be compared to simulated data in order to discover the effects and implications of malicious activity: Simulated traffic comparison may be performed to prove that malware actually ran on an asset  110  in question and/or to explain the lifecycle of the infection. Proving that the malware ran may involve matching actual network data related to the asset  110 , collected utilizing the methods described above with respect to  FIG. 2  for example, against destination data contained in simulated data generated by a malware analysis engine. For example, if specific destination data traits (for example, destinations, paths, patterns, and behaviors) are observed in both simulated data and actual data from assets  110 , then those traits may become strong indicators of compromise, as the similarity of the temporal occurrence and the uniqueness of the traits may be statistically relevant. Having proof of malware running on an internal asset  110  may allow a system to reduce a false positive rate, may remove conviction uncertainty on die part of a network user or administrator, and may help a network user or administrator to understand the severity of the infection inclusive of but not limited to the systems and methods described in U.S. 2012/0143650. Other examples may include correlation with other customer security product events such as proxy block pages, resulting connections to sinkholed destinations, determination that the infection has disabled host based protection via registry key changes, etc. Explaining the infection lifecycle may include matching the buffered data against data associated with research intelligence systems that may perform reputation, content, and behavioral analysis to determine a type of criminal destination (infector, updater, data drop, etc.) inclusive of but not limited to the systems and methods described in U.S. 2012/0042381, as well as other proprietary systems that identify C&amp;C destinations, DGA activity, or clusters of malware, for example. Based on this analysis, an annotation of criminal destination type in the user interface may allow for accurate severity scoring inclusive of but not limited to the systems and methods described in U.S. 2012/0143650. Other examples may include correlation with other customer security product events such as proxy block pages, resulting connections to sinkholed destinations, determination that the infection has disabled host based protection via registry key changes, etc. Such annotation may help a user to understand the severity of the infection, may allow the system to identify how much data has been exfiltrated, may allow understanding of malware update frequency, may allow the use of host-based software, which may include well-known third party software, to retrieve malware updates that were encrypted payloads over the network, and may allow a determination of the infection profile (low and slow, password stealer, spammer, infecting other internal assets, etc). 
       FIGS. 3A-3B  depict an analysis system  320  according to an embodiment of the invention. This example system  320  is presented in the context of an example flow of an infection lifecycle with an infection vector wherein malware  310  from an external network  300  may enter an internal network  330  and may be delivered to an endpoint asset  331 . If the malware  310  successfully infects the endpoint  331 , then the malware  310  may install  332  and communicate  333  to a cyber-criminal infrastructure  350  to get updated  351 . After an update  351 , the malware  310  may download a new malware sample with a downloader  354  and may be updated/customized to new malware  334 . The new malware  334  may the communicate  335  to the cyber-criminal infrastructure  350 . The communication  335  may include criminal communication such as delivering stolen data to a repository  352 , receiving new instructions via command and control (C&amp;C) portals  353 , and/or other communication types  355 . 
     During an initial transit of malware  310  from an external network  300  to the internal network  330 , the system  320  may watch the malware  310  in motion and may make a copy of the malware  315  for analysis. The copy of the malware  315  may be delivered to a dynamic analysis sub-system  340 , which may perform both static and dynamic analysis on the malware  315 . The malware  315  may be loaded into the simulated endpoint  341 , where the malware  315  may follow a similar infection lifecycle as did malware  310  on endpoint  331 . In this example, malware may install  342 , communicate  343  to the cyber criminal infrastructure  350 , and/or be updated and customized  344 . New malware may communicate  345  to the cyber criminal infrastructure  350 . 
     The system  320  may include an asset, monitoring subsystem  140  (described with reference to  FIG. 2  above), which may capture and index the selective network communications metadata of the potentially infected asset  331 . The system  320  may also include a simulation monitoring subsystem  370 , which may capture and index the simulated network communication activity from sub-system  340 . The simulation monitoring subsystem  370  may be similar to the asset monitoring subsystem  140 , but may monitor, assess, and store the simulated data instead of network traffic  120  data. 
     As seen in  FIG. 3B , a comparison subsystem  321  may compare the captured and indexed activity of the asset monitoring subsystem  140  to the captured and indexed activity of the simulation monitoring subsystem  370 . If the comparing reveals that the activity of the asset monitoring subsystem  140  and the simulation monitoring subsystem  370  is statistically similar  322 , then there may be increased confidence in the infection being present on asset  331 . If the comparing reveals that the activity of the asset monitoring subsystem  140  and the simulation monitoring subsystem  370  is not statistically similar  323 , then it may be unlikely that an infection occurred. 
     If the activities are not statistically similar  323 , then this may validate that an infection likely did not occur on the asset  331  and thus a lower confidence score  381  may be presented within a user interface that may be part of or in communication with, the system  320 . This information may help reduce false positives. Furthermore, since it may be likely the malware  310  did not install on the asset  331 , then there may be decreased risk  382 , see for example U.S. 2012/0143650, posed to an organization and network  330  associated with the asset  331 , and information indicating this low risk level may be presented within the user interface. 
     If the activities are statistically similar  322 , then this may validate that an infection occurred and thus an increased confidence score  381  may be presented within the user interface. Furthermore, the confidence in the presence of the infection may increase the risk  382 , see for example U.S. 2012/0143650, that the infection poses to the organization and network  330  associated with the asset  331 , and information indicating this high risk level may be presented within the user interface. When the activities are statistically similar  322 , the system  320  may take the simulated activity  370  and analyze  390 , see for example U.S. 2012/0042381, and label  395  the monitored communications as updater, repository, downloader, C&amp;C, etc., thereby generating information which may be used to identify how much data has been exfiltrated from the asset  331  and to where, to allow understanding of malware update frequency, a allow the use of host-based software to retrieve malware updates that were encrypted payloads over the network, and to allow a determination of the infection profile (low and slow, password stealer, information stealer spammer, infecting other internal assets, etc). The labeling may provide context to the purpose of each labeled communications, for example assessing the quantity of data delivered through communications labeled “repository” may indicate how much data theft is occurring and may indicate the threat type as an information stealer. 
     Reexamination of Indexed Historic, Present, and/or Future Data 
     Systems and methods may also be provided which may perform reexamination of indexed historic, present, and/or future data to discover precursors to malicious activity as well as present and future activity. This may provide a determination of an origin of the activity that led to the infection. For example, malware may have infected an asset  331  from an ad placed on CNN, a browser exploit, etc. Reexamination may be done by capturing referrer headers, URLs, timestamps, and other attributes. Reexamination may help a user to understand the infector lifecycle, to craft future security software rulesets, to inform acceptable use policies, and/or to reduce the uncertainty of an identified infection. 
     Discovery and/or recovery of historical infector malware based on future network communications or on future available intelligence based indicators may enable retroactive discovery of stealthy infector malware that may have caused an initial infection on an asset machine. As noted above, suspicious metadata may be stored. The system may also store binaries downloaded in the network for a period of time, and once malicious network traffic is discovered, binaries downloaded by an asset  110  that is suspected to be infected may be meticulously examined to determine the infector malware. This determination may then be provided to a user. Trace data for the infector malware may also be provided to the user. This may allow the discovery of stealthy malware and may provide a technique for thwarting malware detection evasion techniques. 
       FIG. 4  depicts an analysis process  400  according to an embodiment of the invention. This process  400  may involve the collection and/or analysis of data related to malicious activity of an infection on an asset  110  within a network  100 . The timeline  405  in this example shows the time when malicious activity is identified or new threat intelligence based indicators are available  406 , the time prior to identification  407 , and the time period post identification  408 . 
     During the time prior to identification  407 , the discovery/recovery system  410  may utilize the monitoring system  140  described above, which may selectively capture and/or index metadata associated with the activity of endpoints  110  in the network  100 . Specifically, historical network communication data may be gathered  421  and analyzed  430 . Similarly, historical network file downloads and other suspicious content may be gathered  422  and analyzed  440 . Newly identified malicious activity and selective metadata may also be gathered  423 . 
     The analysis of historical network communication data  430  may include analysis and/or re-analysis of each component of historical network communication data to determine new intelligence. As discussed above, network data may be identified as suspicious and may be stored. In many cases, the data may not be immediately analyzed and/or may not be suspicious enough at the time of detection to warrant reporting to a user. However, if an infection is identified, this suspicious data may become more interesting. Analysis and/or reanalysis may be performed to provide deep analysis on data which may have been ignored before identification of infection due to scalability concerns associated with analyzing all collected data. In some cases, brief analysis may be performed upon collection of suspicious data, and more thorough analysis may be triggered by infection identification or by new threat intelligence indicators being available. In other cases, all data (instead of only suspicious data) may be captured by a monitoring system, and analysis of stored data may be triggered by infection identification. 
     For example a communication attempt may be deemed suspicious enough to capture and index but not suspicious enough at the time of determination to bring to the customer&#39;s attention. In this example, there may be 100 indexed but not reported events for an endpoint. At a later date, which may be after detection of an infection in the endpoint, advanced techniques may be applied to examine these 100 events. Examples of analysis and/or reanalysis that may be performed include:
         Destination Reputation, for example identifying known malicious or legitimate domain reputations for the destination domain of a communication attempt. See for example U.S. 2012/0042381.   New Destination Classification and Labels, for example receiving passive DNS query information, utilizing the DNS query information to measure statistical features of known malicious and legitimate domain names, and utilizing the statistical features to determine a reputation of a new domain (for example, likely malicious or likely legitimate). See for example U.S. 2012/0042381.   Analysis of headers, for example examining traffic for malformed headers that may have not been considered serious enough to generate an alert.   Analysis of referrers, for example to provide contextual information related to the source of potential malicious communications.   Other, for example the identification of new behavioral patterns or properties based on observed historical activities.   Analyze any newly analyzed files for simulated traffic matches, described in greater detail below with respect to automation discovery.       

     A user interface  450  may be part of or in communication with the discovery/recovery system  410 . The results of the historical network communication data analysis  430  may be presented  451  in the user interface  450 . Historical network communication data and highlights on any historical data deemed interesting from retroactive analysis may be presented  451 . 
     The analysis of historical network file downloads and other suspicious content  440  may include retroactive analysis of each historical file and content via static and dynamic analysis. This may be done even for data that may have been analyzed in the past:
         Analyze Source Reputation, for example identifying known malicious or legitimate domain reputations for the domain from which one or more files were downloaded. See for example U.S. 2012/0042381.   Analyze Source Classification &amp; Labels, for example receiving passive DNS query information, utilizing the DNS query information to measure statistical features of known malicious and legitimate domain names, and utilizing the statistical features to determine a reputation of the domain from which one or more files were downloaded (for example, likely malicious or likely legitimate). See for example U.S. 2012/0042381.   Analyze against third party commodity AV detection engines. Identify static structure, for example by searching for well-known malware, identifying trademarks, or finding that a large part of an executable is encrypted.   Identify behavioral traits of file, for example identifying an executable which may start sending email without user interaction or a PDF file which may initiate network communication.   Identify current verdict of file and generate simulated trace report, for example by allowing the file to execute and examining changes to the underlying system. These changes may be analyzed to generate a verdict representing the file&#39;s behavior.       

     The results of the historical network file downloads and other suspicious content analysis  440  may be presented  452  in the user interface  450 . Historical file data within the time period before identification time period  406  and highlights on any historical data deemed interesting from retroactive analysis may be presented  452 . 
     An example of historical, present, and/or future analysis may proceed as follows. Infection may occur at 8:00 AM with a dropper that infects an endpoint. The dropper may communicate with a criminal infrastructure and receive a new malware update at 8:30 AM. The update may be a new piece of malware that is sent down in an encrypted payload. That new malware may begin to communicate at 8:35 AM. The system may identify these true malicious communications at 8:35 AM. If all suspicious files downloaded to this endpoint (including the one that caused the infection at 8:00 AM), captured metadata associated with the files, and network communications (which may include communications by the dropper) have been stored, this suspicious data may now be analyzed. The system may retroactively examine the files downloaded prior to the 8:35 AM identification (which may include the dropper at 8:00 AM) and reexamine the suspicious network traffic (which may include the dropper&#39;s communications up to the criminal operator). Going forward, other suspicious communications that the infected endpoint makes that may not necessarily be suspicious enough to attribute directly to the infection may now be examined closely. In this example, the identification of a threat at 8:35 AM caused the system to retroactively examine suspicious network traffic and files that may have led to the infection. 
     When any malicious activity is identified  406 , any malicious activity and/or selective metadata newly identified during the present  406  and/or future time period  406  may be captured  423  and presented  453  in the user interface  450 . As noted above, this may provide a determination of an origin of the activity that led to the infection and/or help a user to understand the infector lifecycle, to craft future security software rulesets, to inform acceptable use policies, and/or to reduce the uncertainty of an identified infection. 
     Automation Discovery 
     Systems and methods may also be provided for determining a degree of automation within suspicious network activity. This may be used to show that malware convictions that were arrived at via other detection techniques exhibit automated behavior (behavior that is machine based instead of user based). This may reduce the uncertainty of convictions. 
       FIG. 5  depicts a real time analysis process  500  according to an embodiment of the invention. Observed network traffic with either known or low reputation destinations may be collected  510 . Analysis of the collected data may be performed  520  which may result in statistical scoring to indicate how automated the observed communications are used on their temporal patterns and attributes. In some embodiments, the analysis may determine the degree of automation via constantly evolving algorithms, an example of which can be described by examining the temporal deltas (time between each) of a series of malware communications and performing statistical analysis to determine that each delta is similar to all of the other deltas. In such an example, the more statistically similar each delta is to the group, the higher the automation score may be. Those of ordinary skill in the art will appreciate that other analysis and/or scoring techniques may be used to identify and/or classify potential automation. The statistical scoring of automation may be based on algorithms  530  built by observing known malware. If statistical scoring indicates a high degree of automation, then the system may indicate a high level of confidence of an infection  540  and thus a high risk factor  550  of the infection and present this information  560  via a user interface. 
     The probability of maliciousness in network traffic patterns may also be determined. This may allow net new detections via the presence of automated traffic patterns. Data may be gathered as described above with respect to  FIG. 2 , and this data may be analyzed for the presence of automated behavior using algorithms and low reputation or other information indicative of a malware destination. This may allow the system to detect new threats without any foreknowledge of the threat, and may reduce conviction uncertainty. 
       FIG. 6  depicts an historical analysis process  600  according to an embodiment of the invention. As described above with respect to  FIG. 2 , suspicious network traffic may have been captured and indexed. This captured and indexed data may be retrieved  610  for analysis. Analysis of the indexed data may be performed  620 , resulting in statistical scoring to indicate how automated the observed communications are. This analysis may use similar techniques to those described above for existing malware detection. The statistical scoring of automation may be based on algorithms  630  built by observing known malware. If statistical scoring indicates a high degree of automation, then the system may indicate a high level of confidence of an infection  640  and thus a high risk factor  650  of the infection and present this information  660  via a user interface. 
     While various embodiments have been described above, it should be understood that they have been presented by way of example and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope. In fact, after reading the above description, it will be apparent to one skilled in the relevant art(s) how to implement alternative embodiments. Thus, the present embodiments should not be limited by any of the above-described embodiments. 
     In addition, it should be understood that any figures which highlight the functionality and advantages are presented for example purposes only. The disclosed methodology and system are each sufficiently flexible and configurable such that they may be utilized in ways other than that shown. 
     Although the term “at least one” may often be used in the specification, claims and drawings, the terms “a”, “an”, “the”, “said”, etc. also signify “at least one” or “the at least one” in the specification, claims and drawings. 
     Finally, it is the applicant&#39;s intent that only claims that include the express language “means for” or “step for” be interpreted under 35 U.S.C. 112, paragraph 6. Claims that do not expressly include the phrase “means for” or “step for” are not to be interpreted under 35 U.S.C. 112, paragraph 6.