Method of malware detection and system thereof

Information

  • Patent Grant
  • 12026257
  • Patent Number
    12,026,257
  • Date Filed
    Tuesday, March 7, 2023
    a year ago
  • Date Issued
    Tuesday, July 2, 2024
    6 months ago
Abstract
There is provided a system and a computer-implemented method of detecting malware in real time in a live environment. The method comprises: monitoring one or more operations of at least one program concurrently running in the live environment, building at least one stateful model in accordance with the one or more operations, analyzing the at least one stateful model to identify one or more behaviors, and determining the presence of malware based on the identified one or more behaviors.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

Any and all applications for which a foreign or domestic priority claim is identified in the Application Data Sheet as filed with the present application are hereby incorporated by reference under 37 CFR 1.57. The present application claims the benefit of U.S. patent application Ser. No. 16/849,808, filed Apr. 15, 2020, now U.S. Pat. No. 11,625,485, U.S. patent application Ser. No. 15/623,669, filed Jun. 15, 2017, now U.S. Pat. No. 10,664,596, and U.S. patent application Ser. No. 14/456,127, filed Aug. 11, 2014, now U.S. Pat. No. 9,710,648, the entire contents of each of which are hereby incorporated by reference herein for all purposes as if set forth fully herein.


TECHNICAL FIELD

The presently disclosed subject matter relates, in general, to the field of the detection of malicious software (malware), and more specifically, to methods and systems for behavior based malware detection.


BACKGROUND OF THE INVENTION

With the rapid growth of computer technology and widespread Internet access, malware threats have continued to grow significantly in recent decades, and thus have caused severe damage to systems, such as hardware failures and loss of critical data, etc.


Various antivirus technologies are currently in use, including signature and behavior based analysis, which aim to identify and prevent further spread of malware in the network. Signature-based analysis involves searching for known patterns of malicious code within executable code. However, malware is often modified (e.g., by obfuscating and randomizing content) in order to change its signature without affecting functionality, which renders the signature-based analysis mechanism as being increasingly ineffective. Due to an increase in malware variants (e.g., malware variants with the same behavior but different signatures), behavior-based analysis may be used to identify malware variants that have similar effects and thus can be handled with similar security measures.


Behavior-based analysis detects malware by monitoring behaviors of malicious activities rather than static signatures. Existing behavioral monitoring systems include a database of actions that are blacklisted and indicate malicious intent. If a given process or program performs any of the actions listed in the database, the action is blocked, and the process may be identified as malicious, and thus be terminated, by the monitoring system.


There is a need in the art for a new method and system for malware detection.


References considered to be relevant as background to the presently disclosed subject matter are listed below. Acknowledgement of the references herein is not to be inferred as meaning that these are in any way relevant to the patentability of the presently disclosed subject matter.


U.S. Pat. No. 8,555,385 (Bhatkar et al.) entitled “Techniques for behavior based malware analysis” discloses techniques for behavior based malware analysis. In one particular embodiment, the techniques may be realized as a method for behavior based analysis comprising receiving trace data, analyzing, using at least one computer processor, observable events to identify low level actions, analyzing a plurality of low level actions to identify at least one high level behavior, and providing an output of the at least one high level behavior.


U.S. Pat. No. 7,530,106 (Zaitsev et al.) entitled “System and method for security rating of computer processes” discloses a system, method, and computer program product for secure rating of processes in an executable file for malware presence, comprising: (a) detecting an attempt to execute a file on a computer; (b) performing an initial risk assessment of the file; (c) starting a process from code in the file; (d) analyzing an initial risk pertaining to the process and assigning an initial security rating to the process; (e) monitoring the process for the suspicious activities; (f) updating the security rating of the process when the process attempts to perform the suspicious activity; (g) if the updated security rating exceeds a first threshold, notifying a user and continuing execution of the process; and (h) if the updated security rating exceeds a second threshold, blocking the action and terminating the process.


U.S. Pat. No. 8,607,340 (Wright) entitled “Host intrusion prevention system using software and user behavior analysis” discloses improved capabilities for threat detection using a behavioral-based host-intrusion prevention method and system for monitoring a user interaction with a computer, software application, operating system, graphic user interface, or some other component or client of a computer network, and performing an action to protect the computer network based at least in part on the user interaction and a computer code process executing during or in association with a computer usage session.


US Patent Application No. 2012/079,596 (Thomas et al.) entitled “Method and system for automatic detection and analysis of malware” discloses a method of detecting malicious software (malware) including receiving a file and storing a memory baseline for a system. The method also includes copying the file to the system, executing the file on the system, terminating operation of the system, and storing a post-execution memory map. The method further includes analyzing the memory baseline and the post-execution memory map and determining that the file includes malware.


SUMMARY OF THE INVENTION

In accordance with an aspect of the presently disclosed subject matter, there is provided a computer-implemented method of detecting malware in real time in a live environment, the method comprising: monitoring one or more operations of at least one program concurrently running in the live environment; building at least one stateful model in accordance with the one or more operations; analyzing the at least one stateful model to identify one or more behaviors; and determining the presence of malware based on the identified one or more behaviors.


In accordance with an embodiment of the presently disclosed subject matter, there is further provided a computer-implemented method, wherein the monitoring further comprises: generating event data characterizing one or more events, each of the events being indicative of a corresponding monitored operation of the one or more operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the monitoring the one or more operations further includes selecting at least one operation of interest from the one or more operations, and monitoring the selected at least one operation of interest.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the at least one operation of interest includes one or more in-process operations and/or one or more kernel related operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the kernel related operations include one or more of the following: file system operations, process and memory operations, registry operations, and network operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the in-process operations are monitored by intercepting one or more library calls representing the in-process operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the kernel related operations are monitored by intercepting one or more system calls representing the kernel related operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the kernel related operations are monitored by registering one or more kernel filter drivers for the kernel related operations via one or more callback functions.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method further comprising, for each event of the one or more events, generating a respective event data characterizing the event, wherein the event data includes at least the following attributes of the event: operation type, and source of the event.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the at least one stateful model includes one or more objects derived from the one or more operations and one or more relationships identified among the objects in accordance with the operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein each of the objects represents an entity involved in the operations and is of a type selected from a group that includes: process object, file object, network object, registry object, and windows object.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein each of the at least one stateful model is a program-level stateful model that represents a sequence of linked operations related to a given program of the at least one program.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the at least one stateful model is a system-level stateful model that represents operations related to all programs that run concurrently in the live environment.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the system-level stateful model includes one or more program-level stateful models each representing a sequence of linked operations related to a given program of the all programs.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method further comprising monitoring one or more kernel related operations of the at least one program; building at least one stateful model based on the monitored kernel related operations; analyzing the at least one stateful model to identify one or more behaviors; and determining the presence of malware based on a behavioral score of the stateful model.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method wherein the at least one stateful model includes one or more objects derived from the one or more operations and one or more relationships identified among the objects in accordance with the operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the building the at least one stateful model comprises, for each event data associated with the event, normalizing the event data giving rise to an abstract event; retrieving one or more objects from the abstract event, each of the objects representing an entity involved in a corresponding operation and being of a type selected from a group that includes: process object, file object, network object, registry object and windows object, at least one of the objects representing the source of the event; identifying one or more relationships among the objects in accordance with the abstract event, and generating respective associations among the objects corresponding to the identified relationships, giving rise to an event context comprising the one or more objects and the associations therein; in case of the event being a first event of a stateful model, generating the stateful model including the event context; otherwise updating a previous stateful model based on the event context, giving rise to an updated stateful model, the previous stateful model corresponding to at least one previous event that precedes the event.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the updating further includes: in case the previous stateful model includes the one or more objects, adding the associations of the event context to the previous stateful model, giving rise to the updated stateful model; otherwise in case of at least one object of the objects being a new object that is not included in the previous stateful model, adding the new object and the associations of the event context to the previous stateful model, giving rise to the updated stateful model.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method further comprising selecting selected event data associated with events of interest from the event data based on one or more predefined filtering rules and applying the normalizing of the event data with respect to the selected event data.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the one or more predefined filtering rules include filtering out event data associated with the following events: uncompleted events, memory related events of which a targeting process is not a remote process, and events in which a targeting process does not exist.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein normalizing the event data includes formatting the event data and parsing the formatted event data giving rise to the abstract event.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the analyzing the at least one stateful model includes analyzing the event context in view of the stateful model or the updated stateful model in accordance with one or more predefined behavioral logics, and determining the presence of at least one behavior of the one or more behaviors upon any of the predefined behavioral logics being met, the at least one behavior related to a sequence of events of the stateful model including at least the event.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the predefined behavioral logics include determining a behavior of self-execution when the following condition is met: a target of an event is an object that is included in the stateful model.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method wherein each of the at least one behavior is assigned with a respective behavioral score.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the determining the presence of malware further includes: in case of the at least one behavior being determined: searching if there is a previous stateful model score associated with the previous stateful model, the previous stateful model score being an aggregated behavioral score of all previous behavioral scores assigned for respective previous determined behaviors, the previous determined behaviors being related to the at least one previous event of the previous stateful model, if not, determining a sum of the respective behavioral score assigned for each of the at least one behavior as the stateful model score associated with the stateful model; otherwise increasing the previous stateful model score with the sum, giving rise to the stateful model score; comparing the stateful model score with a predefined threshold; and determining the presence of malware if the stateful model score passes the predefined threshold.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the respective behavioral score is assigned with a corresponding weight factor if a condition is met, and the increasing comprises applying the corresponding weight factor to the respective behavioral score giving rise to a respective weighted behavioral score, and increasing the previous stateful model score with a sum of the respective weighted behavioral score assigned for each of the at least one behavior.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the condition includes that a source of an event is a remote process and a target of the event is a system process.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a computer-implemented method, wherein the method further comprises: eliminating determined malware by remediating the one or more operations indicated by the stateful model.


In accordance with an aspect of the presently disclosed subject matter, there is yet further provided a system for detecting malware in real time in a live environment, the system comprising a processor configured to perform at least the following: monitor one or more operations of at least one program concurrently running in the live environment; build at least one stateful model in accordance with the one or more operations; analyze the at least one stateful model to identify one or more behaviors; and determine the presence of malware based on the identified one or more behaviors.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system, wherein the at least one stateful model includes one or more objects derived from the one or more operations and one or more relationships identified among the objects in accordance with the operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system, wherein each of the objects represents an entity involved in the operations and is of a type selected from a group that includes: process object, file object, network object, registry object, and windows object.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system, wherein each of the at least one stateful model is a program-level stateful model that represents a sequence of linked operations related to a given program of the at least one program.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system, wherein the at least one stateful model is a system-level stateful model that represents operations related to all programs that run concurrently in the live environment.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system, wherein the system-level stateful model includes one or more program-level stateful models each representing a sequence of linked operations related to a given program of the all programs.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system, wherein the processor is further configured to perform the following: monitor one or more kernel related operations of said at least one program; build at least one stateful model based on said monitored kernel related operations; analyze the at least one stateful model to identify one or more behaviors; and determine the presence of malware based on a behavioral score of said stateful model.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system, wherein the kernel related operations include one or more of the following: file system operations, process and memory operations, registry operations, and network operations.


In accordance with an embodiment of the presently disclosed subject matter, there is yet further provided a system, wherein the processor is further configured to monitor the one or more kernel related operations by registering one or more kernel filter drivers for the kernel related operations via one or more callback functions.


