Exploit detection of malware and malware families

According to one embodiment, a computerized method comprises, accessing information associated with one or more observed events, wherein one or more of the observed events constitutes an anomalous behavior; accessing a reference model based on a first plurality of events, the reference model comprises a first event of the first plurality of events, a second event of the first plurality of events and a relationship that identifies that the second event of the first plurality of events is based on the first event of the first plurality of events, wherein at least one of the first event and the second event constitutes an anomalous behavior; and comparing the information associated with the one or more observed events with the reference model to determine whether at least one observed event of the one or more observed events matches at least one of the first event of the first plurality of events or the second event of the first plurality of events that constitutes the anomalous behavior is provided.

FIELD

Embodiments of the disclosure relate to the field of cyber security. More specifically, embodiments of the disclosure relate to a system for detecting malware and/or exploits through the comparison of incoming data with reference models describing known instances of malicious behavior.

GENERAL BACKGROUND

Over the last decade, malicious software has become a pervasive problem for Internet users as many networked resources include vulnerabilities that are subject to attack. For instance, over the past few years, more and more vulnerabilities are being discovered in software that is loaded onto endpoint devices present on the network, such as vulnerabilities within operating systems for example. These vulnerabilities may be exploited by a person allowing the person to gain access to one or more areas within the network not typically accessible. For example, a person may exploit a vulnerability to gain unauthorized access to email accounts and/or data files.

While some vulnerabilities continue to be addressed through software patches, prior to the release of such software patches, network devices will continue to be targeted for attack by exploits, namely malicious computer code that attempts to acquire sensitive information or adversely influence or attack normal operations of the network device or the entire enterprise network by taking advantage of a vulnerability in computer software.

Currently, a threat detection system observes suspicious or malicious exploits and presents the information regarding the exploits in a list format. While the list format may provide security personnel information directed to uncovered exploits or other detected malicious actions, it fails to identify any relationships between the exploits that would allow security personnel to better understand potential effects, both detected and undetected, caused by the malicious exploit.

In addition, current systems fail to generate reference models based on observed exploits, malicious behaviors, anomalous behaviors (e.g., deviating from typical or expected behavior) or the like for comparison against events observed at a later time.

DETAILED DESCRIPTION

Various embodiments of the disclosure relate to a malware detection and visualization system that improves exploit detection and/or visual representation of the detection of suspected malware. The malware detection and visualization system includes a machine learning engine that generates reference models used in exploit detection as well as interactive display screen information based on data transmitted to the malware detection and visualization system from one or more endpoint devices, one or more threat detection systems and/or cloud computing services. The generated reference models may be combined to generate malware family reference models allowing the malware detection and visualization system to compare observed events on the network to particularized malware threats in the form of malware affecting a specific file type or malware detected in a common location (e.g., email). Alternatively, a comparison with several reference models or with a large malware family reference model may provide detection against a large range of malware threats. The malware detection and visualization system may take the form of a security appliance or security cloud service, for example. Alternatively, an electronic device may be configured with software, hardware or firmware that includes a malware detection and visualization system. The malware detection and visualization system may be implemented in real-time (e.g., as incoming data is being processed) or as a forensic investigative tool (e.g., after the incoming data has been processed to determine the root cause of a malware exploited has been executed).

The malware detection and visualization system also includes a user interface rendering subsystem that generates interactive display screens from the interactive display screen information and allows security personnel to select displayed malicious events in order to acquire additional information concerning such events as well as generate an alert or a (malware) signature that may be used for subsequent detection of malware associated with these malicious events. The interactive display screens provide a network administrator with a visual representation that compares a reference model of events (e.g., known exploits) and the relationships connecting the events with a group of potentially malicious events and their relationships to one another. The group of potentially malicious events may be derived from observations of endpoint devices, threat detection systems and/or cloud computing services connected to the malware detection and visualization system over a network.

Specifically, in one embodiment, the visual representation allows a viewer to convert a list of events into a nodal diagram in either a top-down representation or a left-to-right representation. The nodal diagrams may enable a view, such as network security personnel, to see how each event relates to one another, if at all. Furthermore, the nodal diagrams provide the visual representation necessary for a viewer to select one or more events, referred to herein as a “grouping” of events, to generate a signature or alert. The signature of a grouping of events may be used as a reference model to check for a particular sequence of events in data received in the future or added to an existing reference model. The alert may be used to notify the network administrator of the observation of a grouping of events that typically implies malicious activity on the network thereby allowing prevention actions to be taken to guard against the malicious activity.

Embodiments of the invention may be employed by or take the form of a network device or apparatus implementing a malware detection and visualization system (MDVS), where the malware detection and visualization system includes a machine learning engine for analyzing data received by the MDVS. The data may include information regarding the observation of events by a server or client device or other system (called an “endpoint”), a threat detection systems (TDS) and/or a cloud computing service. In some embodiments, the observations of events may take place while an endpoint device is operating in real-time or the observations may take place while incoming data is being processed in one or more virtual machines. Examples of incoming data may include, but are not limited or restricted to, network traffic, static files containing structured or unstructured data maintained locally or on a peripheral device and/or executable files. According to one embodiment of the disclosure, an endpoint device, TDS or cloud computing service transmits data regarding an observation of one or more events and/or relationships when an anomalous characteristic of incoming data is observed and thus indicative of an exploit. If so, one or more portions of data may be labeled “suspicious.” Throughout the specification, claims and figures, the term “network traffic” will be used in the discussion but any form of incoming data may be substituted.

A TDS may perform static and/or dynamic analyses on incoming data (e.g., network traffic) to determine whether an object of the incoming data is suspicious or malicious. An illustrative example of the static and dynamic analyses is illustrated in the threat detection and prevention (TDP) system in a prior U.S. patent application entitled “System, Apparatus and Method for Automatically Verifying Exploits Within Suspect Objects and Highlighting the Display Information Associated with the Verified Exploits,” U.S. patent application Ser. No. 14/228,073 filed Mar. 27, 2014, the contents of which are incorporated by reference.

In particular, the machine learning engine may be activated automatically in response to an alert condition that signifies detection of a malicious event by an endpoint device, a TDS and/or a cloud computing service within the network. Alternatively, the machine learning engine may be activated in accordance with a time-based schedule or manually by a user such as security personnel. For instance, the machine learning engine may be activated manually upon selecting a particular visual representation associated with the observance of a malicious event, where one or more events may be concurrently presented on an interactive display screen, and then subsequently selecting a prescribed item on the display screen (e.g., “exploit visualization” button or “timeline visualization” button).

After activation, the machine learning engine may be adapted to obtain received data from a machine learning data store and/or event log, where the received data may include metadata associated with malicious events detected by one or more endpoint devices, TDSes and/or a cloud computing service. The machine learning engine generates a visual representation in the form of a nodal diagram illustrating a potential malware infection, where each node or relationship included in the nodal diagram represents an action, operation, file, process, etc. associated with an anomalous event or relationship. This provides a network administrator with one or more displays directed to the sequence of events to identify which network device(s) and or file(s) within the network may have been infected by the anomalous event. For example, the anomalous event may be an atypical, but non-malicious, operation or relationship; alternatively, the anomalous event may be realized as a malicious event or relationship.

In the nodal diagrams, each event may be selected to display additional information, including, any or all of the following metadata directed to the observance of the selected event: (1) time and date of observance; (2) address information such as the path within the file system in which the affected file is located; (3) process identification of the affected process (if applicable); (4) the particulars of the particular electronic device or cloud computing service that detected the event; and/or (5) the relationship to one or more events associated with the selected event.