In accordance with an aspect of the presently disclosed subject matter, there is yet further provided a non-transitory program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for detecting malware in real time in a live environment, the method comprising: monitoring one or more operations of at least one program concurrently running in the live environment; building at least one stateful model in accordance with the one or more operations; analyzing the at least one stateful model to identify one or more behaviors; and determining the presence of malware based on the identified one or more behaviors.





BRIEF DESCRIPTION OF THE DRAWINGS

In order to understand the presently disclosed subject matter and to see how it may be carried out in practice, the subject matter will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:



FIG. 1 is a functional block diagram schematically illustrating a malware detection system, in accordance with certain embodiments of the presently disclosed subject matter;



FIG. 2 is a generalized flowchart of detecting malware in accordance with certain embodiments of the presently disclosed subject matter;



FIG. 3 is a generalized flowchart of building a stateful model in accordance with certain embodiments of the presently disclosed subject matter;



FIGS. 4a and 4b are schematic illustrations of an exemplified stateful model and an exemplified updated stateful model in accordance with certain embodiments of the presently disclosed subject matter, and



FIG. 5 is a generalized flowchart of an exemplified sequence of operations being monitored and processed in accordance with certain embodiments of the presently disclosed subject matter.





DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosed subject matter. However, it will be understood by those skilled in the art that the present disclosed subject matter can be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present disclosed subject matter.


In the drawings and descriptions set forth, identical reference numerals indicate those components that are common to different embodiments or configurations.


Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as “monitoring”, “building”, “analyzing”, “determining”, “generating”, “selecting”, “normalizing”, “comparing”, “formatting”, “parsing”, “searching”, “increasing”, “eliminating”, “terminating”, “providing”, or the like, include action and/or processes of a computer that manipulate and/or transform data into other data, said data represented as physical quantities, e.g. such as electronic quantities, and/or said data representing the physical objects. The terms “computer”, “processor”, “processing unit”, “host machine”, and “end user station” should be expansively construed to include any kind of electronic device with data processing capabilities, including, by way of non-limiting examples, a personal computer, a server, a computing system, a communication device, a processor (e.g. digital signal processor (DSP), a microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), any other electronic computing device, and or any combination thereof.


The operations in accordance with the teachings herein can be performed by a computer specially constructed for the desired purposes or by a general purpose computer specially configured for the desired purpose by a computer program stored in a non-transitory computer readable storage medium.


The term “non-transitory” is used herein to exclude transitory, propagating signals, but to otherwise include any volatile or non-volatile computer memory technology suitable to the presently disclosed subject matter.


As used herein, the phrase “for example,” “such as”, “for instance” and variants thereof describe non-limiting embodiments of the presently disclosed subject matter. Reference in the specification to “one case”, “some cases”, “other cases” or variants thereof means that a particular feature, structure or characteristic described in connection with the embodiment(s) is included in at least one embodiment of the presently disclosed subject matter. Thus the appearance of the phrase “one case”, “some cases”, “other cases” or variants thereof does not necessarily refer to the same embodiment(s).


It is appreciated that, unless specifically stated otherwise, certain features of the presently disclosed subject matter, which are described in the context of separate embodiments, can also be provided in combination in a single embodiment. Conversely, various features of the presently disclosed subject matter, which are described in the context of a single embodiment, can also be provided separately or in any suitable sub-combination.


In embodiments of the presently disclosed subject matter, fewer, more and/or different stages than those shown in FIGS. 2 and 3 may be executed. In embodiments of the presently disclosed subject matter one or more stages illustrated in FIGS. 2 and 3 may be executed in a different order and/or one or more groups of stages may be executed simultaneously. FIG. 1 illustrates a general schematic of the system architecture in accordance with an embodiment of the presently disclosed subject matter. Each module in FIG. 1 can be made up of any combination of software, hardware and/or firmware that performs the functions as defined and explained herein. The modules in FIG. 1 may be centralized in one location or dispersed over more than one location. In other embodiments of the presently disclosed subject matter, the system may comprise fewer, more, and/or different modules than those shown in FIG. 1.


As aforementioned, behavior-based analysis detects malware by monitoring behaviors of malicious activities rather than static signatures. There are a number of problems existing m current behavior-based technologies. For instance, due to the frequently changing behaviors of malicious programs, new instances of malwares may not be detected immediately due to lack of information about their behaviors and functionality. Current behavior-based technologies may also fail to trace a sequence of events, each of which, independently, is not identified as malicious, but when considered within the sequence context, is actually performing a malicious action. Moreover, current behavior-based technologies are normally implemented by performing emulation and running suspected malware in a safe environment (e.g., a sandboxed virtual machine) to reveal otherwise obscured logics and behaviors. This kind of emulation is normally very limited and the suspected malware under scrutiny never actually runs in a live environment. Thus it is impossible to actually observe full execution and interaction of the suspected malware with other processes and files that are not emulated in the safe environment. Therefore, not all potential malicious behaviors of the suspected malware can be detected by performing such emulation. Furthermore, it is typically resource-intensive to collect and analyze the large amount of operation information contained by suspicious malwares in order to identify potential behaviors, especially for a host machine with limited resources, such as an end user station. Certain embodiments of the detailed description are able to cope with these problems.


Bearing this in mind, attention is drawn to FIG. 1, schematically illustrating a functional block diagram of a malware detection system in accordance with certain embodiments of the presently disclosed subject matter.


The term “malware” used in this specification should be expansively construed to include any kind of computer virus, ransomware, worms, trojan horses, rootkits, keyloggers, dialers, spyware, adware, malicious Browser HelperObjects (BHOs), rogue security software, or any other malicious or undesirable programs.


A Malware Detection System 100 illustrated in FIG. 1 implements a computer-based malware detection mechanism, which enables end users to detect malware in real time in a live environment. The term “live environment” used in this specification should be expansively construed to include any kind of host machine configuration where computer programs and products are actually put into operation for their intended uses by end users, such as, for example, an end user station with programs concurrently running in a production environment, in contrast to a safe environment, such as, for example, an emulated environment, or a sandboxed virtual machine environment.


As shown, the Malware Detection System 100 includes at least one Processing Unit 101 that comprises the following functional modules: Monitoring Module 104, Event Parsing Module 106, Behavior Analyzing Module 110, and Decision Making Module 114. Alternatively the Processing Unit 101 can be operatively coupled to the functional modules, and configured to receive instructions therefrom and execute operations in accordance with the instructions.


The Monitoring Module 104 can be configured to monitor, in real time, one or more operations 102 of at least one computer program that runs concurrently in the live environment. It is to be noted that the term “operation” used in this specification should be expansively construed to include any kinds of actions performed by one or more processes, threads, applications, files or any other suitable entities in any operating system. By way of non-limiting example, in a Windows operating system, operations can be performed by one or more processes of the computer programs. For purpose of illustration only, references are made in part of the following description with respect to operations performed by one or more processes. Embodiments are, likewise, applicable to operations performed by any other suitable entities in any operating system as described above.


A process is an instance of a computer program that is being executed. A process can further create child processes, and a computer program can be associated with one or more processes. It should be noted that the term “program” used in this specification should be expansively construed to include any kind of system software (e.g., operating system, device drivers, etc.) and application software (e.g., office suites, media players, etc.) that perform specified tasks with a computer.


As aforementioned, Monitoring Module 104 can monitor all the operations (e.g., performed by processes or other entities) occurred in the live system environment. According to certain embodiments, the Monitoring Module 104 can further include two sub-components: an In-process Monitoring Module 107 and a Kernel Monitoring Module 109. The In-process Monitoring Module can monitor all in-process operations that are performed at process level and do not necessarily involve the kernel of an operating system. The Kernel Monitoring Module can monitor all operations that request services from an operating system's kernel, such as file system operations, process and memory operations, registry operations, and network operations, as further elaborated with respect to FIG. 2.


It is to be further noted that, without limiting the scope of the disclosure in any way, in some cases one operation can be construed to include a single action, such as “file read”. In some other cases, one operation can also be construed to include a sequence of actions, for example, “file copy” can be regarded as one operation which includes a sequence of three sequential actions “file create”, “file read”, and “file write”.


Event Parsing Module 106 can be configured to build at least one stateful model 108 in accordance with the one or more operations that are monitored by the Monitoring Module 104. According to certain embodiments, a stateful model is a data model with hierarchical structure that contains information indicative of a real time updated system state resulted from a sequence of operations performed in a live environment. The sequence of operations can be linked together by context. Thus the stateful model can be a logical representation (e.g., a tree structure, etc) of a sequence of linked operations. For instance, the stateful model 108 can include one or more objects derived from real time operations 102, and one or more relationships identified among the objects in accordance with the operations. According to certain embodiments, each of the objects of the stateful model 108 can represent an entity related in the operations and can be of a type selected from a group that includes: process object, file object, network object, registry object and windows object. The stateful model can further include attributes characterizing the objects and the identified relationships therein, as further elaborated with respect to FIGS. 3 and 4.


Behavior Analyzing Module 110 can be configured to analyze the stateful model 108 constructed by Event Parsing Module 106 to identify one or more behaviors. It should be noted that the term “behavior” used in this specification should be expansively construed to include any sequence of operations performed by one or more processes that fulfill one or more predefined behavioral logics (also termed as “behavioral signatures” hereinafter).


According to certain embodiments, the Malware Detection System 100 can further comprise a Storage Module 105 that comprises anon-transitory computer readable storage medium. The Storage Module 105 can include a Behavioral Signature Database 112 that is operatively coupled to the Behavior Analyzing Module 110 and stores the one or more predefined behavioral logics. According to certain embodiments, the predefined behavioral logics are behavioral signatures indicative of specific behavioral patterns. In some cases, the behavioral logics can be predefined based on prior knowledge of certain malware behaviors, such as, for instance, self-deletion, self-execution, and code injection, etc. Optionally, the predefined behavioral logics can also include one or more logics indicative of benign behaviors, as further elaborated with respect to FIG. 2. The stateful model 108 that is built by the Event Parsing Module 106 can also be stored in the Storage Module 105.


Decision Making Module 114 can be configured to determine the presence of malware based on the one or more behaviors identified by the Behavior Analyzing Module 110, as further elaborated with respect to FIG. 2.


According to certain embodiments, the Processing Unit 101 can further include a Mitigation Module 116 configured to eliminate the determined malware by remediating the one or more operations indicated by the stateful model.


According to further embodiments, the Malware Detection System 100 can further include an VO interface 103 communicatively coupled to the Processing Unit 101. The VO interface 103 can be configured to perform the following actions: receive instructions from end users and/or from one or more of the functional modules, and provide an output of processed information obtained from the functional modules, e.g., an illustration of the determined malware, to the end users.


According to certain embodiments, the Processing Unit 101 is further configured to perform at least one of the aforementioned operations of the functional components of the Malware Detection System 100 in realtime.


The operation of the Malware Detection System 100 and of the various components thereof is further detailed with reference to FIG. 2.


While not necessarily so, the process of operation of the Malware Detection System 100 can correspond to some or all of the stages of the method described with respect to FIG. 2. Likewise, the method described with respect to FIG. 2 and its possible implementations can be implemented by the Malware Detection System 100. It is therefore noted that embodiments discussed in relation to the method described with respect to FIG. 2 can also be implemented, mutatis mutandis as various embodiments of the Malware Detection System 100, and vice versa.


It should be further noted that the aforementioned functional components of the Malware Detection System 100 can be implemented in a stand-alone computer, such as the end user station. Or alternatively, one or more of the functional components can be distributed over several computers in different locations. In addition, the above referred modules can, in some cases, be cloud based.


Those versed in the art will readily appreciate that the teachings of the presently disclosed subject matter are not bound by the system illustrated in FIG. 1. Alternative to the example shown in FIG. 1, the Malware Detection System 100 can, in some cases, include fewer, more and/or different modules than shown in FIG. 1. Equivalent and/or modified functionality can be consolidated or divided in another manner and can be implemented in any appropriate combination of software, firmware and hardware.


Turning now to FIG. 2, there is shown a generalized flowchart of detecting malware in accordance with certain embodiments of the presently disclosed subject matter.


As illustrated in FIG. 2, one or more operations of at least one program that runs in a live environment can be monitored (202) in real time, e.g., by the Monitoring Module 104 of the Malware Detection System 100. As aforementioned, in contrast to a safe environment, a live environment should include one or more computer programs that are put into operation for their intended uses. The computer programs run concurrently and interactively (e.g., with other programs and/or end users) in the live environment. According to certain embodiments, one or more processes can be launched by the one or more programs. Each process can perform one or more operations in order to communicate with and/or request services from the operating system. Accordingly, the Monitoring Module 104 can be configured to monitor the one or more operations performed by each process.


Due to the large number of concurrently running programs and operations thereof in a live environment, the amount of information contained in the monitored operations can be huge. According to certain embodiments, the Monitoring Module 104 can be configured to select at least one operation of interest from the one or more operations, and monitor the selected at least one operation of interest.


According to certain embodiments, the at least one operation of interest includes one or more in-process operations and/or one or more kernel related operations. In-process operations can include any operation performed in user space (i.e., the memory area where application software executes) and do not necessarily involve the kernel of an operating system, such as, by way of non-limiting example, local process memory allocation, mapping functions from imported libraries, and read/write process memory. In some cases, the in-process operations can be monitored (e.g., by the In-process Monitoring module) by intercepting one or more library calls (e.g., API calls) that represent the corresponding operations. By way of non-limiting example, the In-process Monitoring module can attach monitoring hooks to the library calls in user space in order to monitor these calls.


The kernel related operations, on the other hand, can include one or more of the following operations that are performed in kernel space (i.e., the memory area reserved for running privileged kernel, kernel extensions, and most device drivers): file system operations, process and memory operations, registry operations, and network operations. Specifically, by way of non-limiting example, file system operations can include any operation and interaction with the storage medium of the host machine. Process and memory operations can include any operation of creating, terminating, modifying, querying, suspending and resuming processes, as well as memory management (e.g., allocating memory, creating a memory section, mapping/unmapping a memory section, writing/reading memory, etc). Registry operations can include any operation related to registry manipulation. And network operations can include any operation of sending or receiving data through network and network connection management.


The kernel related operations can be monitored by the Kernel Monitoring Module through different mechanisms, e.g., in accordance with different operating system platforms. For instance, for Mac OS X operating system, the kernel related operations can be monitored, by way of non-limiting example, by intercepting one or more system calls (in kernel space) that represent the corresponding operations. For the Windows operating system, kernel related operations can be monitored, by way of non-limiting example, by registering one or more kernel filter drivers for the kernel related operations via one or more callback functions. Windows operating system allows new drivers to be registered as part of the existing kernel stack, and thus information regarding a specific type of operation can be filtered by a corresponding kernel filter driver and passed through to the Kernel Monitoring Module via callback functions.


According to certain embodiments, OOB (Out-of-Band) monitoring approach can be adapted in the monitoring process (e.g., by the Kernel Monitoring Module). OOB enables the monitoring module to get notified on selected operations/events while not to have control over these operations/events, which allows the monitoring module to utilize different monitoring mechanisms (e.g., kernel callback functions) to accomplish a full system monitoring in an optimized manner. OOB also allows the events to be processed and analyzed into a stateful model in real time while the events are happening, as further described below.


According to certain embodiments, OOB can also enable the sequence of operations described with reference to FIG. 2, e.g., the monitoring operations, building stateful model, analyzing behaviors, determining malware and eliminating the determined malware, to be performed in the same machine, such as an end user station.


It is to be noted that the aforementioned categorized operations that are monitored respectively by different monitoring modules are provided for exemplary purposes only and should not be construed as limiting. For instance, in some cases one or more of the operations monitored by the In-process Monitoring Module can also be monitored by the Kernel Monitoring Module, and vice versa. According to one embodiment, at least one of the kernel related operations can be only monitored by the kernel Monitoring Module.


It should be noted that above mentioned examples of operations and implementations of the monitoring mechanisms are illustrated for exemplary purposes only. Additional kinds of operations and implementations can be applied in addition to or instead of the above.


It is also noted that the implementation mechanisms of the Kernel Monitoring Module can expedite system processing and enable the monitoring of the operations to be performed in a real time manner in a live environment.


According to certain embodiments, each monitored operation of the one or more operations constitutes an event. The Monitoring Module 104 can be further configured to generate event data characterizing one or more events. Optionally, an event data can be generated to characterize a respective event. According to certain embodiments, the event data can include at least the following attributes of the respective event: operation type, and source of the event.


Specifically, operation type is an identifier indicative of the type of the monitored operation that constitutes the event. The source of an event is the originating entity that performs the operation. Optionally, event data can include one or more additional attributes. For example, in some cases event data can include a target of an event, such as a targeting process, a targeting file, or any other entities that the operation is performed upon by the source of the event. In some further cases, event data can also include additional attributes according to different types of operations. For instance, event data that characterize file system operations can include additional attributes such as file permissions, full path of the file, size of the file, etc, while event data that characterize process and memory operations can include additional attributes such as address of the memory on which the operation is performed, size of the data that was written or read, memory permissions, etc.


Following step 202, at least one stateful model can be built (204) in accordance with the one or more operations, e.g., by the Event Parsing Module 106 of the Malware Detection System 100, as further described below in detail with respect to FIG. 3.


Attention is now directed to FIG. 3, illustrating a generalized flowchart of building a stateful model in accordance with certain embodiments of the presently disclosed subject matter. According to certain embodiments, the event data generated by the Monitoring Module 104 is created based on a large amount of raw data gathered through different routes, e.g., low level system calls and kernel driver callbacks, etc, thus the event data are generated in various forms. According to certain embodiments, this raw form of event data can be normalized (302) by the Event Parsing Module 106 into a logical data structure, giving rise to an abstract event which allows each segment of the attributes encoded in the event data to be accessed and analyzed. Specifically, the Event Parsing Module 106 can format the event data and parse the formatted event data in order to generate the abstract event. Through the event data normalization, event data indicative of similar operations but generated in various forms can also be normalized into a single format and categorized into the same event type. For example, various system API calls generated to allocate memory will be categorized into a single type of abstract event, e.g., a memory allocation event.


According to certain embodiments, the Event Parsing Module 106 can select event data associated with events of interest from all event data received from the Monitoring Module 104 based on one or more predefined filtering rules, and apply the normalization with respect to the selected event data. By way of non-limiting example, the one or more predefined filtering rules can include filtering out event data associated with the following events: uncompleted events, memory related events in which the targeting process is not a remote process, and events in which the targeting process does not exist.


Based on the generated abstract event, a stateful model can be created or updated. As aforementioned, a stateful model can be a logical structure representation of a sequence of linked operations performed in a live environment.


According to certain embodiments, for each event data that is normalized to an abstract event, one or more objects can be retrieved (304) from the abstract event. As aforementioned, each of the retrieved objects represents an entity related in a corresponding event, and each object can be of a type selected from a group that includes: process object, file object, network object, registry object, and windows object. At least one of the objects represents the source of the event that performs a corresponding operation. By way of non-limiting example, the source of the event can be represented by a process object indicating an originating process that performs the operation. For example, a process P1 performs an operation of “system shutdown”. In this case, a process object will be retrieved from the corresponding abstract event to represent P1 as the source of the event.


In some cases an operation is performed upon a target entity (i.e. target of the event) by the source of the event. For example, a process P1 opens a file F1. A process object will be retrieved from the corresponding abstract event to represent P1 as the source of the event for the operation “file open”, and a file object will be retrieved to represent F1 as the target of the event.


It is to be noted that an operation is usually initiated by a process. Thus the source of an event is normally represented by a process object. The target of the event, however, can be of various types of objects that are manipulated in the operation, such as a process object, file object, network object, registry object, etc.


According to further embodiments, a process can own resources, such as a source file that the process is initiated from. The source file can be of various types, such as, by way of non-limiting example, a document file, an image file that contains the executable program that the process is launched from, or any other relevant types of files. A source file, if related to an operation, can also be represented by a file object.


It is to be noted that the above mentioned object types are merely illustrated for exemplary purposes only and should not be construed as limiting the present disclosure in any way. Additional types of objects that may occur in an operation can be included in addition to or instead of the above.


Following retrieving the objects from an abstract event in step 304, the Event Parsing Module 106 can identify one or more relationships (306) among the objects in accordance with the abstract event, and generate respective associations among the objects corresponding to the identified relationships, giving rise to an event context corresponding to the abstract event. The event context contains context information of the corresponding event, and comprises the one or more objects of the event and the associations therein.


Following step 306, the Event Parsing Module 106 can further determine if a current event is a first event (308) of a stateful model, as described below in detail with respect to FIG. 4a. In case of the above condition being met, a new stateful model can be generated (310) and include the event context, namely, the one or more objects and the one or more associations therein. The process then goes back to step 302 wherein the next event data can be processed.


With reference now to FIG. 4a, there is shown an exemplified stateful model 400 being created based on an abstract event 401, in accordance with certain embodiments of the presently disclosed subject matter. Abstract event 401 is normalized from an event data characterizing an event E1 of a process P1 creating a child process P2. The abstract event 401 comprises the following attributes of the event: operation type—process creation; source of the event—P1 (as the originating process of the event), source file of P1-F1, target of the event—P2 (as a targeting process of the event), and source file of tP2-F2. Based on the abstract event 401, four objects can be retrieved: a process object 402 indicative of the source of the event P1, a process object 404 indicative of the target of the event P2, a file object 406 indicative of the source file F1 of P1, and a file object 408 indicative of the source file F2 of P2. According to certain embodiments, file objects 406 and 408 can be affiliated with, or correlated with, their respective process objects 402 and 404 as illustrated. The abstract data 401 can further include additional attributes which contain more information of the operation if applicable.


A relationship indicative of process creation can be identified between process objects 402 and 404 in accordance with the abstract event. A corresponding association between 402 and 404 can be generated accordingly based on the identified relationship, giving rise to an event context that comprises the process objects 402 and 404 (together with their correlated file objects 406 and 408) and the association therebetween. The association can be represented, e.g., as a direct linkage between the two related objects 402 and 404, as illustrated in FIG. 4a.