In the following description, certain terminology is used to describe features of the invention. For example, in certain situations, both terms “logic” and “engine” are representative of hardware, firmware and/or software that is configured to perform one or more functions. As hardware, logic (or engine) may include circuitry having data processing or storage functionality. Examples of such circuitry may include, but are not limited or restricted to a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, a controller, an application specific integrated circuit, wireless receiver, transmitter and/or transceiver circuitry, semiconductor memory, or combinatorial logic.

Logic (or engine) may be software in the form of one or more software modules, such as executable code in the form of an executable application, an application programming interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, source code, object code, a shared library/dynamic load library, or one or more instructions. These software modules may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of non-transitory storage medium may include, but are not limited or restricted to a programmable circuit; a semiconductor memory; non-persistent storage such as volatile memory (e.g., any type of random access memory “RAM”); persistent storage such as non-volatile memory (e.g., read-only memory “ROM”, power-backed RAM, flash memory, phase-change memory, etc.), a solid-state drive, hard disk drive, an optical disc drive, or a portable memory device. As firmware, the executable code is stored in persistent storage.

An “exploit” may be construed broadly as information (e.g., executable code, data, command(s), etc.) that attempts to take advantage of a vulnerability and/or an action by a person gaining unauthorized access to one or more areas of a network, a computer and/or an electronic device. Typically, a “vulnerability” is a coding error or artifact of software (e.g., computer program) that allows an attacker to alter legitimate control flow during processing of the software (computer program) by a network device, and thus, causes the network device to experience undesirable or anomalous behaviors. The undesired or anomalous behaviors may include a communication-based anomaly or an execution-based anomaly, which, for example, could (1) alter the functionality of an network device executing application software in an atypical manner (a file is opened by a first process where the file is configured to be opened by a second process and not the first process); (2) alter the functionality of the network device executing that application software without any malicious intent; and/or (3) provide unwanted functionality which may be generally acceptable in another context. To illustrate, a computer program may be considered as a state machine, where all valid states (and transitions between states) are managed and defined by the program, in which case an exploit may be viewed as seeking to alter one or more of the states (or transitions) from those defined by the program. The term “anomalous behavior” should be understood to include either (i) a first event that is an atypical occurrence or a malicious occurrence, or (ii) a relationship identifying that the first event is based on a second event, the relationship being an atypical relationship between the first and second event or a relationship between the first and second events that is malicious to the network, electronic device on which the relationship appears, or to one or more users of the electronic device or of the network.

According to one embodiment, malware may be construed broadly as computer code that executes an exploit to take advantage of a vulnerability, for example, to harm or co-opt operation of a network device or misappropriate, modify or delete data. Conventionally, malware is often said to be designed with malicious intent.

The term “transmission medium” is a physical or logical communication path between two or more network devices (e.g., any devices with data processing and network connectivity such as, for example, a security appliance, a server, a mainframe, a computer such as a desktop or laptop, netbook, tablet, firewall, smart phone, router, switch, bridge, etc.). For instance, the communication path may include wired and/or wireless segments. Examples of wired and/or wireless segments include electrical wiring, optical fiber, cable, bus trace, or a wireless channel using infrared, radio frequency (RF), or any other wired/wireless signaling mechanism.

The term “network device” should be construed as any electronic device with the capability of connecting to a network. Such a network may be a public network such as the Internet or a private network such as a wireless data telecommunication network, wide area network, a type of local area network (LAN), or a combination of networks. Examples of a network device may include, but are not limited or restricted to, a laptop, a mobile phone, a tablet, a computer, etc.

The term “computerized” generally represents that any corresponding operations are conducted by hardware in combination with software and/or firmware. Also, the terms “compare” or “comparison” generally mean determining if a match (e.g., a certain level of correlation) is achieved between two items where one of the items may include a particular signature pattern.

The term “signature” designates an indicator of a set of characteristics and/or behaviors exhibited by one or more exploits that may not be unique to those exploit(s). Thus, a match of the signature may indicate to some level of probability, often well less than 100%, that a portion of received data constitutes an exploit. In some contexts, those of skill in the art have used the term “signature” as a unique identifier or “fingerprint,” for example of a specific virus or virus family (or other exploit), which is generated for instance as a hash of its machine code, and that is a special sub-case for purposes of this disclosure.

The term “observed” indicates that an event or relationship has been detected with a prescribed level of confidence (or probability). A first event or relationship may be observed with a first confidence while a second event or relationship may be observed with a second confidence, the second confidence being lower or higher than the first confidence. Examples of an event may include, but are not limited or restricted to, a process (e.g., an executable file), a non-executable file (e.g., a text document or a registry file), a unique address or location (e.g., a particular website, Internet Protocol (IP) address, or file location).

The term “reference model” should be interpreted as an association of a plurality of events wherein each event is connected to another event and the association includes at least one anomalous behavior (e.g., anomalous event or relationship). For example, a reference model may include a process that (1) injects code into a file unexpectedly and (2) opens multiple files wherein the opening of the files constitutes anomalous behavior. Throughout the specification and claims, the terms “reference model” and “signature” will be used interchangeably.

The term “relationship” means the connection or association of a first event with a second event. Examples of a relationship may include, but are not limited or restricted to, an event: starting a process, terminating a process, modifying a file, generating a file, opening a file, closing a file, deleting a file, infecting a file and/or process, injecting code into file and/or process and/or generating a mutual exclusion (mutex) on a particular file, process, application, etc.

The term “particular” should be interpreted as a characteristic of an event. Examples of particulars include, but are not limited or restricted to, a process identification (PID), a process name, a file name, a process or file path (i.e., unique location on an electronic device), the date and/or time the event was observed and/or occurred, an application programming interface (API) call involved and/or a hash value of the one or more processes or files involved.

The invention may be utilized for displaying an interactive infection visualization detailing detection, verification and/or prioritization of malicious content. As this invention is susceptible to embodiments of many different forms, it is intended that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

II. Malware Detection and Visualization System

Referring toFIG. 1, a flowchart illustrating an exemplary method for generating a reference model and the applications that may be performed by a network device such as, for example, a malware detection and visualization system (MDVS), using the generated reference model is shown. In block110, the MDVS receives data describing observed events from one or more sources connected to a network. The sources may include one or more endpoint devices, one or more threat detection systems (TDSes) and/or cloud computing services. The received data may provide one or more particulars of the observed events and/or describe relationships between the observed events.

At block120, the MDVS generates a reference model based on, at least, the received data. The MDVS may use the generated reference to: (i) perform an exploit detection process by comparing data received from one or more sources at a later time to the generated reference model and provide exploit detection feedback to block120, if applicable (block130); (ii) generate a malware family reference model from a plurality of generated reference models or reference models received over the network (block140); and/or (iii) generate one or more interactive display screens to aid in the detection and tracing of exploits and/or one or more anomalous behaviors and provide interactive display screen input to block120, if applicable (block150).

Referring toFIG. 2, a block diagram of an exemplary MDVS200coupled to a network240is shown. The network240provides communication connectivity between the MDVS200and one or more sources, wherein the sources may include one or more endpoint devices2501-250N(where N=2 for this embodiment), one or more threat detection systems (TDSes)2601-260M(where M=3 for this embodiment) and/or the cloud computing services241. The sources are communicatively coupled to a management system242, which is adapted to manage the one or more sources as well as the MDVS200. For instance, the management system242may be configured to perform content updates (e.g., upload new rules or modified rules, delete rules, modify parameters that are utilized by the rules, upload metadata stored within other TDSes, or certain metadata associated with the one or more endpoint devices2501and/or2502) within the one or more endpoint devices1501and1502and/or within the one or more TDSes2601-2603.

As shown inFIG. 2, the MDVS200is an electronic device that is adapted to analyze information associated with a plurality of events observed at one or more sources (the endpoint devices2501and2502, the TDSes2601-2603and/or the cloud computing services241). The MDVS200receives data of the observed events and the particulars of the events over the network240. The network240may include a public network such as the Internet, a private network such as a wireless data telecommunication network, wide area network, a type of local area network (LAN), or a combination of networks.

In general, the endpoint devices2501and2502may observe one or more events during operation of the device and transmit a log of the events along with particulars of the events to the MDVS200. In addition, the TDSes2601-2603may observe one or more events while processing, for instance in one or more virtual machines, one or more portions of data received over the network240. The TDSes2601-2603may then transmit a log containing the events and their particulars to the MDVS200. The management system242controls the transmission of the event logs by the endpoint devices2501and2502and/or the TDSes2601-2603. For example, the management system242may transmit notifications to the endpoint devices2501and2502and/or the TDSes2601-2603instructing the sources that the event logs should be transmitted to the MDVS200.

As illustrated inFIG. 2, the MDVS200includes a machine learning engine210, a user interface (UI) rendering subsystem220and an event log engine230. Herein, the machine learning engine210may include a machine learning logic211, a machine learning data store214, a gathering logic212, a matching logic213, and a reference model generation logic215. The UI rendering subsystem220may include a display generation logic221and a UI logic222. The event log engine may include an event log control logic231and an event log232.

In one embodiment, the event log control logic231is responsible for receiving data associated with a malicious event that may be detected at and transmitted by the one or more sources over the network240. Upon receiving the data, the event log control logic231may categorize the event and any associated events included in the data, for example, according to the type of event (e.g., executable file, text file, registry file, etc.). The data associated with a malicious event includes the particulars of the malicious event and the particulars of any observed events associated with the malicious event. The event log control logic231further adds the particulars of each observed event to the event log232. Therefore, the MDVS200is able to easily access the event particulars in a sorted manner when generating an interactive display screen.

In a second embodiment wherein the MDVS200is deployed within an endpoint device2501, the event log control logic231is also responsible for observing the events at the endpoint device on which the MDVS200is deployed and for adding data associated with an observed malicious event to the event log232as well.

The machine learning logic211is responsible for analyzing the data associated with the observed events. The gathering logic212of the machine learning logic211may query the event log232to obtain the one or more portions of the data. The matching logic213of the machine learning logic211may analyze the one or more portions of the data to generate associations of one or more events based on the particulars of the events. For instance, the machine learning logic211may realize a first process (e.g., a parent process) launched several secondary processes (e.g., child processes) and that the child processes subsequently modified one or more files. In addition, the machine learning logic211may perform a comparison between the above-referenced realization and one or more reference models formed by events and relationships where one of these events or relationships may be characterized as a known anomalous behavior. Furthermore, the reference model generation logic215of the machine learning logic211may generate reference models of malware families from the data stored in the event log232and data stored in the machine learning data store214(the generation of reference models of malware families will be described in detail below). The machine learning logic211also generates the interactive display screen information based on the data in the machine learning data store214and the event log232. In one embodiment, the generated reference models of malware families and the interactive display screen information may be expressed in eXtensible Markup Language (XML) and stored in the machine learning data store214(as will be discussed below withFIGS. 4 and 5).

The machine learning data store214stores the reference models generated by the machine learning logic211or received over the network240if applicable. For example, an MDVS may be deployed within an endpoint device2501and/or2502, within one or more TDSes2601-2603, or within the cloud computing services241. In that such an embodiment, the MDVS200may receive one or more reference models generated by the MDVS deployed within the endpoint device2501. The machine learning data store214also stores interactive display screens generated by the machine learning logic211. In the embodiment wherein an MDVS is deployed within the endpoint device2501, the data received over the network may include previously generated reference models and/or interactive display screen information. The MDVS200may adopt such data without modification or analyze such data to generate its own reference models and/or interactive display screen data in combination with previously received data.

The display generation logic221is responsible for displaying the interactive display screens generated from the interactive display screen information generated by the machine learning logic211. When a request to display an interactive display screen is received by the MDVS200, the user interface logic222notifies the machine learning logic211. The machine learning logic211then queries the machine learning data store214and the event log232for the appropriate data (e.g., data pertaining to the relevant event(s)) and generates the interactive display screen information. The machine learning logic211may transmit the interactive display screen information to the display generation logic221or the display generation logic221may query the machine learning data store214to obtain the interactive display screen information. Upon obtaining the interactive display screen information, the display generation logic221generates the physical display screen that illustrates the association of one or more anomalous events and/or a comparison of one or more reference models of events that constitute known anomalous behaviors with an association of one or more observed events. In some embodiments, the display screen may contain the particulars of the events.

The UI logic222is responsible for receiving requests for the generation of an interactive display screen, requests to display particulars of an event and/or requests to generate signatures (e.g., reference models).

FIG. 2also illustrates optional reference model generators2431-2432attached to sources connected to the network240. The reference model generator2431may be connected to (or part of) the TDS2602. The reference model generator2431may generate one or more reference models based on network traffic analyzed by the TDS2602. The one or more reference models may be transmitted to the MDVS200through the network240and stored in either the event log232or the machine learning data store214. Similarly, the reference model generator2432may generate reference models based on data supplied to the management system from a network administrator and/or one or more sources, for example, the endpoint devices2501and/or2502, one or more TDSes2601-2603and/or the cloud computing services241. The generated reference models may be transmitted to the MDVS200through the network240and stored in either the event log232or the machine learning data store214.

Referring toFIG. 3, an exemplary embodiment of a logical representation of the MDVS ofFIG. 2is shown. The MDVS200includes one or more processors300that are coupled to communication interface logic301via a first transmission medium320. Communication interface301enables communications with endpoint devices2501and/or2502, one or more TDSes2601-2603, the cloud computing services241and/or the management system242ofFIG. 2. According to one embodiment, communication interface301may be implemented as a physical interface including one or more ports for wired connectors. Additionally, or in the alternative, communication interface logic301may be implemented with one or more radio units for supporting wireless communications with other electronic devices.

The processor(s)300is further coupled to the persistent storage310via transmission medium325. According to one embodiment of the disclosure, persistent storage310may include (a) the machine learning engine210, including the machine learning logic211and/or the machine learning data store214; (b) the UI rendering subsystem220that includes the display generation logic221and the UI logic222; and (c) the event log engine230including the event log control logic231and the event log232. Of course, when implemented as hardware, one or more of these logic units could be implemented separately from each other.

III. Reference Model Generation

Referring toFIG. 4, an exemplary portion of data received by the event log engine230expressed in XML is shown. As described above, the event log control logic231receives data transmitted by the one or more sources over the network240pertaining to one or more events and the particulars of the events.FIG. 4illustrates one embodiment of data of events and particulars of the events received by the event log control logic231. The data illustrated inFIG. 4is stored in the event log232until it is gathered by the gathering logic212(discussed below).

FIG. 4illustrates details of a first event observed at a time having a timestamp of “200.” For example, lines 3-12 state one or more attributes of the process information of a first event at a time having a timestamp value of “200” detailing: (1) the value of the event (“<value>”); (2) the process identification of the event (“<pid>”); (3) the parent process identification of the event (“<ppid>”); (4) the parent name of the event (“<parentname>”); (5) the file size of the event (“<filesize>”); (6) the hash value (e.g., a particular message digest (MD5) hash value) of the event (“<md5sum>”); (7) the securer hash algorithm (SHA) value of the event (“<shalsum>”); and (1) the file identification of the event (“<fid>”). Similarly, lines 13-20 and 21-26 recite event particulars of a second and third event at times having timestamp values of “300” and “350,” respectively.