According to certain embodiments, one or more fields can be created for each of the objects, storing one or more parameters characterizing the respective object and the association related thereto. By way of non-limiting example, the process object 402 can have one or more fields selected from a group that includes: process identifier (e.g., a unique identifier assigned by the operating system for each process), one or more source file identifiers (e.g., a pointer to file object 406), and one or more operations and corresponding associations related thereto (e.g., an operation of process creation and a corresponding linkage to P2). The file object 406 can have one or more of fields selected from a group that includes: file identifier (e.g., the full path of the file), process identifier, and one or more operations and corresponding associations related thereto. Assume that E1 is a first event in a stateful model, a stateful model 400 can be generated and include the event context of E1.


It should be noted that the term “stateful model” should be expansively construed to include any of the following situations:

    • 1) A stateful model can be a program-level stateful model that represents a sequence of linked operations related to a given program (and in some cases, also operations related to one or more other programs that are linked to the given program due to operations). In this case, a stateful model represents a program context that reflects all the operations related to the given program by context.


A first event of the program-level stateful model can be determined to be any event that relates to the given program's first interaction with the system. For instance, a first event can be determined to be an event of “process creation” that creates the initiating process of the given program. An initiating process is the process that is created upon the given program being executed, which may also be the root process of a stateful model that performs further operations. A first event can also be determined to be an event performed by the initiating process upon other objects.


In the above example illustrated in FIG. 4a, if the originating process P1 is the initiating process of a certain program, the creation of P1 can be determined as the first event in the stateful model. Since the initiating process may be created by a system process P0, in some cases the stateful model can include P0, P1 and the association of process creation between P0 and P1. In some other cases the stateful model may include only the object P1, and a reference therewith indicating that P0 is the parent of P1. In some further cases a first event can also be determined as an event that P1 performs on other objects, for example, an event of “process creation” performed by P1 to create a child process P2.


In some circumstances events can be delayed to be processed by the Event Parsing Module 106 due to unexpected system processing problems. Thus a first event of the stateful model can also be an event that does not occur first in terms of time, but is first processed by the Event Parsing Module 106. Accordingly, following the above mentioned example of FIG. 4a, if a further event E2 of P2 opening a file F1 is first processed by the Event Parsing Module 106, the event E2 can be determined to be a first event of the stateful model, and any event that occurs before it (e.g., the event E1 of P1 creating P2) can be processed retroactively and reflected in the stateful model.


Thus, depending on the number of programs concurrently running in the live environment and the operational relationships among them, there may be one or more program stateful models co-existing, each of which represents a respective program context of a given program;

    • 2) A stateful model can be a system-level stateful model that represents operations related to all programs that run concurrently in a live environment. In this case a first event of the stateful model can be determined to be the event of “system start” that is initiated when the operating system initially starts. Accordingly, there is only one stateful model existing at any given time in the system which represents a system context of the entire environment. According to some embodiments, the system-level stateful model can be created upon the initialization of the operating system, and can be kept updating while the operating system and program processing proceeds. In accordance with further embodiments, the system-level stateful model may be created by including one or more program-level stateful models each related to one program of all the programs running in the live environment as described above.


It is to be noted that the definition and implementation of the above stateful model structure are illustrated for exemplary purposes only and should not be construed as limiting the present disclosure in any way. Alternative data structures can be applied to implement equivalent functionality of the stateful model in addition to or in lieu of the above.


Turning back to FIG. 3, according to certain embodiments, if the current event is not a first event of a stateful model (308), a previous stateful model corresponding to at least one previous event that precedes the current event exists. The Event Parsing Module 106 can update (312) the previous stateful model based on the event context of the current event, giving rise to an updated stateful model that is updated.


According to certain embodiments, a previous stateful model can be updated in accordance with the following scenarios:

    • 1) If all the objects of the current event are already included in the previous stateful model, the one or more associations of the event context can be added to the previous stateful model, giving rise to the updated stateful model;
    • 2) Otherwise at least one object of the one or more objects should be a new object that does not exist in the previous stateful model. Thus the new object, together with the one or more associations, can be added to the previous stateful model, giving rise to the updated stateful model.


Continuing with the example illustrated in FIG. 4a, assume that the illustrated stateful model 400 (including process objects P1, P2 and the association between P1 and P2 representing the event E1 of P1 creating P2) is a previous stateful model that exists, and a current event E2 arrives, wherein the same process P1 allocates memory in the same child process P2. Following the process in FIG. 3, the event data that characterizes the current event E2 is normalized to an abstract event. Objects P1 and P2 are retrieved based on the abstract event. A relationship indicative of memory allocation can be identified between P1 and P2 based on the abstract event, and an association between P1 and P2 can be generated based on the identified relationship. Thus an event context for the current event E2 comprises objects P1 and P2 and the association therebetween. Since the current event E2 is not a first event in the previous stateful model 400, the stateful model 400 will be updated based on the current event context. In this case, since all the objects of the current event, namely, P1 and P2, are already included in the previous stateful model 400, the currently generated association between P1 and P2 representing an operation of memory allocation, will be added as a new association between P1 and P2 in the stateful model 400, besides the previous association therebetween representing the operation of process creation, giving rise to an updated stateful model. By way of non-limiting example, the new association can be added in the stateful model by adding a respective field for P1 and/or P2 to indicate the operation of memory allocation therebetween. Since only the association has been updated, the hierarchical structure of the updated stateful model may look similar as illustrated in FIG. 4a, with a newly added association.


Continuing with the same example, assume that another event E3 arrives after E2, wherein the process P2 creates a child process P3. Following the same process in FIG. 3, the event data that characterizes the current event E3 is normalized to an abstract event. Objects P2 and P3 are retrieved based on the abstract event. A relationship indicative of process creation can be identified between P2 and P3 based on the abstract event, and an association between P2 and P3 can be generated based on the identified relationship. Thus an event context for the current event E3 comprises objects P2 and P3 and the association therebetween. Since the current event E3 is not the first event in the stateful model 400, the stateful model 400 will be updated based on the current event context. In this case, since P3 is a new object that does not exist in the previous stateful model, the new object P3 can be added to the stateful model 400 as a process object 410. Optionally a file object F3 that is correlated with P3 can also be added as a file object 412. The association between P2 and the new object P3 can be added in the stateful model, by way of non-limiting example, by adding a respective field for P2 and/or P3 to indicate the operation of process creation therebetween, giving rise to an updated stateful model, as illustrated in FIG. 4b.


It is to be noted that the specific examples of building and updating the stateful model illustrated above are provided for exemplary purposes only and should not be construed as limiting. Accordingly, other ways of implementation of building and updating the stateful model can be used in addition to or in lieu of the above.


It should also be noted that the present disclosure is not bound by the specific sequence of operation steps described with reference to FIG. 3.


Having described the structure of the stateful model and the process of building/updating the stateful model in accordance with certain embodiments, attention is now drawn back to FIG. 2, wherein analyzing at least one stateful model in order to identify one or more behaviors is now described with reference to step 206.


According to certain embodiments, the Behavior Analyzing Module 110 can be further configured to analyze the event context of the current event in view of the stateful model (when the stateful model is newly created based on the current event) or the updated stateful model (when the stateful model is updated based on the current event), in accordance with one or more predefined behavioral logics.


The Behavior Analyzing Module 110 can further determine the presence of at least one behavior upon any of the one or more predefined behavioral logics being met. The determined behavior relates to a sequence of events of the stateful model including at least the current event. In some cases, each of the sequence of events independently may not be identified as malicious, but when considered within the sequence context, is actually performing a malicious behavior. By analyzing the event context in view of the stateful model, the Behavior Analyzing Module can inspect a specific event while looking at the whole picture, thus avoiding omission of undetected malwares.


According to certain embodiments, the predefined behavioral logics are behavioral signatures indicative of specific behavioral patterns. The behavioral logics can be predefined based on prior knowledge of certain malware behaviors, such as, for instance, self-deletion, self-execution, and code injection, etc. The behavioral logics can be stored in a Behavioral Signature Database 112 as aforementioned with respect to FIG. 1. One of the predefined behavioral logics can be, by way of non-limiting example, determining a behavior of self-execution when the following condition is met: the target of an event is an object that is already included in the stateful model, which indicates that the operation is performed on one of the family's own members. For example, a targeting process of an event is identical to one of the following: the originating process, a child process of the originating process, and a parent process of the originating process. Another similar exemplary behavioral logic can be, for instance, determining a behavior of self-deletion when the following condition is met: the target of a deletion event is an object included in the stateful model. For example, the source file of a targeting process of an event is identical to one of the following: the source file of the originating process, and the source file of a parent process of the originating process.


Optionally, the predefined behavioral logics can also include one or more logics indicative of benign behavior patterns such as, for example, interaction with the desktop or users, registration in the system program repository, etc. According to certain embodiments, each behavioral signature in the database can be associated with a predefined behavioral score that indicates the malicious level of a corresponding behavior. Accordingly each of the determined at least one behavior can be assigned with a respective behavioral score based on the predefined behavioral score associated therewith. The process of analyzing a stateful model and determining at least one behavior is further exemplified with reference to FIG. 5.


It is to be noted that the hierarchical structure of the stateful model as described above is designed as a fast accessible data structure, which can in turn enable the creating of the stateful model and analyzing the created stateful model, following the monitoring of the operations, to be performed in a real time manner in a live environment.


Upon the at least one behavior being determined, the Decision Making Module 114 can be configured to determine the presence of malware (208) based on the determined behavior. According to certain embodiments, each stateful model can be associated with a stateful model score. The stateful model score is an aggregated behavioral score of all behavioral scores assigned for respective behaviors being determined in the stateful model. Upon at least one current behavior being determined in a stateful model, the Decision Making Module 114 can search if there is a previous stateful model score associated with a previous stateful model. Accordingly, the previous stateful model score is an aggregated behavioral score of all previous behavioral scores assigned for respective previous determined behaviors, the previous determined behaviors being related to the at least one previous event of the previous stateful model. If there is no previous stateful model score, the sum of the respective behavioral score for each of the at least one behavior can be determined as the stateful model score associated with the current stateful model. Otherwise, if there is found a previous stateful model score, the previous stateful model score can be increased with the sum, giving rise to the stateful model score that has been updated based on the current event. The Decision Making Module 114 can be further configured to compare the stateful model score with a predefined threshold. The predefined threshold can be a score indicative of malware presence and can be predetermined based on prior knowledge of malware detection. If the stateful model score passes the predefined threshold, a presence of malware can be determined. For example, the corresponding stateful model, and one or more programs that relate to the stateful model can be determined as malicious. The process of determining the presence of malware is further exemplified with reference to FIG. 5.


According to certain embodiments, the respective behavioral score of a currently determined behavior can be assigned with a corresponding weight factor if a condition is met. The condition can be, by way of non-limiting example, that the source of an event is a remote process and the target of the event is a system process, indicating that a remote process is performing operations on a system process. In this case a weight factor (e.g., a numerical value greater than 1) can be assigned to the original behavioral score associated with this behavior, indicating an increasing likelihood of malware presence. The assigned weight factor can be applied to the original behavioral score (e.g., by multiplying the original behavioral score with the weight factor), giving rise to a weighted behavioral score. Accordingly the previous stateful model score can be increased with a sum of the weighted behavioral score assigned for each of the at least one behavior.


It is to be noted that the present disclosure is not bound by the specific scoring and weighting paradigms described above. The scoring and weighting functionalities can be implemented in a consolidated manner or separately. Additional kinds of implementations can be applied in addition or instead of the above.


According to certain embodiments, the determined malware can be eliminated by remediating the operations indicated in the stateful model, such as, by way of non-limiting example, by terminating the process objects within the stateful model, removing the file objects (or other types of objects) correlated with or created by the process objects, and undo the operations performed among the objects if possible, in order to restore the system to a state as close as possible to the system state before the operations in the stateful model were executed. According to further embodiments, an output of the determined malware can be provided through the I/O Interface 103 to the end users, as aforementioned.


According to certain embodiments, the sequence of operations described with reference to FIG. 2, e.g., the monitoring operations, building stateful model, analyzing behaviors, determining malware and eliminating the determined malware, can be carried out concurrently in real time. For instance, building at least one stateful model in accordance with the one or more operations responsive to monitoring the one or more operations of at least one program concurrently running in a live environment can be performed in real time. Additionally or alternatively, analyzing the at least one stateful model to identify one or more behaviors responsive to monitoring the one or more operations and building the at least one stateful model can be performed in real time. Additionally or alternatively, determining the presence of malware based on the identified one or more behaviors responsive to analyzing the at least one stateful model can be performed in real time. Additionally or alternatively, eliminating the determined malware responsive to determining the presence of malware can be performed in real time.


It is to be noted that the present disclosure is not bound by the specific sequence of operation steps described with reference to FIG. 2.


Turning now to FIG. 5, there is shown a generalized flowchart of an exemplified sequence of operations being monitored and processed in accordance with certain embodiments of the presently disclosed subject matter.


As shown, a process P1 is created (501) upon a given program being executed. Thus P1 is the initiating process of the given program. The operation of process creation is monitored, e.g., by the kernel monitoring module. A corresponding event E1 and event data thereof are generated accordingly. E1 is determined to be the first event of a stateful model, and the stateful model is generated based on E1. The stateful model will now include an event context of E1, namely, P1 (optionally, also a system process P0 that creates P1, and/or the source file F1 of P1), together with an association of process creation of P1. No behavior is determined (502) at this stage in accordance with the predefined behavioral logics, and, accordingly no score is assigned.


A second operation of P1 allocating memory to a system process P2 (503) occurs. The operation of memory allocation is monitored, e.g., by the in-process monitoring module. A corresponding event E2 and event data thereof are generated accordingly. Since E2 is not the first event of a stateful model, the previous stateful model comprising event context E1 is updated based on E2. The stateful model now includes P1, P2 (optionally also their source files F1 and F2) together with an association of memory allocation between P1 and P2. A behavior of remote memory allocation is determined (504) in accordance with one of the predefined behavioral logics, and accordingly a behavioral score S1 is assigned. Since there is no previous stateful model score, the behavioral score S1 is also the stateful model score.


Following the second operation, a third operation of P1 injecting code (505) in the allocated memory in P2 occurs. According to certain embodiments, the operation of code injection can comprise three actions: memory write, memory execution permissions, and code execution, all of which are monitored. A corresponding event E3 and event data thereof are generated accordingly. Since E3 is not the first event of a stateful model, the previous stateful model based on event context of E1 and E2 are further updated based on the current event E3. The stateful model now includes P1, P2 (optionally also their source files F1 and F2), a previous association of memory allocation between P1 and P2, and a new association of code injection between P1 and P2. A behavior of code injection is determined (506) in accordance with one of the predefined behavioral logics, and accordingly a behavioral score S2 is assigned. The stateful model score is updated to be the sum of S1 and S2.


A fourth operation of P2 deleting P1's file F1 (507) follows the third operation. The operation of file deletion is monitored. A corresponding event E4 and event data thereof are generated accordingly. Since E4 is not the first event of a stateful model, the previous stateful model based on previous events E1, E2 and E3 are now updated based on E4. The present stateful model includes P1, P2, F1 (optionally also source file F2), two associations (i.e. memory allocation, and code injection) between P1 and P2, and a new association of file deletion between P2 and F1. Based on analyzing the stateful model, it is noted that P1 is actually the parent of P2. A behavior of self-deletion is determined (508) in accordance with one of the predefined behavioral logics, and a behavioral score S3 is assigned. Now the stateful model score is updated to be the sum of S1, S2 and S3. If the stateful model score passes a predefined threshold, the presence of malware is determined. For example, the stateful model, especially the given program that is related to P1 is determined to be malicious, and will be eliminated (509). For instance, the process objects P1 and P2 are terminated, the file objects F1 and F2 are removed, and the relevant operations between P1 and P2, such as memory allocation, code injection, file deletion etc, can be remediated if possible.


It is to be noted that the specific examples illustrated above with reference to FIG. 5 are provided for exemplary purposes only and should not be construed as limiting the present disclosure in any way.


It is to be understood that the presently disclosed subject matter is not limited in its application to the details set forth in the description contained herein or illustrated in the drawings. The presently disclosed subject matter is capable of other embodiments and of being practiced and carried out in various ways. Hence, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. As such, those skilled in the art will appreciate that the conception upon which this disclosure is based can readily be utilized as a basis for designing other structures, methods, and systems for carrying out the several purposes of the present presently disclosed subject matter.


It will also be understood that the system according to the presently disclosed subject matter can be implemented, at least partly, as a suitably programmed computer. Likewise, the presently disclosed subject matter contemplates a computer program being readable by a computer for executing the disclosed method. The presently disclosed subject matter further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the disclosed method.

Claims
  • 1. A computer-implemented method of performing a behavior-based analysis of an execution of a program in an operating system, the method comprising: monitoring, by a computer system, by registering one or more kernel filter drivers for kernel space operations via one or more call back functions using an out-of-band monitoring module, one or more operations performed by the execution of the program running in the operating system in a live environment, wherein the monitoring comprises tracking user space operations and the kernel space operations;generating, by the computer system, an event data for each of the one or more monitored operations;normalizing the event data into a logical data structure such that attributes of the event data can accessed and analyzed;building, by the computer system, at least one stateful model of the execution of the program based on the normalized event data, the at least one stateful model comprising a hierarchal structure of the one or more monitored operations performed by the execution of the program in the live environment, the one or more monitored operations linked by an event context, wherein the hierarchal structure comprises: the event context comprising: one or more objects derived from the one or more monitored operations;one or more fields generated for each of the one or more objects, the one or more fields storing one or more parameters characterizing a respective object of the one or more objects and an associate to the respective object; andone or more relationships identified among the one or more objects; andattributes characterizing the one or more objects and the one or more relationships among the one or more objects, wherein the attributes comprise at least a type of the one or more monitored operations and a source of the one or more events;analyzing, by the computer system, the event context to identify one or more behaviors of the execution of the program related to the one or more events; andapplying a score to the stateful model based on the one or more identified behaviors, wherein applying the score to the stateful model comprises: determining a weighted behavior score for each of the one or more identified behaviors, wherein the weighted behavior score indicates a likelihood of the presence of malware based on the one or more identified behaviors;determining the score by computing a sum of the weighted behavior scores for each of the one or more identified behaviors; andcomparing the one or more identified behaviors and the score to one or more pre-existing behaviors and a pre-existing score of a pre-existing stateful model.
  • 2. The computer-implemented method of claim 1, further comprising updating, in real time, the at least one stateful model in response to one or more new events.
  • 3. The computer-implemented method of claim 1, further comprising outputting, via an output device of the computer system, a representation of the one or more identified behaviors of the execution of the program.
  • 4. The computer-implemented method of claim 1, further comprising storing the one or more identified behaviors of the execution of the program in a behavioral profile database.
  • 5. The computer-implemented method of claim 1, wherein the computer system comprises a cloud-based computer system.
  • 6. The computer-implemented method of claim 1, wherein the computer system comprises one or more functional components distributed over more than one computer.
  • 7. The computer-implemented method of claim 1, wherein the live environment comprises one or more programs, including the program, operating concurrently and interactively for their intended uses.
  • 8. The computer-implemented method of claim 1, further comprising aggregating the one or more identified behaviors.
  • 9. The computer-implemented method of claim 1, wherein the one or more behaviors comprise a representation of a behavior pattern of the execution of the program.
  • 10. The computer-implemented method of claim 1, further comprising analyzing the one or more behaviors to determine if the execution of the program comprises malware.
  • 11. A system for performing a behavior-based analysis of an execution of a program in an operating system, the system comprising: one or more computer readable storage devices configured to store a plurality of computer executable instructions; andone or more hardware computer processors in communication with the one or more computer readable storage devices and configured to execute the plurality of computer executable instructions in order to cause the system to: monitor, by registering one or more kernel filter drivers for kernel space operations via one or more call back functions using an out-of-band monitoring module, one or more operations performed by the execution of the program running in the operating system in a live environment, wherein monitoring comprises tracking user space operations and the kernel space operations;generate an event data for each of the one or more operations of interest, wherein the event data characterizes one or more events of the one or more monitored operations;normalize the event data into a logical data structure such that attributes of the event data can accessed and analyzed;build at least one stateful model of the execution of the program based on the normalized event data, the at least one stateful model comprising a hierarchal structure of the one or more monitored operations by the execution of the program in the live environment, the one or more monitored operations linked by an event context, wherein the at least one stateful model comprises: the event context comprising: one or more objects derived from the one or more monitored operations;one or more fields generated for each of the one or more objects, the one or more fields storing one or more parameters characterizing a respective object of the one or more objects and an associate to the respective object; andone or more relationships identified among the one or more objects; andattributes characterizing the one or more objects and the one or more relationships among the one or more objects, wherein the attributes comprise at least a type of the one or more monitored operations and a source of the one or more events;analyze the event context to identify one or more behaviors of the execution of the program related to the one or more events; andapply a score to the stateful model based on the one or more identified behaviors, wherein applying the score to the stateful model comprises: determining a weighted behavior score for each of the one or more identified behaviors, wherein the weighted behavior score indicates a likelihood of the presence of malware based on the one or more identified behaviors; anddetermining the score by computing a sum of the weighted behavior scores for each of the one or more identified behaviors; andcompare the one or more identified behaviors and the score to one or more pre-existing behaviors and a pre-existing score of a pre-existing stateful model.
  • 12. The system of claim 11, wherein the system is further caused to update, in real time, the at least one stateful model in response to one or more new events.
  • 13. The system of claim 11, wherein the system is further caused to output, via an output device of the system, a representation of the one of more behaviors of the execution of the program.
  • 14. The system of claim 11, wherein the system is further caused to store the one or more behaviors of the execution of the program in a behavioral profile database.
  • 15. The system of claim 11, wherein the system comprises a cloud-based computer system.
  • 16. The system of claim 11, wherein the system comprises one or more functional components distributed over more than one computer.
  • 17. The system of claim 11, wherein the live environment comprises one or more programs, including the program, operating for concurrently and interactively for their intended uses.
  • 18. The system of claim 11, wherein the system is further caused to aggregate the one or more identified behaviors.
  • 19. The system of claim 11, wherein the one or more behaviors comprise a representation of a behavior pattern of the execution of the program.
  • 20. The system of claim 11, wherein the system is further caused to analyze the one or more behaviors to determine if the execution of the program comprises malware.