Based on the data illustrated inFIG. 4, a reference model may be generated by the reference model generation logic215ofFIG. 2. The generation of a reference model may be triggered, for example, at predetermined time intervals, after receipt of a predetermined amount of data from the network240, and/or manually by a system administrator or the like. Upon the triggering of the generation of a reference model the gathering logic212gathers the data illustrated inFIG. 4and passes the data to the reference model generation logic215. Alternatively, the data illustrated inFIG. 4may be gathered by the gathering logic212and passed to the machine learning logic211which will generate an association of potentially malicious events for the matching logic213to use in an exploit detection process (discussed below).

Referring toFIG. 5, an exemplary portion of data generated by either the reference model generating logic215or the machine learning logic211expressed in XML is shown. As mentioned above, the gathering logic212gathers the data illustrated inFIG. 4and may pass the data to the reference model generating logic215. The reference model generating logic215generates a reference model for use in an exploit detection process. The generated reference model may be expressed in XML as illustrated inFIG. 5and subsequently stored in the machine learning data store214. Alternatively,FIG. 5may represent an association of potentially malicious events that will be used by the matching logic213in an exploit detection process, such as the exploit detection process performed by the matching logic213illustrated inFIGS. 6-7C.

The modifications to the data as illustrated inFIG. 4to obtain the data as illustrated inFIG. 5provide indicators of the beginning and end of event data (e.g., “<nodes>”) as well as the relationship (e.g., “<edge>”) between two events. The modifications may be performed by either the reference model generation logic215or the machine learning logic211.

IV. Applications of Reference Model(s)

A. Improved Exploit Detection

Referring now toFIG. 6, an exemplary illustration of a comparison of a reference model of an association of known malicious events with an association of potentially malicious observed events is shown. The machine learning logic211may perform an exploit detection process by performing the comparison illustrated inFIG. 6. The exploit detection process may be triggered, for example, at predetermined time intervals, after receipt of a predetermined amount of data from the network240, and/or manually by a system administrator or the like.

The determination of selecting which reference model(s) to use in a comparison such as that illustrated inFIG. 6is based on one or more factors. Examples of factors include, but are not limited or restricted to, the infection type of one or more events included in the received data (the association of potentially malicious observed events), the type of a file included in the received data and/or the most commonly matched reference models. Alternatively, the received data may be compared to all of the reference models.

Upon the triggering of the exploit detection process, the gathering logic212of the machine learning logic211initially gathers the data received over the network240and stored in the event log232. The gathering logic212also gathers the one or more reference models that will be used in the comparison. The matching logic213of the machine learning logic211compares the received data and the one or more reference models gathered by the gathering logic212.

InFIG. 6, the interactive display screen600illustrates a side-by-side comparison of two nodal diagrams; the left side being the reference model620and the right side being an association of observed potentially malicious events630(“the association630”). The reference model620represents an association of known or observed events and the relationships between the events. The observations or knowledge is such that the event and/or relationship was observed and/or known to have occurred with at least a certain probability. The reference model generation logic215ofFIG. 2may generate reference models such as reference model620from one or more of the data stored in the machine learning data store214, the data stored in the event log232and/or data received over the network240.

The events Event_1602, and Event_2603through Event_m604were observed as a result of the performance of an action or operation caused by the Process_A601. The events appearing in the reference model620are present as a result of one or more events or relationships being deemed at least anomalous, where one or more events or relationships may have been deemed malicious. In one embodiment, the Process_A601may have been deemed malicious by the TDS2601ofFIG. 2and such information transmitted to the MDVS200. In some embodiments, all behaviors caused by one malicious event may be considered malicious while in other embodiments, only a subset of the events caused by a malicious event may be deemed malicious.

Referring to the association630, the solid lines appearing in the association630signify that the events and/or relationships (i.e., the line connecting two events) were observed with at least a first confidence (e.g., observation that the event occurred or existed exceeds a first predetermined probability threshold). The dotted lines appearing in the association630signify that the events and/or relationships were observed with a second confidence, wherein the second confidence is different and less than the first confidence.

In the comparison performed by the matching logic213as illustrated inFIG. 6, some events and/or relationships may be equivalent in both the reference model620and the association630. As is illustrated, the events Event_1602and Event_2603appear in both the reference model620and the association630. In addition, the machine learning logic211may infer that one or more events and/or relationships were observed and should be included in the association630based on the reference model620. For example, the machine learning logic211may “learn” that when two events are observed, a third typically is as well and therefore infer that the third event was observed, adding it to association630. The concept of the machine learning logic211learning when events and/or relationship are likely to have be observed by recognizing trends and patterns based on the data stored in the machine learning data store214, stored in the event log232and/or received over the network240will be explained in detail along with the discussion ofFIGS. 7A-7Cbelow.

Referring toFIGS. 7A-7D, exemplary diagrams illustrating the exploit detection process performed by the matching logic213comparing an association of potentially malicious observed events with a reference model of known malicious events are shown. The changes seen betweenFIG. 7AtoFIG. 7Band fromFIG. 7BtoFIG. 7Cillustrate one embodiment of a process the machine learning logic211may perform to determine whether at least a portion of the association of potentially malicious observed events matches with one or more reference models. In one embodiment, the progression fromFIG. 7AtoFIG. 7BtoFIG. 7Cmay be considered the development of one interactive display screen. Alternatively,FIGS. 7A-7Cmay be considered separate interactive display screens providing a viewer three different perspectives of the potentially malicious events and/or relationships included within the association of potentially malicious events (the right side of the interactive display screen). The embodiment in whichFIGS. 7A-7Cmay be interactive display screens will be discussed below.

The following discussion ofFIGS. 7A-7Cwill explain an embodiment wherein the three figures illustrate the exploit detection process performed by the machine learning logic211. In addition, the discussion of the changes seen fromFIG. 7CtoFIG. 7Dwill explain the enhancement of a reference model based on the data transmitted to the MDVS200.

Referring toFIG. 7A, an initial stage of the exploit detection process is shown. The exploit detection process includes a comparison700that includes the reference model730and the association of potentially malicious events740(“the association740”). The reference model730includes the event 1.exe701that is seen to cause the performance of an action or operation in the events 1_M.exe702, “hidden files”703, “tampered files”704, “www.web1.com resolved to 199.16.199.2”705, “199.16.199.2”706, firefox.exe707and C:/Windows/explorer.exe708.

In addition, the reference model730details the relationships between the events. For example,FIG. 7Aprovides that the event 1.exe701caused the creation of a mutex to be performed that resulted in the observation of the event 1.exe_M702. Likewise, it is seen that the event 1.exe701exhibited malicious action that resulted in various hidden files703. Similarly, the relationships between the event 1.exe701and the other events included in the reference model730are illustrated in the comparison700.

The association740includes the event 1.exe701that is seen to cause the performance of an action or operation resulting in the events 1_M.exe721, “hidden files”722, “tampered files”723, “disabled taskmanager”724and C:/Windows/4.exe725. In contrast to the reference model730, not all of the relationships between the events included in the association740are illustrated inFIG. 7A. The association740shown inFIG. 7Amay not include enough data for the MDVS200to initially recognize all events and relationships with at least a first confidence, as mentioned above. As illustrated inFIG. 7A, the machine learning logic211may not initially have access to data allowing the machine learning logic211to determine relationships between the event720and the events722,723and725with at least the first confidence.

Therefore, as one embodiment,FIG. 7Aillustrates the first stage in the process of generating the association740that is shown inFIG. 7C. For example, the data used to generate the association ofFIG. 7Amay have been transmitted to the MDVS200from the TDS2601. The TDS2601may have, for example, processed a portion of network traffic it received in one or more virtual machines and observed, among others, the events and relationship included in the association740ofFIG. 7A. One or more of the events and/or relationships included in the association740ofFIG. 7Amay be been deemed malicious, prompting the TDS2601to transmit the observations to the MDVS200.

Referring toFIG. 7B, a second stage of the exploit detection process is shown. The association740illustrated inFIG. 7Bis seen to have two additional events included compared to the association740ofFIG. 7A. In particular, the two events, “www.web1.com resolves to 199.16.199.2”750and “199.16.199.2”751, are illustrated using dotted lines. In the embodiment ofFIGS. 7A-7C, dotted lines are intended to represent that the events and/or relationships were observed with a second confidence, meaning that the data available to the machine learning logic211did not provide as much support for the occurrence or existence of the events illustrated using dotted lines as the data did for the occurrence or existence of the events illustrated using solid lines.

Alternatively, the dotted lines may represent that the event was not detected at any one source but instead is an inference from the event's appearance in the reference model730. For example, the dotted box surrounding the “www.web1.com resolves to 199.16.199.2” event750may represent that no source connected to the MDVS200via the network240observed the “www.web1.com resolves to 199.16.199.2” event750. Instead, based on the similarities between the association740and the reference model730, the matching logic213inferred that the “www.web1.com resolves to 199.16.199.2” event750should be included and may have occurred but its observance did not occur.

In one embodiment, the data may have only provided one source of evidence of the occurrence of existence of the events illustrated using dotted lines whereas the first confidence requires Y or more sources of evidence are state that an event occurred or existed (wherein Y≧2). Alternatively, or in addition, the dotted lines may represent that the machine learning logic211has inferred that the events illustrated using dotted lines occurred or existed. Through machine learning, the machine learning logic211may have recognized that the events illustrated using dotted lines typically occur or exist when one or more of the events illustrated using solid lines were observed and therefore infer that it is likely the events illustrated dotted lines occurred or existed but were not observed with the first confidence. For example, the machine learning logic211may recognize that when an executable file (e.g., 4.exe720) generates a mutex which is followed by the hiding of files and tampering with network settings, it is likely that the website “www.web1.com” resolves to the IP address “199.16.199.2” and source (e.g., TDP2601) connected to the IP address “199.16.199.2” based on the reference model730.

Referring toFIG. 7C, the association740is fully illustrated such that the relationships between the event 4.exe720and the events 1_M.exe721, “hidden files”722, “tampered files”723, “disabled taskmanager”724, “www.web1.com resolved to 208.73.211.247”750, “208.73.211.247”751and C:/Windows/4.exe725are present in the comparison700. As was discussed regardingFIG. 7B, the machine learning logic211may infer one or more relationships based on at least a comparison700of the association740with the reference model730. Therefore, the comparison700as illustrated inFIG. 7Cprovides the matching logic213the association of the event 4.exe720with the events721-725,750and751allowing the matching logic213to make a determination as to whether the association740matches with the reference model730.

Based onFIGS. 7A-7C, the matching logic213may ascertain what malicious events occurred or existed, the relationships between the one or more events as well as the confidence of the machine learning logic211of the occurrence or existence of a particular event and/or relationship. The comparison700inFIGS. 7A-7Cperformed by the matching logic213to compare the association of observed and/or inferred events with a reference model allowing the matching logic213to determine the extent of malicious activity that may have occurred and what files, processes, locations, etc. may have been affected.

Furthermore, the matching logic213may determine whether a correlation exists between the reference model730and the association740depending on predetermined characteristics and thresholds. For example, the matching logic213may find a correlation when Z specific events are found to match in the reference model730and the association740(wherein Z is a predetermined number). Alternatively, the matching logic213may determine a correlation exists if a predetermined number of events and/or relationships are found to match between the reference model730and the association740. In yet another embodiment, the matching logic213may find a correlation if a predetermined number of events and/or relationships are found to match and one or more events and/or relationships are not present in both of the reference model730and the association740. Any combination of the above scenarios may be used to determine whether a correlation is present between the reference model730and the association740. The machine learning logic211may store these correlations in the machine learning data store211as a way of “learning” when one or more malicious events and/or relationships may be inferred.

Referring toFIG. 7D, an enhancement to the reference model730is shown. The event “Disabled TaskManager724” has been added to the reference model730and is illustrated with a dotted and dashed line. In addition, the relationship between the process 1.exe701and the event “Disabled TaskManager724” is also present in the reference model730similarly illustrated with a dotted and dashed line. As a result of the data transmitted to the MDVS200, and optionally, in addition to the data stored in the event log232and/or the machine learning data store212, the machine learning logic211may determine that there is sufficient correlation between an event and/or relationship and a reference model such that the event and/or relationship should be added to the reference model.

In one embodiment, a “sufficient correlation” may include the event and/or relationship appearing within a grouping of events a predetermined number of times. For example, if the event “Disabled TaskManager724” appears X number of times (wherein X is a predetermined threshold) when a process (e.g., 4.exe720) generates a mutex, hides files and tampers with network settings, the event “Disabled TaskManager”724will be added to the reference model including those events. Referring back toFIG. 1, the addition of event “Disabled TaskManager724” and the relationship between the between the process 1.exe701and the event “Disabled TaskManager724” is illustrated inFIG. 1as “exploit detection feedback” from block130to block120. The addition of one or more events and/or relationships to a reference model constitutes exploit detection feedback as illustrated inFIG. 1. The one or more events and/or relationships determined by the matching logic213and/or the machine learning logic211to be added to one or more reference models may be transmitted to the reference model generation logic215. The gathering logic212may gather the reference models to be updated from the machine learning data store214. The reference model generation logic215may then perform an updating process to the one or more gathered reference models by adding the one or more events or relationships into the one or more reference models. The reference models that are to be updated may be determined by gathering all reference models having one or more common events and/or relationships with the reference model used in the comparison or all reference models included in the machine learning data store214. Alternatively, reference models to be updated may be selected based on file types included in the reference models and/or a source that observed the events included in the reference models (e.g., email TDS, web TDS, file TDS and/or mobile TDS).

The enhanced reference model730may be used to update and/or allow for more particularized exploit detection. For example, the enhanced reference model730may be used by, among others, the management system242to further configure or reconfigure one or more of the sources (e.g., the endpoint device2501and/or the TDS2601). The reconfiguration or further configuration may entail, for example, configuring the one or more sources to search one or more pieces of network traffic for an extended amount of time, search the one or more pieces of network traffic multiple times and/or search for different malware exploits and/or certain events and/or relationships.

Alternatively, or in addition to, the enhanced reference model730may provide a means for updating one or more correlation rules for classifying malware (e.g., updating signatures or rules for determining whether an object of network traffic is suspicious and/or configuring and/or reconfiguring one or more virtual machines (VMs) included in one or more sources). Such updated signatures may be more robust due to the more complete picture of a malware exploit the updated signature provides. In one embodiment, the enhanced reference model730may provide improved alerts and recognition of malware based on the enhancement.

Referring toFIG. 8, an exemplary illustration of a comparison800of reference models820and821with an association of potentially malicious observed events is shown. Similar toFIGS. 7A-7C, the comparison800includes a left side and a right side. However, in contrast toFIGS. 7A-7Cshowing a single reference model, the left side of the comparison800includes the reference model820and the reference model821. One embodiment of the generation process of the association of potentially malicious events822(the association822) is similar to the embodiment describingFIGS. 7A-7C. Furthermore, in the embodiment ofFIG. 8, the machine learning logic211may infer events and/or relationships from two reference models.