US Referenced Citations (494)
Number Name Date Kind
4979118 Kheradpir Dec 1990 A
5311593 Carmi May 1994 A
6154844 Touboul et al. Nov 2000 A
6157953 Chang et al. Dec 2000 A
6728716 Bhattacharya et al. Apr 2004 B1
6804780 Touboul Oct 2004 B1
6836888 Basu et al. Dec 2004 B1
7076696 Stringer Jul 2006 B1
7093239 van der Made Aug 2006 B1
7181769 Keanini et al. Feb 2007 B1
7225468 Waisman et al. May 2007 B2
7299294 Bruck et al. Nov 2007 B1
7305546 Miller Dec 2007 B1
7322044 Hrastar Jan 2008 B2
7464407 Nakae et al. Dec 2008 B2
7530106 Zaitsev et al. May 2009 B1
7543269 Krueger Jun 2009 B2
7546587 Marr et al. Jun 2009 B2
7574740 Kennis Aug 2009 B1
7596807 Ptacek et al. Sep 2009 B2
7596808 Wilkinson et al. Sep 2009 B1
7710933 Sundaralingam et al. May 2010 B1
7739516 Bender et al. Jun 2010 B2
7832012 Huddleston Nov 2010 B2
7882538 Palmer Feb 2011 B1
7890612 Todd et al. Feb 2011 B2
7937755 Guruswamy May 2011 B1
7984129 Vaught Jul 2011 B2
8015605 Yegneswaran Sep 2011 B2
8024795 Newton Sep 2011 B2
8042186 Polyakov et al. Oct 2011 B1
8065722 Barford et al. Nov 2011 B2
8078556 Adi et al. Dec 2011 B2
8082471 Khan Dec 2011 B2
8131281 Hildner et al. Mar 2012 B1
8141154 Gruzman et al. Mar 2012 B2
8156556 Krishnamurthy Apr 2012 B2
8171545 Cooley et al. May 2012 B1
8181033 Paul et al. May 2012 B1
8181250 Rafalovich et al. May 2012 B2
8204984 Aziz Jun 2012 B1
8205035 Reddy et al. Jun 2012 B2
8230505 Ahrens et al. Jul 2012 B1
8296842 Singh et al. Oct 2012 B2
8327442 Herz et al. Dec 2012 B2
8353033 Chen et al. Jan 2013 B1
8370931 Chien et al. Feb 2013 B1
8375444 Aziz et al. Feb 2013 B2
8375447 Amoroso et al. Feb 2013 B2
8413238 Sutton Apr 2013 B1
8413241 Weeks et al. Apr 2013 B2
8418250 Morris et al. Apr 2013 B2
8438386 Hegli et al. May 2013 B2
8438626 Anderson et al. May 2013 B2
8443442 Wang et al. May 2013 B2
8474044 Zawadowskiy et al. Jun 2013 B2
8488466 Breslin et al. Jul 2013 B2
8528057 Garrett Sep 2013 B1
8528087 Hsu et al. Sep 2013 B2
8538578 Battles et al. Sep 2013 B2
8539582 Aziz et al. Sep 2013 B1
8549643 Shou Oct 2013 B1
8555385 Bhatkar et al. Oct 2013 B1
8561177 Aziz et al. Oct 2013 B1
8566946 Aziz et al. Oct 2013 B1
8607054 Ramarathinam et al. Dec 2013 B2
8607340 Wright Dec 2013 B2
8627475 Loveland et al. Jan 2014 B2
8677494 Edery et al. Mar 2014 B2
8713306 Bennett Apr 2014 B1
8719937 Sundaram et al. May 2014 B2
8725898 Vincent May 2014 B1
8726389 Morris et al. May 2014 B2
8732296 Thomas et al. May 2014 B1
8752173 Yadav Jun 2014 B2
8789135 Pani Jul 2014 B1
8793151 Delzoppo et al. Jul 2014 B2
8821242 Hinman et al. Sep 2014 B2
8839369 Dai et al. Sep 2014 B1
8849880 Thelen Sep 2014 B2
8850582 Endoh et al. Sep 2014 B2
8880435 Catlett et al. Nov 2014 B1
8881282 Aziz et al. Nov 2014 B1
8893278 Chechik Nov 2014 B1
8898788 Aziz et al. Nov 2014 B1
8904527 Dawson et al. Dec 2014 B2
8943594 Arrowood Jan 2015 B1
8949986 Ben-Shalom Feb 2015 B2
8959338 Snow et al. Feb 2015 B2
8973142 Shulman et al. Mar 2015 B2
8984637 Karecha et al. Mar 2015 B2
9009829 Stolfo et al. Apr 2015 B2
9027135 Aziz May 2015 B1
9043920 Gula et al. May 2015 B2
9081747 Tabieros et al. Jul 2015 B1
9117078 Chien et al. Aug 2015 B1
9141792 Baluda et al. Sep 2015 B2
9166993 Liu Oct 2015 B1
9185136 Dulkin et al. Nov 2015 B2
9195480 Wang et al. Nov 2015 B2
9197601 Pasdar Nov 2015 B2
9213838 Lu Dec 2015 B2
9225734 Hastings Dec 2015 B1
9240976 Murchison Jan 2016 B1
9246774 Mataitis et al. Jan 2016 B2
9270690 Kraitsman et al. Feb 2016 B2
9305165 Snow et al. Apr 2016 B2
9329973 Bhuyan May 2016 B2
9330259 Klein et al. May 2016 B2
9356942 Joffe May 2016 B1
9356950 Vissamsetty et al. May 2016 B2
9369476 Chekina et al. Jun 2016 B2
9386034 Cochenour Jul 2016 B2
9398001 Tidd Jul 2016 B1
9407602 Feghali et al. Jul 2016 B2
9413721 Morris et al. Aug 2016 B2
9430646 Mushtaq et al. Aug 2016 B1
9432360 Triandopoulos et al. Aug 2016 B1
9438614 Herz Sep 2016 B2
9495188 Ettema et al. Nov 2016 B1
9503470 Gertner et al. Nov 2016 B2
9547516 Thakkar et al. Jan 2017 B2
9578045 Jaroch et al. Feb 2017 B2
9591006 Siva et al. Mar 2017 B2
9601000 Gruss et al. Mar 2017 B1
9602531 Wallace et al. Mar 2017 B1
9606893 Gupta et al. Mar 2017 B2
9607146 Sridhara et al. Mar 2017 B2
9609019 Vissamsetty et al. Mar 2017 B2
9628498 Aziz et al. Apr 2017 B1
9641544 Treat et al. May 2017 B1
9641550 Kraitsman et al. May 2017 B2
9705904 Davis et al. Jul 2017 B1
9710648 Weingarten Jul 2017 B2
9712547 Touboul et al. Jul 2017 B2
9769204 Vissamsetty et al. Aug 2017 B2
9772832 Rubio Sep 2017 B2
9781148 Mahaffey et al. Oct 2017 B2
9807092 Gutzmann Oct 2017 B1
9807115 Kolton et al. Oct 2017 B2
9813451 Honda et al. Nov 2017 B2
9871766 Syed et al. Jan 2018 B2
9877210 Hildner et al. Jan 2018 B1
9888032 Dekel et al. Feb 2018 B2
9898763 Vaynblat et al. Feb 2018 B1
9942270 Vissamsetty et al. Mar 2018 B2
10025928 Jaroch et al. Jul 2018 B2
10044675 Ettema et al. Aug 2018 B1
10102374 Cohen et al. Oct 2018 B1
10169586 Maciejak et al. Jan 2019 B2
10237282 Nelson et al. Mar 2019 B2
10250636 Vissamsetty et al. Apr 2019 B2
10257224 Jaroch et al. Apr 2019 B2
10284591 Giuliani et al. May 2019 B2
10375110 Vissamsetty et al. Jul 2019 B2
10382484 Shayevitz et al. Aug 2019 B2
10476891 Vissamsetty et al. Nov 2019 B2
10509905 Vissamsetty et al. Dec 2019 B2
10542044 Vissamsetty et al. Jan 2020 B2
10567431 Vissamsetty et al. Jan 2020 B2
10574698 Sharifi Feb 2020 B1
10599842 Vissamsetty et al. Mar 2020 B2
10599844 Schmidtler et al. Mar 2020 B2
10609074 Vissamsetty et al. Mar 2020 B2
10757090 Kahol et al. Aug 2020 B2
10826941 Jain et al. Nov 2020 B2
10855671 Kahol et al. Dec 2020 B2
10938854 Strogov et al. Mar 2021 B2
11032301 Mandrychenko et al. Jun 2021 B2
11038658 Vissamsetty et al. Jun 2021 B2
11171974 Gertner et al. Nov 2021 B2
11470115 Vissamsetty et al. Oct 2022 B2
11507663 Cohen et al. Nov 2022 B2
11522894 Weingarten et al. Dec 2022 B2
11579857 Montag et al. Feb 2023 B2
11580218 Enfinger Feb 2023 B2
20020010800 Riley et al. Jan 2002 A1
20020016826 Johansson et al. Feb 2002 A1
20020078382 Sheikh et al. Jun 2002 A1
20020093917 Knobbe et al. Jul 2002 A1
20020095607 Lin-Hendel Jul 2002 A1
20020178374 Swimmer et al. Nov 2002 A1
20020194489 Almogy et al. Dec 2002 A1
20030065950 Yarborough Apr 2003 A1
20030145225 Bruton, III et al. Jul 2003 A1
20030145226 Bruton, III et al. Jul 2003 A1
20030152034 Zhang et al. Aug 2003 A1
20030188189 Desai et al. Oct 2003 A1
20030223367 Shay et al. Dec 2003 A1
20040083369 Erlingsson et al. Apr 2004 A1
20040172557 Nakae et al. Sep 2004 A1
20040243699 Koclanes et al. Dec 2004 A1
20040255157 Ghanea-Hercock Dec 2004 A1
20050050353 Thiele et al. Mar 2005 A1
20050076235 Ormazabal et al. Apr 2005 A1
20050076238 Ormazabal et al. Apr 2005 A1
20050108562 Khazan et al. May 2005 A1
20050138402 Yoon et al. Jun 2005 A1
20050204157 Johnson Sep 2005 A1
20050223239 Dotan Oct 2005 A1
20050240989 Kim et al. Oct 2005 A1
20060053490 Herz et al. Mar 2006 A1
20060085543 Hrastar Apr 2006 A1
20060101515 Amoroso et al. May 2006 A1
20060126522 Oh Jun 2006 A1
20060161989 Reshef et al. Jul 2006 A1
20060203774 Carrion-Rodrigo Sep 2006 A1
20060209701 Zhang et al. Sep 2006 A1
20060230129 Swami et al. Oct 2006 A1
20060236401 Fosdick Oct 2006 A1
20070022090 Graham Jan 2007 A1
20070025374 Stefan et al. Feb 2007 A1
20070067623 Ward Mar 2007 A1
20070097976 Wood et al. May 2007 A1
20070100905 Masters et al. May 2007 A1
20070101431 Clift et al. May 2007 A1
20070115993 Cohen May 2007 A1
20070143827 Nicodemus et al. Jun 2007 A1
20070143851 Nicodemus et al. Jun 2007 A1
20070177499 Gavrilescu et al. Aug 2007 A1
20070208822 Wang et al. Sep 2007 A1
20070208936 Ramos Sep 2007 A1
20070209070 Yadav Sep 2007 A1
20070226320 Hager et al. Sep 2007 A1
20070240215 Flores et al. Oct 2007 A1
20070250930 Aziz et al. Oct 2007 A1
20070282782 Carey et al. Dec 2007 A1
20080005782 Aziz Jan 2008 A1
20080018927 Martin et al. Jan 2008 A1
20080022000 Furuya et al. Jan 2008 A1
20080034429 Schneider Feb 2008 A1
20080046989 Wahl Feb 2008 A1
20080060074 Okuyama Mar 2008 A1
20080071728 Lim Mar 2008 A1
20080082722 Savagaonkar et al. Apr 2008 A1
20080083034 Kim et al. Apr 2008 A1
20080098476 Syversen Apr 2008 A1
20080104046 Singla et al. May 2008 A1
20080127346 Oh et al. May 2008 A1
20080162397 Zaltzman Jul 2008 A1
20080168559 Touitou et al. Jul 2008 A1
20080170566 Akimoto Jul 2008 A1
20080229415 Kapoor et al. Sep 2008 A1
20090077664 Hsu et al. Mar 2009 A1
20090089040 Monastyrsky et al. Apr 2009 A1
20090104046 Martin et al. Apr 2009 A1
20090158407 Nicodemus et al. Jun 2009 A1
20090158418 Rao et al. Jun 2009 A1
20090170566 Kwon et al. Jul 2009 A1
20090199296 Xie et al. Aug 2009 A1
20090241173 Troyansky Sep 2009 A1
20090249466 Motil et al. Oct 2009 A1
20090249470 Litvin et al. Oct 2009 A1
20090254973 Kwan Oct 2009 A1
20090288158 Izatt et al. Nov 2009 A1
20090296641 Bienas et al. Dec 2009 A1
20090327688 Li et al. Dec 2009 A1
20090328196 Bovee Dec 2009 A1
20100005339 Hooks Jan 2010 A1
20100077483 Stolfo et al. Mar 2010 A1
20100122317 Yadav May 2010 A1
20100122343 Ghosh et al. May 2010 A1
20100169973 Kim et al. Jul 2010 A1
20100269175 Stolfo et al. Oct 2010 A1
20100293615 Ye Nov 2010 A1
20100299430 Powers et al. Nov 2010 A1
20110023118 Wright et al. Jan 2011 A1
20110067107 Weeks et al. Mar 2011 A1
20110078309 Bloch Mar 2011 A1
20110099633 Aziz Apr 2011 A1
20110113427 Dotan May 2011 A1
20110138456 Ormazabal et al. Jun 2011 A1
20110141937 Breslin et al. Jun 2011 A1
20110145920 Mahaffey et al. Jun 2011 A1
20110167494 Bowen Jul 2011 A1
20110178930 Scheidt et al. Jul 2011 A1
20110185430 Sallam Jul 2011 A1
20110214176 Burch et al. Sep 2011 A1
20110214182 Adams et al. Sep 2011 A1
20110219443 Hampel Sep 2011 A1
20110219449 St. Neitzel Sep 2011 A1
20110247071 Hooks et al. Oct 2011 A1
20110271341 Satish et al. Nov 2011 A1
20110288940 Hordan et al. Nov 2011 A1
20120023572 William, Jr. et al. Jan 2012 A1
20120030745 Bauer Feb 2012 A1
20120030750 Bhargava et al. Feb 2012 A1
20120079596 Thomas et al. Mar 2012 A1
20120084866 Stolfo Apr 2012 A1
20120106377 Sommers et al. May 2012 A1
20120124363 Dietrich et al. May 2012 A1
20120137342 Hartrell et al. May 2012 A1
20120137367 Dupont et al. May 2012 A1
20120144488 Sankruthi Jun 2012 A1
20120151565 Fiterman Jun 2012 A1
20120185563 Sugiyama et al. Jul 2012 A1
20120240182 Marayanaswamy et al. Sep 2012 A1
20120255003 Sallam Oct 2012 A1
20120255004 Sallam Oct 2012 A1
20120291090 Srinivasan et al. Nov 2012 A1
20120297488 Kapoor et al. Nov 2012 A1
20120324094 Wyatt et al. Dec 2012 A1
20120331553 Aziz et al. Dec 2012 A1
20130052992 Lee et al. Feb 2013 A1
20130054682 Malik et al. Feb 2013 A1
20130061097 Mendel et al. Mar 2013 A1
20130080641 Lui et al. Mar 2013 A1
20130086684 Mohler Apr 2013 A1
20130091573 Herz et al. Apr 2013 A1
20130097706 Titonis et al. Apr 2013 A1
20130111547 Kraemer May 2013 A1
20130133072 Kraitsman et al. May 2013 A1
20130152200 Alme et al. Jun 2013 A1
20130167236 Sick Jun 2013 A1
20130191924 Tedesco et al. Jul 2013 A1
20130212658 Amaya et al. Aug 2013 A1
20130219217 Seren et al. Aug 2013 A1
20130231084 Raleigh Sep 2013 A1
20130242743 Thomas et al. Sep 2013 A1
20130247190 Spurlock Sep 2013 A1
20130290662 Teal Oct 2013 A1
20130290729 Pettigrew et al. Oct 2013 A1
20130291111 Zhou et al. Oct 2013 A1
20130298192 Kumar et al. Nov 2013 A1
20130298244 Kumar et al. Nov 2013 A1
20130305377 Herz Nov 2013 A1
20130329732 Vyas et al. Dec 2013 A1
20130333040 Diehl et al. Dec 2013 A1
20130340033 Jones et al. Dec 2013 A1
20130346472 Wheeldon Dec 2013 A1
20130347052 Choudrie Dec 2013 A1
20140046645 White et al. Feb 2014 A1
20140053267 Klein et al. Feb 2014 A1
20140068326 Quinn Mar 2014 A1
20140068779 Tan et al. Mar 2014 A1
20140090061 Avasarala et al. Mar 2014 A1
20140096229 Burns et al. Apr 2014 A1
20140108794 Barton et al. Apr 2014 A1
20140123280 Kedma May 2014 A1
20140137246 Baluda May 2014 A1
20140150094 Rao et al. May 2014 A1
20140157366 Ko et al. Jun 2014 A1
20140165203 Friedrichs et al. Jun 2014 A1
20140215617 Smith et al. Jul 2014 A1
20140215621 Xaypanya et al. Jul 2014 A1
20140215625 Paul et al. Jul 2014 A1
20140237562 Nandakumar Aug 2014 A1
20140237595 Sridhara et al. Aug 2014 A1
20140237599 Gertner et al. Aug 2014 A1
20140245376 Hibbert et al. Aug 2014 A1
20140250524 Meyers et al. Sep 2014 A1
20140259092 Boucher et al. Sep 2014 A1
20140282816 Xie et al. Sep 2014 A1
20140283076 Muttik Sep 2014 A1
20140289851 Klein et al. Sep 2014 A1
20140298419 Boubez et al. Oct 2014 A1
20140349611 Kant et al. Nov 2014 A1
20150006384 Shaikh Jan 2015 A1
20150007312 Pidathala et al. Jan 2015 A1
20150013006 Shulman et al. Jan 2015 A1
20150013008 Lukacs et al. Jan 2015 A1
20150033341 Schmidtler et al. Jan 2015 A1
20150039513 Adjaoute Feb 2015 A1
20150074810 Saher et al. Mar 2015 A1
20150082430 Sridhara et al. Mar 2015 A1
20150089655 Choi et al. Mar 2015 A1
20150096048 Zhang et al. Apr 2015 A1
20150113616 Sampas Apr 2015 A1
20150121524 Fawaz et al. Apr 2015 A1
20150121529 Quinlan et al. Apr 2015 A1
20150128206 Haim et al. May 2015 A1
20150128246 Feghali et al. May 2015 A1
20150143496 Thomas et al. May 2015 A1
20150150125 Dulkin et al. May 2015 A1
20150150130 Fiala May 2015 A1
20150156214 Kaminsky Jun 2015 A1
20150163121 Mahaffey et al. Jun 2015 A1
20150172300 Cochenour Jun 2015 A1
20150195291 Zuk et al. Jul 2015 A1
20150199512 Kim et al. Jul 2015 A1
20150200928 Burch et al. Jul 2015 A1
20150205962 Swidowski et al. Jul 2015 A1
20150220735 Paithane et al. Aug 2015 A1
20150254161 Baril et al. Sep 2015 A1
20150257194 Cho Sep 2015 A1
20150264068 Beauchesne Sep 2015 A1
20150264077 Berger et al. Sep 2015 A1
20150268947 Ionescu Sep 2015 A1
20150271200 Brady et al. Sep 2015 A1
20150281267 Danahy et al. Oct 2015 A1
20150286820 Sridhara et al. Oct 2015 A1
20150288706 Marshall Oct 2015 A1
20150310196 Turgeman et al. Oct 2015 A1
20150326587 Vissamsetty et al. Nov 2015 A1
20150326588 Vissamsetty et al. Nov 2015 A1
20150326592 Vissamsetty et al. Nov 2015 A1
20150326599 Vissamsetty et al. Nov 2015 A1
20150350236 Klinghofer et al. Dec 2015 A1
20150358345 Clark et al. Dec 2015 A1
20150373039 Wang Dec 2015 A1
20150381376 Wardman et al. Dec 2015 A1
20160028750 Di Pietro et al. Jan 2016 A1
20160042179 Weingarten Feb 2016 A1
20160042180 Sayre et al. Feb 2016 A1
20160055334 Herwono et al. Feb 2016 A1
20160055337 El-Moussa Feb 2016 A1
20160072838 Kolton et al. Mar 2016 A1
20160078365 Baumard Mar 2016 A1
20160080414 Kolton et al. Mar 2016 A1
20160127352 Xu et al. May 2016 A1
20160127413 Kraitsman et al. May 2016 A1
20160142399 Pace et al. May 2016 A1
20160191554 Kaminsky Jun 2016 A1
20160212225 Smith et al. Jul 2016 A1
20160261631 Vissamsetty et al. Sep 2016 A1
20160285914 Singh et al. Sep 2016 A1
20160315909 Von Gravrock et al. Oct 2016 A1
20160323300 Boss et al. Nov 2016 A1
20160323316 Kolton et al. Nov 2016 A1
20160381023 Dulce et al. Dec 2016 A1
20170019425 Ettema et al. Jan 2017 A1
20170026387 Vissamsetty et al. Jan 2017 A1
20170032122 Thakar et al. Feb 2017 A1
20170054754 Saher et al. Feb 2017 A1
20170093910 Gukal et al. Mar 2017 A1
20170126718 Baradaran et al. May 2017 A1
20170134405 Ahmadzadeh et al. May 2017 A1
20170141980 Palanciuc et al. May 2017 A1
20170147796 Sardesai et al. May 2017 A1
20170149787 Niemela et al. May 2017 A1
20170149795 Day, II May 2017 A1
20170149832 Touboul et al. May 2017 A1
20170171244 Vissamsetty et al. Jun 2017 A1
20170180421 Shieh et al. Jun 2017 A1
20170206142 Pawar et al. Jul 2017 A1
20170206357 Gorelik et al. Jul 2017 A1
20170230384 Touboul et al. Aug 2017 A1
20170230402 Greenspan et al. Aug 2017 A1
20170235967 Ray et al. Aug 2017 A1
20170244729 Fahrny et al. Aug 2017 A1
20170244749 Shulman et al. Aug 2017 A1
20170244755 Tsao Aug 2017 A1
20170264639 Sama et al. Sep 2017 A1
20170279839 Vasseur et al. Sep 2017 A1
20170279846 Osterweil et al. Sep 2017 A1
20170286676 Weingarten et al. Oct 2017 A1
20170302458 Berger et al. Oct 2017 A1
20170302653 Ortner et al. Oct 2017 A1
20170302665 Zou et al. Oct 2017 A1
20170302696 Schutz et al. Oct 2017 A1
20170318054 Vissamsetty et al. Nov 2017 A1
20170322959 Tidwell et al. Nov 2017 A1
20170324774 Ohayon et al. Nov 2017 A1
20170324777 Ohayon et al. Nov 2017 A1
20170331849 Yu et al. Nov 2017 A1
20170331856 Vissamsetty et al. Nov 2017 A1
20170346802 Gruskin et al. Nov 2017 A1
20170346853 Wyatt et al. Nov 2017 A1
20170359370 Humphries et al. Dec 2017 A1
20180013788 Vissamsetty et al. Jan 2018 A1
20180020005 Beiter et al. Jan 2018 A1
20180027006 Zimmermann et al. Jan 2018 A1
20180027017 Touboul et al. Jan 2018 A1
20180039776 Loman et al. Feb 2018 A1
20180048665 Shulman et al. Feb 2018 A1
20180063187 St Pierre Mar 2018 A1
20180089430 Mayo Mar 2018 A1
20180146008 Vissamsetty et al. May 2018 A1
20180173876 Vissamsetty et al. Jun 2018 A1
20180183815 Enfinger Jun 2018 A1
20180248896 Challita et al. Aug 2018 A1
20190042745 Chen et al. Feb 2019 A1
20190052659 Weingarten et al. Feb 2019 A1
20190068642 Araujo et al. Feb 2019 A1
20190073475 Vissamsetty et al. Mar 2019 A1
20190114426 Cohen et al. Apr 2019 A1
20190199736 Howard et al. Jun 2019 A1
20190253453 Vissamsetty et al. Aug 2019 A1
20190354355 Jacobson et al. Nov 2019 A1
20190379697 Vissamsetty et al. Dec 2019 A1
20200143054 Cohen et al. May 2020 A1
20200218806 Cho Jul 2020 A1
20200252429 Vissamsetty et al. Aug 2020 A1
20200374087 Vissamsetty et al. Nov 2020 A1
20210397710 Cohen et al. Dec 2021 A1
20220070256 Singh et al. Mar 2022 A1
20220391496 Cho Dec 2022 A9
20230007025 Weingarten et al. Jan 2023 A1
20230007026 Weingarten et al. Jan 2023 A1
20230007027 Weingarten et al. Jan 2023 A1
20230007028 Weingarten et al. Jan 2023 A1
20230007029 Weingarten et al. Jan 2023 A1
20230007030 Weingarten et al. Jan 2023 A1
20230007031 Weingarten et al. Jan 2023 A1
Foreign Referenced Citations (17)
Number Date Country
103607399 Feb 2014 CN
3 171 568 May 2017 EP
2016-512631 Apr 2016 JP
2017-504102 Feb 2017 JP
10-2015-0101811 Sep 2015 KR
10-1969572 Apr 2019 KR
WO 0227440 Apr 2002 WO
WO 2010030169 Mar 2010 WO
WO 2012027669 Mar 2012 WO
WO 2013014672 Jan 2013 WO
WO 2015171780 Nov 2015 WO
WO 2015171789 Nov 2015 WO
WO 2016024268 Feb 2016 WO
WO 2016081561 May 2016 WO
WO 2017064710 Apr 2017 WO
WO 2019092530 May 2019 WO
WO 2019032728 Mar 2020 WO
Non-Patent Literature Citations (46)
Entry
Barbhuiya et al., “Detection of neighbor solicitation and advertisement spoofing in IPv6 neighbor discovery protocol.” Proceedings of the 4th international conference on Security of information and networks. (2011).
Chen et al., “MitM attack by name collision: Cause analysis and vulnerability assessment in the new gTLD era.” Security and Privacy (SP), 2016 IEEE Symposium on. IEEE (2016).
Dini et al., “Probabilistic Contract Compliance for Mobile Applications”, Eighth International Conference on Availability, Reliability and Security (ARES) IEEE, Sep. 2-6, 2013, pp. 599-606.
Gu et al., “Malicious Shellcode Detection with Virtual Memory Snapshots,” 2010 Proceedings IEEE Infocom, San Diego, CA, 2010, pp. 1-9, accessed Mar. 6, 2019.
Installing a Tanium Client—distributed also using user/password (not encrypted) from a hosted Module server, downloaded from https://docs.tanium.com/client/client/deployment.html#client_management on Apr. 1, 2021.
IBM Software, “Stepping up the battle against advanced threats”, IBM Trusteer Apex Thought Leadership White Paper, Dec. 2013, WGW03043-USEN-00.
“IBM Security Qradar SIEM Installation Guide” downloaded from http://www.siem.su/docs/ibm/Installation_and_updating/IBM_Security_QRadar_installation_Guide.pdf, printed 2013, vol. 7.2 in 54 pages.
IBM Security Guardium Insights for IBM Cloud Park for Security', printed from https://www.ibm.com/downloads/cas/QY1RYRLP, printed May 26, 2021 in 12 pages.
IBM Security Qradar Solutuion Brief “Visibility, detection, investigation and response” printed from https://www.ibm.com/downloads/cas/OP62GKAR, printed on May 26, 2021 in 11 pgs.
“IBM Security Trusteer Apex Advanced malware Protection (SaaS) delivers an enterprise endpoint security solution to help protect organizations from advanced malware and targeted attacks” downloaded from https://www-01.ibm.com/common/ssi/rep_ca/0/877/ENUSZP14-0390/ENUSZP14-0390.PDF, printed Aug. 5, 2014, in 9 pgs.
IBM Guardium Documentation “Components and Topology”, downloaded from https://www.ibm.com/docs/en/qsip/7.4?topic=deployment-qradar-architecture-overview, printed on Jun. 8, 2021 in 3 pages.
IBM Software “Stepping up the battle against advanced threats”, downloaded from https://citrixready.citrix.com/content/dam/ready/partners/ib/ibm-global-services/ibm-security-trusteer-apex-advanced-malware-protection/wgw03043usen.pdf, Printed Dec. 2013 in 12 pages.
Laureano et al., M., “Intrusion detection in virtual machine environments. In Euromicro Conference, 2004. Proceedings.” 30th (pp. 520-525). IEEE Sep. 30, 2004.
Liu, Yu-Feng; Zhang Li-Wei; Liang, Juan; Qu, Sheng; Ni, Zhi-Qiang;, “Detecting Trojan Horses Based on System Behavior Using Machine Learning Method”, International Conference on Machine Learning and Cybernetics (ICMLC), IEEE, Jul. 11-14, 2010, pp. 855-860.
IBM, “Qradar Architecture overview”, downloaded from https://www.ibm.com/docs/en/qsip/7.4?topic=deployment-qradar-architecture-overview printed May 28, 2021 in 6 pgs.
Moussaileb et al., “Ransomware's Early Mitigation Mechanisms,” Proceedings ARES 2018 Proceedings of the 13th International Conference on Availability, Reliability and Security Article No. 2, pp. 1-10 (2018).
Ornaghi et al., “Man in the middle attacks.” Blackhat Conference Europe (2003).
Ramachandran et al., “Detecting ARP spoofing: An active technique.” International Conference on Information Systems Security, Springer, Berlin, Heidelberg (2005).
Rüdiger Schollmeier, A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications, Proceedings of the First International Conference on Peer-to-Peer Computing, IEEE (2002).
Shosha et al., A.F., “Evasion-resistant malware signature based on profiling kernel data structure objects.” In 2012 7th International Conference on Risks and Security of Internet and Systems (CRISIS) (pp. 1-8). IEEE., Oct. 31, 2012.
Tanium™ Client Management 1.6 User Guide, downloaded from https://docs.tanium.com/client_management/client_management/index.html on Apr. 1, 2021.
Ullrich et al., “IPv6 Security: Attacks and Countermeasures in a Nutshell.” 8th USENIX Workshop on Offensive Technologies (2015).
Xu, J-Y; Sung, A.H.; Chavez, P.; Mukkamala, S.; “Polymorphic Malicious Executable Scanner by API Sequence Analysis”, Fourth International Conference on Hybrid Intelligent Systems, IEEE Dec. 5-8, 2004, pp. 378-383.
Communication Pursuant to Article 94(3) EPC dated Dec. 11, 2018 for European Application 15 760 520.5, in 7 pages.
Extended European Search Report dated May 9, 2019 for Application No. 16855062.2, in 7 pages.
European Search Report dated Apr. 29, 2021 in European Patent Application No. 18844671 in 38 pages.
Extended European Search Report dated Jan. 25, 2021 for European Patent Application No. 20181537.0, in 10 pages.
Reaqta Hive, A.I. Based Endpoint Threat Response, Whitepaper, 27 pages (Apr. 6, 2017).
International Search Report and Written Opinion dated Feb. 18, 2016 for International Application No. PCT/IL2015/050802, in 10 pages.
International Preliminary Report on Patentability dated Feb. 14, 2017 for International Application No. PCT/IL2015/050802, in 7 pages.
International Search Report and Written Opinion dated Apr. 20, 2017 for International Application No. PCT/IL2016/051110, in 10 pages.
International Search Report and Written Opinion dated Dec. 11, 2018 for International Application No. PCT/US2018/045850, in 12 pages.
International Search Report and Written Opinion dated Aug. 24, 2020 for International Application No. PCT/US2020/033872, in 8 pages.
International Search Report issued in application No. PCT/US2021/050129 dated Dec. 21, 2021.
International Search Report in corresponding International Patent Application No. PCT/US2015/29490, dated Aug. 7, 2015, in 2 pages.
Written Opinion in corresponding International Patent Application No. PCT/US2015/29490, dated Aug. 7, 2015, in 6 pages.
International Preliminary Report on Patentability in corresponding International Patent Application No. PCT/US2015/29490, dated Nov. 8, 2016, in 7 pages.
International Search Report in corresponding International Patent Application No. PCT/US2015/29501, dated Aug. 7, 2015, in 2 pages.
Written Opinion in corresponding International Patent Application No. PCT/US2015/29501, dated Aug. 7, 2015, in 6 pages.
International Preliminary Report on Patentability in corresponding International Patent Application No. PCT/US2015/29501, dated Nov. 8, 2016, in 7 pages.
International Search Report in corresponding International Patent Application No. PCT/US2015/61271, dated Feb. 2, 2016, in 2 pages.
Written Opinion in corresponding International Patent Application No. PCT/US2015/61271, dated Feb. 2, 2016, in 6 pages.
International Preliminary Report on Patentability in corresponding International Patent Application No. PCT/US2015/61271, dated May 23, 2017, in 7 pages.
Office Action dated Jul. 24, 2019 in European Patent Application No. 15760520.5, in 8 pages.
Office Action dated May 31, 2022 in Japanese Patent Application No. 2020-503272, in 7 pages.
Extended European Search Report dated Aug. 25, 2021 for European Patent Application No. 21162973.8, in 5 pages.
Related Publications (1)
Number Date Country
20230281311 A1 Sep 2023 US
Continuations (3)
Number Date Country
Parent 16849808 Apr 2020 US
Child 18179711 US
Parent 15623669 Jun 2017 US
Child 16849808 US
Parent 14456127 Aug 2014 US
Child 15623669 US