InFIG. 8, the association822is seen to have solid lines illustrating the Event_A_1802and the Event_G_1805. In addition, the relationship connecting the Process_C_1810with the Event_A_1802and Event_G_1808are illustrated using solids lines. Therefore,FIG. 8, illustrates the Event_A_1802and the Event_G_1808and the connections (i.e., relationships) between the Process_C_1810and the events Event_A_1802and Event_G_1808were observed with at least a first confidence by one or more of the sources connected to, for example, the network240ofFIG. 2.

Furthermore, the events Event_D_1805and Event_F_1807as well as the connections between the Process_C_1810and the events Event_D_1805and Event_F_1807are illustrated as dotted lines meaning these events and connections were inferred from the Process_A_1801and/or the Process_B_1809. As can be seen inFIG. 8, the reference model820includes the Event_D_1805. The reference model821includes the Event_F_1807. In addition, not all events present in one or more of the reference models need to be inferred as occurring within the received data. For example, the events Event_B_1803and Event_C_1804was not inferred by the machine learning logic211as having occurred with the association822. In one embodiment, the received data along with the reference models available to the machine learning logic211may not have supported such an inference.

B. Malware Family Reference Model Generation

Malware family generation is the generation of comprehensive signatures used to identify one or more anomalous, or more specifically malicious, files, processes, etc., and/or relationships that are related through, among others, the evolution of a malware, a common point of attack or attack pattern (e.g., multiple pieces of malware gaining unauthorized access to the same file or process within an operating system), a common method of entering a network or electronic device (e.g., embedded software in an email or embedded software in a portable document format (PDF) file), a common targeted vulnerability (e.g., a common exploit kit), a common targeted information and/or a common targeted unauthorized access point. The generation of a malware family reference model may be triggered, for example, at predetermined time intervals, after receipt of a predetermined amount of data from the network240, and/or manually by a system administrator or the like.

Upon the triggering of the generation of a malware family reference model, the gathering logic212of the machine learning logic211initially gathers a plurality of appropriate reference models stored in the machine learning data store214. The gathering logic212determines which reference models are appropriate for generation of a malware family reference model based on one or more characteristics of the triggering event and/or the plurality of reference models currently stored in the machine learning data store214. The matching logic213of the machine learning logic211compares the received data and the one or more reference models gathered by the gathering logic212.

In one embodiment, the reference models stored in the machine learning data store214may all include one or more common events and/or relationships and therefore all reference models may be used to generate a family malware reference model. Alternatively, appropriate reference models for generating a malware family reference model may be selected based on file types included in the reference models and/or a source that observed the events included in the reference models (e.g., email TDS, web TDS, file TDS and/or mobile TDS). Furthermore, if a network administrator manually triggers the generation of a reference model, the network administrator may manually select one or more of the above characteristics for the gathering logic212to use in its determination of what reference models in the machine learning data store214are appropriate to include in the reference model generation.

Once the reference models that will be used to generate a malware family reference model have been gathered by the gathering logic212, the reference models are passed to the reference model generating logic215. As will be discussed below in relation toFIG. 9, the reference model generating logic215generates a malware family reference model by computing the mathematical union between the plurality of reference models gathered by the gathering logic212.

Referring toFIG. 9, an exemplary illustration of a process of generating a malware family reference model is shown. The generation process900performed by the reference model generation logic215ofFIG. 2includes a left side and a right side. The left side includes two reference models, the reference models930and931. The reference model930includes the Process_A_2901and the events Event_A_2902, Event_B_2903, Event_D_2905and Event_E_2906. The reference model931includes the Process_B_2908and the events Event_A_2902, Event_B_2903, Event_C_2904, Event_E_2906and Event_F_2907.

The malware family reference model940has been generated from the reference models930and931. The reference model generation logic215compares two or more reference models in order to generate a malware family reference model. The reference model generation logic215generates the malware family reference model by placing all distinct events in the two or more reference models compared (e.g., the mathematical union of the two or more reference models compared) into the malware family reference model (e.g., the malware family reference model940).

As illustrated inFIG. 9, the malware family reference model940contains all distinct events included in the reference models930and931. In particular, the reference model generation logic215generates the malware family reference model940by placing the events the reference model930has in common with the reference model931(the events Event_A_2902, Event_B_2903, Event_C_2904and Event_E_2906) in the malware family reference model940. The reference model generation logic215also places any events included in the reference model930in the malware family reference model940that are not included in the reference model931(the events Event_D_2905). To conclude, the reference model generation logic215places any events included in the reference model931in the malware family reference model940that are not included in the reference model930(the events Event_F_2907). The process of placing events in common or events included in less than all of the reference models compared to generate a malware family reference model may be done in any order.

The malware family reference model940also includes the process Process_C_2910. This process may be equivalent to any of the processes included in one or more of the reference models compared to generate the malware family reference model (e.g., the processes Process_A_2901and Process_B_2908).

The reference models used by the machine learning logic211to generate malware family reference models may be stored in the machine learning data store214and/or the event log232, and/or received over the network240. In addition, signatures generated in accordance with the discussion ofFIGS. 14A and 14Bmay be used in the generation of malware family reference models.

As mentioned above, interactive display screens comprisingFIGS. 7A-7Cmay be generated by the display generation logic211of the UI rendering subsystem220. In such an embodiment, the interactive display screens illustratingFIGS. 7A-7Cmay give a viewer a side-by-side visual comparison of a reference model and an association of potentially malicious events (e.g., at least a portion of data received over the network240). A side-by-side visual comparison may allow a viewer to understand the source of the anomalous behavior as well as determine what files, processes, network settings, etc., and/or relationships that may have been affected.

Referring to nowFIG. 10, an exemplary embodiment of an interactive display screen1000for display of associated events and/or particulars of the associated events used in generating the interactive display screens ofFIGS. 12-14Bis shown. Herein, rendered by the UI rendering subsystem220, the interactive display screen1000features a plurality of display areas1010and1030that illustrate information directed to events and particulars of the observed events over a time period by the one or more sources (the endpoint devices2501and2502, the TDSes2601-2603and/or the cloud computing services241ofFIG. 2) and or the management system242ofFIG. 2.

According to one embodiment, the display area1010displays a plurality of entries10201-1020R(R≧1, where R=9 for this embodiment) that provides information directed to observed events, where one or more events are anomalous or malicious. As shown, each row of entries (e.g., row10201) rendered by the UI rendering subsystem220features a plurality of fields, including one or more of the following: (1) a date and time of the observation421; (2) an event name422; (3) a process identification (PID)423(if applicable); (4) a path directing the viewer to the location at which the event may be located424; and/or (5) a source that observed the event (e.g., email TDS, web TDS, file TDS and/or mobile TDS).

A second area1030may be configured to allow selection of one or more observed potentially malicious events for viewing on a second visual representation. In one embodiment, when an observed event has been selected, the row may appear highlighted as is seen inFIG. 10. The buttons1040and1041enable viewing of an interactive visual representation (e.g., nodal diagram) of the selected events as they relate to one or more events within the display area1010and/or as they compare to one or more reference models of known anomalous or malicious behaviors. For example, based on the exemplary embodiment ofFIG. 10in which entry10202is selected, activation of the button1040labeled “Exploit Visualization” would subsequently present an interactive display screen of the relationships of the observed event represented in entry10202to other events, including perhaps one or more events appearing in display area1010(to be described below). Similarly, activation of the button1041labeled “Timeline Visualization” would subsequently present a second interactive display screen of the relationships of the observed event represented in the selected entry10202to other events, including perhaps one or more events appearing in display area1010(to be described below). Alternatively, activation of the button1042labeled “Generate Signature” would request the machine learning logic211ofFIG. 2to generate a signature based on the selected event and, in one embodiment, any subsequent events branching from the selected event (to be discussed in detail below).

One or more interactive display screens may be comprised of, among other things, a top-down nodal or tree diagram (e.g., an “exploit visualization”) or a left-to-right nodal or tree diagram (e.g., “a timeline visualization”). A time axis is illustrated inFIG. 12and will be discussed below. Particulars of the events may be included to provide a detailed understanding of, among other things, where events are located within an electronic device or various methods of identifying one or more events (e.g., file/process name or PID). In addition, the interactive display screen may provide the viewer an understanding of how the event was detected by color-coding the events or providing various line formatting (e.g., dashed lines, solid lines, double lines, etc.) based on, for example, the portion of a TDS or endpoint device that observed the event. Alternatively, the illustration of the events may be color-coded based on the type of event. Additionally, the display may be a static visual representation of the one or more relationships between one or more events.

In addition, a rank may be assigned to the events included in a nodal diagram. For example, when an association of events are illustrated as a top-down nodal diagram, each row of events may be considered to have the same rank, wherein a first event appearing above a second event has a higher rank than the second event. Alternatively, when an association of events are illustrated as a left-to-right nodal diagram, each column of events may be considered to have the same rank, wherein a first event appearing to the left of a second event has a higher rank than the second event.

Referring toFIG. 11, an exemplary portion of data generated by either the reference model generating logic215or the machine learning logic211expressed in XML is shown. As described above, the machine learning logic211generates interactive display screen information for the visual representation of one or more relationships between one or more events and the particulars of the events.FIG. 11illustrates one embodiment of data detailing the relationship of a first event to a second event and the relationship of the first event to a third event. For example, lines 5-6 denote the first and second events (node 1 and node 2 as “process_1” and “registry_1,” respectively). Line 9 denotes the relationship before the first and second events (edge 1 as “node_1.created/changed-properties.node_2”). Similarly, Lines 12-20 represent details of the relationship between the first event and the third event.

The data illustrated asFIG. 11may represent the interactive display screen information used by the display generation logic221to generate a display for viewer. For example, the data illustrated inFIG. 11is used by the display generation logic221to generate a portion ofFIGS. 12 and 13as discussed below.

Referring now toFIG. 12, an exemplary illustration of a first embodiment of an interactive display screen for display of associated events and particulars of the associated events is shown. InFIG. 12, the interactive display screen1200, depicted as a nodal diagram, illustrates the associated events at a high-level allowing a viewer to obtain an understanding of the relationships between one or more observed events wherein one or more anomalous behaviors are present. An anomalous behavior may be (i) a suspicious event or relationship that was observed by one or more of the sources (the endpoint devices2501and2502, the TDSes2601-2603and/or the cloud computing services241) or (ii) a malicious event or relationship observed by one or more of the sources. For example, a malicious event may cause performance of one or more actions that result in one or more malicious behaviors and/or one or more non-malicious behaviors. In general, the depiction of a first event appearing vertically above a second event is intended to illustrate that the first event was observed at a time prior to the second event. Similarly, a depiction of a second event appearing vertically equivalent (e.g., aligned in a row) with a third event, wherein the second event appears to the left of the third event, is intended to illustrate that the second event was observed at a time prior to the third event. It should be noted that exceptions may occur and labeling of such exceptions (e.g., by the use of numbering events and/or relationships) may be used to denote such exceptions to the viewer (numbering of exceptions will be illustrated in and described along withFIG. 13).

InFIG. 12, the Parent_Process_11201is seen to cause an action or operation resulting in the Process_11202at a first time. In one embodiment, the Parent_Process_11201may be a malicious event and starting the Process_11202may constitute a malicious action or operation (e.g., if the Process_11202is also a malicious event and/or if the starting of the Process_11202was not a normal function of the electronic device on which the action or operation occurred (or virtual machine performing processing of the Parent_Process_11201)). Alternatively, the Parent_Process_11201and/or the Process_11202may be non-malicious events and the starting of the Process_11202may be construed as a non-malicious action or operation.

In addition, the Process_11202causes the performance of one or more actions or operations that result in the events including: (i) the Registry_11203; (ii) the File_11204; (iii) the File_21205; and (iv) the Process_21206. Similarly, the File_11204is depicted as causing the performance of an action or operation that results in the Process_31207. Furthermore, the Process_21206is depicted as causing the performance of an action or operation that results in the File_31208.

Therefore, according to one embodiment, when the interactive display screen1000ofFIG. 10is viewed and the button1440(“Exploit Visualization”) is activated, the interactive display screen1200is displayed using the information included in the interactive display screen1000which may be derived from interactive display screen information expressed as XML files similar toFIG. 11.

As mentioned above, a time axis1210is illustrated inFIG. 12. The time axis1210illustrates the embodiment wherein an interactive display screen (e.g., the interactive display screen1200) is configured to illustrate an order of events in a sequential manner according to one or more time axes. The time axis1210shows that the events in the interactive display screen1200are ordered in a top-to-bottom and left-to-right manner according to the time of performance of the one or more actions or operations that resulted in the events1201-1208. For example, the event1202is illustrated below the event1201implying that the performance of the one or more actions or operations that resulted in the event1201occurred prior in time to the one or more actions or operations that resulted in the event1202. Similarly, the event1203is illustrated to the left of the event1204implying that the performance of the one or more actions or operations that resulted in the event1203occurred prior in time to the one or more actions or operations or behaviors that resulted in the event1204. In another embodiment, a time axis may only comprise one axis (e.g., horizontal such as left-to-right, vertical such as top-to-bottom, etc.). Alternatively, a time axis may not be included in an interactive display screen.

In addition, a time axis may be present in an interactive display screen illustrating a left-to-right nodal diagram (e.g., an embodiment in whichFIG. 7Dmay be used as an interactive display screen). As stated above, when a time axis is present in an interactive display screen illustrating a left-to-right nodal diagram, the time axis may comprise a single axis (e.g., only top-to-bottom) or may comprise two time axes (e.g., top-to-bottom and left-to-right).

Referring back toFIG. 2, the machine learning engine210analyzing observed events comprising an exploit after the occurrence of the exploit may fail to determine the source of infection. Even if the events are observed in their entirety, sometimes the voluminous manner of the observed events (events comprising both malicious events and non-malicious events) may make the determination of the presence of an exploit and/or malware difficult. Being able to compare the observed events with a reference model assists in sifting through the data and discovering the origin of infection. For example, a user may have browsed to a well-known Uniform-Resource Locator (URL) that was compromised and unintentionally downloaded malware on an endpoint. Subsequently, the malware may have stolen data and uploaded the stolen data to a foreign server. A reference model stored in the MDVS200may contain the sequence of such events. If the matching logic213of the MDVS200is able to match the observed events with a portion of the reference model, the machine learning logic211may infer that all of the events occurred although not all of the events were observed based on the sequential ordering of the reference model. The matching logic213may determine that one or more events in the reference model were not observed, or were not observed with at least a first confidence. For example, based on the sequential ordering of the events and the time axis of the reference model, the machine learning logic211may infer that an event_B occurred prior to an event_C but subsequent to an event_A, although event_B was not observed by at least one source (e.g., the endpoint device2501).

In addition, the machine learning logic211may trace the root cause of the exploitation back to the initial visit to the compromised URL based on a time axis and the sequential ordering of the events in the reference model. In one embodiment, the presence of a time axis on an interactive display screen may allow a viewer, such as a network administrator, to visually understand which event was the root cause of the exploit.

Referring toFIG. 13, an exemplary illustration of a detailed embodiment of the interactive display screen ofFIG. 12is shown. In addition to events1201-1208ofFIG. 12, interactive display screen1300illustrates events1301-1306corresponding to the Registry_2, the Registry_3, the Registry_4, the File_4, the Folder_1 and the File_5, respectively. In particular, the Process_31207causes the performance of one or more actions or operations that result in events1301-1306.

In addition to providing a visual representation of how the events1201-1208and1301-1306are related, the interactive display screen1300displays one or more particulars of each event. For example, the path (“c:/doc1/local1/temp/4.exe”) and the PID (“1676”) are displayed for the Process_11202. The particulars displayed for each event may differ, for example, only the path of an event may be displayed as is the case with the File_11204in the present embodiment.

Furthermore, the interactive display screen1300provides the viewer with the relationship between two events and the timing of the observation of the relationship. For example, the relationship between the Process_11202and the File_11208is the third relationship generated of the relationships displayed in the interactive display screen1300. In addition, the relationship between the Process_11202and the File_11208is seen to be “created.” Therefore, from the interactive display screen1300, a viewer can easily determine that, of the events and relationships included in the display screen1300, the operation of the Process_11202creating the File_11204was the third relationship created. The Process_11202then opens the File_21205and starts the Process_31207(which is the File_11204being launched as a process as the File_11204is an executable file). In addition, the Process_11202starts the Process_21206as the seventh relationship.

The Process_21206deletes the File_31208as the eighth relationship. Subsequently, the Process_31207sets the name/value pair for the Registry_2, the Registry_3 and the Registry_4 as the ninth, tenth and eleventh relationships respectively. The Process_31207then opens the Registry_5, the Folder_1 and the File_5 as the twelfth, thirteenth and fourteenth relationships respectively.

V. Signature Generation

As mentioned above, one embodiment of the invention enables a viewer to generate one or more signatures from the interactive display screens of, for example,FIGS. 10 and 12-14B. In one embodiment, the viewer may select an event and generate a signature based on the event including any events that directly and/or indirectly branched from the selected event. In a second embodiment, the viewer may select a particular grouping of events and generate a signature limited to those selected events. The generated signatures may be stored in the machine learning data store214ofFIG. 2to be used in future comparisons of one or more reference models of a plurality of events and at least one or more relationships where at least one of these events and/or relationships is an anomalous behavior or known to be malicious. In addition, signatures generated from a first set of data received from a first endpoint device may be compared to similar signatures generated from a second set of data received from a second endpoint device in order to determine whether an event frequently appears across multiple endpoint devices (e.g., correlated operations or actions across endpoint devices). The frequent appearance of an event across multiple endpoint devices may imply that the event is malicious (e.g., an exploit), or at least suspicious. In addition, the frequent appearance of one or more events across multiple endpoint devices (or other sources that supply data to the MDVS200) may indicate that the one or more sources is associated with a malware family.

Referring toFIG. 14A, an exemplary illustration of a portion of an interactive display screen for enabling a viewer to generate a signature of a selected event, display particulars of the selected event and/or generate an alert for a selected event is shown.FIG. 14Aillustrates a viewer selecting an event (e.g., the Process_21206ofFIG. 12) which brings up an overlaying pop-up box1410allowing the viewer to select to “Generate Signature1411,” “Display Info Parameters1412” or “Generate Alert1413.” The selection of “Generate Signature1411” enables the viewer to generate a signature (e.g., a reference model) based on the selected event. The signature may include all events that are a direct or indirect branch from the selected event. For example, a viewer selecting “Generate Signature1411” for the Process_21206may generate a signature including the Process_21206and the File_31208(as is seen inFIG. 12). The selection of “Display Info Parameters1412” for the Process_21206would display an interactive display screen including the information included in the row10206ofFIG. 10. The selection of “Generate Alert1413” enables a viewer to generate a rule for the MDVS200to issue an alert when the selected event is observed by an endpoint device or other source. Therefore, according to the example inFIG. 14A, when a viewer selects “Generate Alert1413” for the Process_21206, the MDVS200will issue an alert to the viewer notifying the viewer of the observation of the Process_21206at an endpoint device. In one embodiment, the MDVS200will issue the alert when the MDVS200receives data containing an observation of the Process_21206. In a second embodiment, the MDVS200may notify the management system242of the creation of the rule and the management system242may propagate the rule to each source connected to the network240(the endpoint devices2501-2502, the TDS2601-2603and the cloud computing services241).

Referring back toFIG. 1, the selection of one or more of “Generate Signature1411,” “Display Info Parameters1412” or “Generate Alert1413” is equivalent to the “Interactive Display Screen Input” illustrated inFIG. 1. The interactive display screen input is transmitted from block150to block120. In particular, the data obtained from the selecting “Generate Signature1411” includes the particulars of the selected event (e.g., the Process_21206as seen inFIG. 14A) and potentially the events branching from the selected event and the relationships that connect the selected event and any branched events. This data obtained from the selection of “Generate Signature1411” may be stored as a signature/reference model in the machine learning data store214for use in future exploit detection processes and/or reference model generation processes.

The selection of “Display Info Parameters1412” may result in a query by the gathering logic212to the machine learning data store214and/or the event log232to gather the particulars of the selected process. The machine learning logic211may generate interactive display screen information based on the data gathered by the gathering logic212. The display generation logic221may use the interactive display screen information to generate a display in a layout similar to the display screen ofFIG. 10.

The selection of “Generate Alert1413” may result in the gathering of the particulars of the selected process, any events that are branched from the selected event and any relationships connecting the branched events by the gathering logic212and the generation of an alert by the machine learning logic211.

It should be noted that, although in the above paragraphs information (e.g., the particulars) of branched events and the corresponding relationships may be gathered as well as the selected event, the particulars of only the selected event may be gathered as well. The system may be set up to gather either, or a network administrator may be able to adjust how the system responds to a selection of one or more of “Generate Signature1411,” “Display Info Parameters1412” and/or “Generate Alert1413.”

Referring toFIG. 14B, an exemplary illustration of a second embodiment of an interactive display screen for enabling a viewer to generate a signature of a selected event is shown.FIG. 14Billustrates that a viewer has selected a particular grouping of events (the Process_3, the Registry_2, the Registry_3, the File_4 and the Folder_1) for which the viewer may generate a signature by selecting “Generate Signature1411.” The generated signature inFIG. 14Bdiffers slightly from that ofFIG. 14Ain the sense that the signature of14A may include all of the events branching directly and/or indirectly from the selected from.FIG. 14Bdoes not include the event File_51406. The exclusion of the event File_51406may be a result of the viewer knowing whether the event File_51406are not malicious and therefore should be not included in a reference model. The selection of “Generate Signature1411” inFIG. 14Bhas the same effect as discussed in reference toFIG. 14Aabove.

Referring toFIG. 15, is an exemplary portion of the generated signature (corresponding to the selected section inFIG. 14B) expressed in XML. The data illustrated byFIG. 15represents the XML generated when a viewer generates a signature from the interactive display screen1300as illustrated inFIG. 14B. As seen inFIG. 14B, a portion of the interactive display screen1300has been manually selected by a user and an input (e.g., clicking of a button on a mouse) allows the viewer to generate a signature by activating the option labeled “Generate Signature”1411. The data illustrated inFIG. 15may be stored in the machine learning data store214and used by the reference model generation logic215and/or the matching logic213to either generate a reference model or perform an exploit detection process, respectively.

In the foregoing description, the invention is described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims.