Machine learning systems and methods for reducing false positive malware detection rates - Patents.com

Abstract

In some embodiments, the behavior classifier includes a set of neural networks trained to determine whether monitored software entities are malicious according to a sequence of computing events caused by the execution of each entity. When the behavior classifier indicates that an entity is malicious, some embodiments execute a memory classifier including another set of neural networks trained to determine whether monitored entities are malicious according to memory snapshots of the monitored entities. Applying the classifiers sequentially can significantly reduce the false positive detection rate while reducing computational costs.

Description

[Technical field]

[0001] The present invention relates to computer security systems and methods, and in particular to systems and methods for detecting malicious software and / or intrusions into computer systems and / or communications networks. [Background technology]

[0002]

[0002] In recent years, computer and network security has become increasingly important to private individuals and businesses alike. The rapid development of electronic communication technologies, the increasing reliance on software in everyday activities, and the emergence of the Internet of Things have left businesses and individuals vulnerable to loss of privacy, data theft, and ransom attacks.

[0003]

[0003] Malicious software, also called malware, is one of the major computer security threats affecting computer systems worldwide. In many forms, such as computer viruses, worms, rootkits, spyware, etc., malware poses serious dangers to millions of computer users. Security software may be used to detect malware that infects a user's computer system and to remove or stop the execution of such malware. Several malware detection techniques are known in the art. Some rely on matching a fragment of a malware agent's code against a library of signatures indicative of malware. Another method detects a set of malware-indicative behaviors of a malware agent.

[0004]

[0004] Such conventional anti-malware strategies typically rely on human analysts to devise explicit malware detection rules and algorithms. For example, analysts may use their empirical knowledge and / or insight into the ways of malicious software to devise behavioral heuristics, which are then implemented in security software. However, new malware is constantly being created, and therefore such behavioral heuristics must be constantly checked and updated. As the variety of computing devices and the amount of data flowing through information networks increase, it becomes increasingly impractical for human operators to reliably maintain security software. Thus, there is great interest in developing more robust and scalable computer security systems and methods.

[0005]

[0005] A particular problem plaguing computer security is false positive detection, i.e., the situation in which security software misinterprets some legitimate computing activity as a cyber attack. Such events can be particularly costly in terms of productivity and can reduce users' confidence in the respective software solution and even in computer security in general. Thus, reducing the rate of false positive detections can be as important to the success of computer security as reliably detecting real threats. Summary of the Invention

[0006] According to one aspect, a computer system includes at least one hardware processor configured to execute a behavior analyzer to determine whether the software entity is malicious and, in response, determine that the software entity is not malicious when the behavior analyzer indicates that the software entity is not malicious. The at least one hardware processor is further configured to execute a memory analyzer to determine whether the software entity is malicious when the behavior analyzer indicates that the software entity is malicious. The at least one hardware processor is further configured to determine that the software entity is malicious when the memory analyzer indicates that the software entity is malicious and to determine that the software entity is not malicious when the memory analyzer indicates that the software entity is not malicious. The behavior analyzer includes a first neural network configured to receive a sequence of event indicators and determine whether the software entity is malicious according to the sequence of event indicators. Each event indicator in the sequence characterizes a distinct event resulting from execution of the software entity. The sequence of event indicators is ordered according to a time of occurrence of each distinct event. The memory analyzer includes a second neural network configured to receive the sequence of token indicators and determine whether the software entity is malicious according to the sequence of token indicators, where each token indicator in the sequence characterizes a distinct string token extracted from the memory snapshot of the software entity, and the sequence of token indicators is ordered according to a memory location of each string token.

[0007] According to another aspect, a malware detection method includes utilizing at least one hardware processor of a computer system to execute a behavior analyzer to determine whether a software entity is malicious, and responsively determining that the software entity is not malicious when the behavior analyzer indicates that the software entity is not malicious. The method further includes utilizing the at least one hardware processor to execute a memory analyzer to determine whether the software entity is malicious when the behavior analyzer indicates that the software entity is malicious. The method further includes utilizing the at least one hardware processor to determine that the software entity is malicious when the memory analyzer indicates that the software entity is malicious, and determining that the software entity is not malicious when the memory analyzer indicates that the software entity is not malicious. The behavior analyzer comprises a first neural network configured to receive a sequence of event indicators and determine whether the software entity is malicious according to the sequence of event indicators. Each event indicator in the sequence characterizes a distinct event resulting from execution of the software entity. The sequence of event indicators is ordered according to a time of occurrence of each distinct event. The memory analyzer includes a second neural network configured to receive the sequence of token indicators and determine whether the software entity is malicious according to the sequence of token indicators, where each token indicator in the sequence characterizes a distinct string token extracted from the memory snapshot of the software entity, and the sequence of token indicators is ordered according to a memory location of each string token.

[0008] According to another aspect, a non-transitory computer readable medium stores instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to execute a behavior analyzer to determine whether the software entity is malicious and, in response, determine that the software entity is not malicious when the behavior analyzer indicates that the software entity is not malicious. The instructions further cause the computer system to execute a memory analyzer to determine whether the software entity is malicious when the behavior analyzer indicates that the software entity is malicious. The instructions further cause the computer system to determine that the software entity is malicious when the memory analyzer indicates that the software entity is malicious and to determine that the software entity is not malicious when the memory analyzer indicates that the software entity is not malicious. The behavior analyzer comprises a first neural network configured to receive a sequence of event indicators and determine whether the software entity is malicious according to the sequence of event indicators. Each event indicator in the sequence characterizes a distinct event resulting from the execution of the software entity. The sequence of event indicators is ordered according to a time of occurrence of each distinct event. The memory analyzer includes a second neural network configured to receive the sequence of token indicators and determine whether the software entity is malicious according to the sequence of token indicators, where each token indicator in the sequence characterizes a distinct string token extracted from the memory snapshot of the software entity, and the sequence of token indicators is ordered according to a memory location of each string token.

[0009]

[0009] The above aspects and advantages of the present invention will be better understood upon reading the following detailed description and referring to the drawings, in which: [Brief description of the drawings]

[0010] [Figure 1]

[0010] FIG. 1 illustrates a set of interconnected client systems that are protected from computer security threats in accordance with some embodiments of the present invention. [Diagram 2]

[0011] FIG. 2 illustrates an exemplary hardware configuration of a computing device configured to perform computer security operations in accordance with some embodiments of the present invention. [Diagram 3]

[0012] FIG. 2 illustrates exemplary software components executing on a protected client system in accordance with some embodiments of the present invention. [Figure 4]

[0013] 2 is a structural and functional diagram of an exemplary security module according to some embodiments of the present invention. [Diagram 5]

[0014] FIG. 2 illustrates an example event sequence including an example event record, according to some embodiments of the present invention. [Figure 6]

[0015] FIG. 2 illustrates example components of a behavior analyzer according to some embodiments of the present invention. [Figure 7]

[0016] FIG. 2 illustrates an example behavior embedding array including multiple event embedding vectors, according to some embodiments of the present invention. [Figure 8]

[0017] FIG. 2 illustrates an example structure and operation of a behavior classifier, according to some embodiments of the present invention. [Figure 9]

[0018] FIG. 1 illustrates the operation of an exemplary convolutional neural network former of a behavior classifier, according to some embodiments of the present invention. [Figure 10-A]

[0019] FIG. 2 illustrates an exemplary unidirectional recurrent neural network in accordance with some embodiments of the present invention. [Figure 10-B]

[0020] FIG. 2 illustrates an exemplary two-way recurrent neural network according to some embodiments of the present invention. [Figure 11]

[0021] FIG. 2 illustrates an exemplary memory snapshot including multiple string tokens, in accordance with some embodiments of the present invention. [Figure 12]

[0022] FIG. 2 illustrates example components of a memory analyzer according to some embodiments of the present invention. [Figure 13]

[0023] 4A-4C illustrate an exemplary sequence of steps performed by a security module according to some embodiments of the present invention. [Figure 14]

[0024] FIG. 2 illustrates an exemplary communication exchange in one embodiment where security software runs on a security server, according to some embodiments of the present invention. [Figure 15]

[0025] FIG. 2 illustrates an exemplary procedure for training an event encoder according to some embodiments of the present invention. [Figure 16]

[0026] FIG. 2 illustrates an alternative procedure for training an event encoder according to some embodiments of the present invention. [Figure 17]

[0027] FIG. 2 illustrates exemplary software components in an alternative embodiment of the present invention. [Figure 18]

[0028] FIG. 4 illustrates an exemplary sequence of steps performed by a security module in an alternative embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011]

[0029] In the following description, it should be understood that all described connections between structures can be direct operational connections or indirect operational connections through intermediate structures. A set of elements includes one or more elements. Any description of an element should be understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise specified, any use of "or" refers to a non-exclusive logical or. Unless otherwise required, any described method steps need not necessarily be performed in the particular order shown. A first element (e.g., data) derived from a second element includes a first element equal to a second element, as well as a first element generated by processing a second element and, optionally, other data. Making a determination or decision according to a parameter includes making a determination or decision according to a parameter and, optionally, other data. Unless otherwise specified, an indicator of a quantity / data may be the quantity / data itself, or the indicator may be different from the quantity / data itself. Computer security includes protecting equipment and data against unauthorized access, modification, and / or destruction. A computer program is a sequence of processor instructions that perform a task. Computer programs described in some embodiments of the invention may be standalone software entities or subentities (e.g., subroutines, libraries) of other computer programs. A process is an instance of a computer program, such as an application or part of an operating system, characterized by having at least a thread of execution and a virtual memory space assigned to the thread of execution, the contents of each virtual memory space containing executable code. Unless otherwise specified, a page represents the smallest unit of virtual memory that can be individually mapped into the physical memory of a host system. A hash is the numerical result of applying a hash function to a token (e.g., a string, a code snippet, etc.). A hash function maps data of any size to a value of a fixed size.Exemplary hashing functions / procedures include, among others, cyclic redundancy checks (CRC), checksums, message digest functions (e.g., MD5), and secure hash algorithms (SHA). Computer-readable media encompass non-transitory media, such as magnetic storage media, optical storage media, semiconductor storage media (e.g., hard drives, optical disks, flash memory, DRAM), as well as communications links, such as conductive cables and fiber optic links. According to some embodiments, the present invention provides, among other things, computer systems comprising hardware (e.g., one or more processors) programmed to perform the methods described herein, as well as computer-readable media encoding instructions for performing the methods described herein.

[0012]

[0030] The following description illustrates embodiments of the present invention by way of example, and not necessarily by way of limitation.

[0031] 1 illustrates an exemplary set of client systems 10a-c protected from computer security threats according to some embodiments of the present invention. Client systems 10a-c collectively represent electronic devices having a processor, memory, and a communication interface. Exemplary client systems 10a-c include personal computers, enterprise mainframe computers, servers, laptops, tablet computers, mobile telecommunications devices (e.g., smartphones), media players, TVs, game consoles, home appliances, wearable devices (e.g., smart watches), among others.

[0013]

[0032] The illustrated client systems are interconnected by a communications network 14, which may include a local area network (LAN) and / or a wide area network (WAN) such as the Internet. In some embodiments, the clients 10a-c are further connected to a security server 12 by the network 14. The server 12 collectively represents a set of communicatively coupled computer systems that may or may not be physically proximate to one another. The clients 10a-c are protected against computer security threats (e.g., malware, intrusions) by security software running on each client system and / or the security server 12, as described in more detail below. In some embodiments, such protection includes the security software automatically detecting suspicious activity occurring on the client systems, such as actions by an attacker to take control of the respective client systems, attempts by malicious software to extract sensitive information from the respective clients, etc.

[0014]

[0033] FIG. 2 illustrates an exemplary hardware configuration of a computing device 100 that can be configured to perform computer security operations as described herein. The device 100 may represent any of the client systems 10a-c of FIG. 1, as well as the security server 12. For clarity, the illustrated computing device is a personal computer. Other computing devices, such as mobile phones, tablet computers, wearable devices, etc., may have slightly different configurations. The processor 22 comprises a physical device (e.g., a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate) configured to perform calculations and / or logical operations with a set of signals and / or data. Such signals or data may be encoded and delivered to the processor 22 in the form of processor instructions, e.g., machine code. The memory unit 24 may comprise a volatile computer-readable medium (e.g., a dynamic random access memory - DRAM) that stores data / signals accessed or generated by the processor 22 while performing operations.

[0015]

[0034] Input devices 26 may include, among other things, a computer keyboard, a mouse, a microphone, including respective hardware interfaces and / or adapters that allow a user to introduce data and / or instructions into device 100. Output devices 28 may include, among other things, display devices such as a monitor and speakers, as well as hardware interfaces / adapters, such as a graphics card, that allow the respective computing device to communicate data to a user. In some embodiments, input and output devices 26-28 share common hardware (e.g., a touch screen).

[0016]

[0035] Storage device 32 includes computer-readable media that allows for non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage devices include magnetic disks, optical disks, and flash memory devices, as well as removable media such as CD and / or DVD disks and drives. Network adapter 34 enables computing device 100 to connect to electronic communications networks (e.g., network 14 of FIG. 1) and / or other devices / computer systems.

[0017]

[0036] Controller hub 30 collectively represents multiple system, peripheral, and / or chipset buses and / or other circuitry that enables communication between processor 22 and the remainder of the hardware components of device 100. For example, controller hub 30 may include a memory controller, an input / output (I / O) controller, an input / output (I / O) controller, and an interrupt controller. Depending on the hardware manufacturer, some such controllers may be incorporated into a single integrated circuit and / or may be integrated with the processor. In another example, controller hub 30 may include a northbridge that connects processor 22 to memory 24 and / or a southbridge that connects processor 22 to devices 26, 28, 32, and 34.

[0018]

[0037] 3 illustrates exemplary components of a client system 10 (e.g., any of client systems 10a-c of FIG. 1) according to some embodiments of the present invention. Such components may be implemented as software, i.e., a computer program that includes instructions that, when loaded into memory unit 24 and executed by hardware processor 22, cause the processor to perform respective tasks or procedures. Those skilled in the art will appreciate that any and / or all of the illustrated components may also be implemented in hardware, firmware, and / or a combination of the above, and may interact with other components via dedicated drivers and / or interfaces. Loading a component / module onto memory 24 and / or processor 22 is referred to herein as forming or executing the respective component / module.

[0019]

[0038] Client systems 10 may execute an operating system (OS) 40 that provides an interface between the hardware of client system 10 and other computer programs, such as user applications 42, running on the respective client system. Exemplary operating systems include Windows, Linux, MacOS, iOS, and Android, among others. User applications 42 generically represent any computer program, such as word processing, image processing, spreadsheets, calendars, gaming, social media, web browsers, electronic communication applications, among others.

[0020]

[0039] In some embodiments, security module 44 is configured to protect client system 10 against computer security threats, such as malicious software and intrusions. Among other functions, security application 44 is configured to detect a set of events occurring during execution of software on client system 10 and determine whether each client system is under attack according to each detected event. In some embodiments, security module 44 is further configured to determine whether each client system is under attack according to the contents of a section of memory of each client system. In some embodiments, security module 44 comprises an artificial intelligence system, such as a set of artificial neural networks that are pre-trained to distinguish between benign and malicious event sequences and / or between legitimate and malicious memory content, as described in more detail below.

[0021]

[0040] The security module 44 may execute at various levels of processor privilege. For example, in some embodiments, the module 44 executes at the user level (also referred to as ring 3 on some hardware platforms). Some components may execute at the processor privilege level of the OS 40 (usually ring 0 or kernel mode). In hardware virtualization embodiments where the OS 40 and applications 42 execute within virtual machines (e.g., in a cloud computing environment), the module 44 may be configured to protect multiple virtual machines running on the client system 10. In such embodiments, the module 44 may execute outside of the protected virtual machines, at the processor privilege level of the hypervisor that exposes the respective virtual machines (e.g., ring -1 or VMX root on Intel® platforms), or within a separate dedicated security virtual machine. To perform operations such as event detection from a location outside of the protected virtual machine, some embodiments may utilize a set of procedures referred to in the art as virtual machine introspection.

[0022]

[0041] 4 illustrates exemplary components of security module 44, according to some embodiments of the present invention. Module 44 comprises data extractor 46, behavior analyzer 60, memory analyzer 70 that receives input from data extractor 46, and decision module 48 coupled to analyzers 60 and 70. In some embodiments, security module 44 uses artificial intelligence techniques to calculate a malicious indicator 80 that indicates whether the respective client system is currently under attack, e.g., whether the respective client system contains malicious software or is controlled by a malicious intruder. In a preferred embodiment, analyzers 60 and / or 70 each comprise a set of artificial neural networks trained to distinguish between benign and malicious software entities according to the sequence of events caused by the execution of the monitored entities and according to memory snapshots of the respective monitored entities. The scope of the monitored software entities can vary from individual processes / threads to entire virtual machines.

[0023]

[0042] The data extractor 46 provides input to the behavior analyzer 60 and / or the memory analyzer 70. In some embodiments, the extractor 46 is configured to detect the occurrence of certain events during the execution of the software on the respective client system. Exemplary detected events include, among others, process launch and termination, creation of child processes (e.g., forking), dynamic loading / unloading of libraries, execution of certain processor instructions (e.g., system calls), file events such as file creation, writing, and deletion, and setting of various OS parameters (e.g., Windows® registry events). Other exemplary events include, among others, requests to access peripheral devices (e.g., hard disks, network adapters), requests for access to remote resources (e.g., HyperText Transfer Protocol-HTTP requests for access to a particular URL, attempts to access a document repository over a local network), requests expressed in a particular uniform resource identifier scheme (e.g., mailto: or FTP: requests), and attempts to send electronic messages (e.g., e-mail, Short Message Service-SMS, etc.). Detected events may or may not be malicious in nature, and some events may be malicious when occurring in conjunction with other events and / or when occurring in certain sequences.

[0024]

[0043] Event detection may include any method known in the art. As an example, upon detection of the initiation of a process / application (such as user application 42), data extractor 46 registers the respective process with the OS 40's event logging service (e.g., event tracking for Windows -ETW, Syslog for UNIX). In response, extractor 46 may receive notification of various events occurring during the execution of the respective process, either in real time or in logged form. Event logging tools typically generate a list of event descriptors that include a timestamp for each event, a numeric code identifying the event type, an indication of the type of process or application that generated the respective event, and other event parameters. In such an embodiment, extractor 46 may detect the occurrence of a target event by parsing the respective event log.

[0025]

[0044] In another example of event detection, data extractor 46 may modify the set of native functions of OS 40 by inserting redirection instructions (also called hooks or patches). In this way, when a process running on client system 10 calls the respective OS function, execution is redirected to a callback routine that notifies extractor 46 about the attempt to execute the respective OS function. When the hooked function serves the monitored event (e.g., file creation, process launch, etc.), the attempt to call the respective function may serve as an indication of the occurrence of the respective event.

[0026]

[0045] In yet another example, particularly suited to hardware virtualization embodiments, data extractor 46 may modify the access permissions of memory pages, for example to indicate that the respective memory pages hosting a targeted OS function are not executable. An attempt to execute the respective OS function would then trigger a processor exception (e.g., a page fault). Extractor 46 may further register as an exception handler, such that an attempt to execute the target OS function automatically notifies data extractor 46. Such a notification may indicate the occurrence of a target event.

[0027]

[0046] The data extractor 46 may organize the detected events into event sequences according to the time of occurrence of each event and / or according to the software entity that caused the respective event. As an example, an event sequence is organized exclusively from events caused by the execution of the same software entity, for example identified by the software entity's unique identifier (e.g., process id-PID) assigned by the OS 40. In alternative embodiments, an event sequence may have events caused by the execution of a group of related software entities, for example members of the same software suite, entities related to each other by a parent-child relationship (parent-child), or entities sharing a common characteristic, such as a Windows® proc_path or a Windows® FilePath key value. Within a sequence, the individual events may be arranged in order of their occurrence time.

[0028]

[0047] An exemplary event sequence 52 is shown in FIG. 5, with each event represented by a corresponding event record. An exemplary record 53a represents a file creation event, and another exemplary record 53b represents a Windows® registry edit. Each event record may include a set of characteristic features of the respective event, such as the time of occurrence (e.g., timestamp), the event type, a unique identifier of the respective event (e.g., hash, uuid), an identifier of the software entity that caused the respective event (e.g., process ID-pid), a location indicator of the respective entity (e.g., file path, proc_path), various event-specific parameter values, etc. Event records may be encoded using any method known in the art, for example as attribute-value pairs specified in the Extensible Markup Language (XML) or a version of Javascript Object Notation (JASON), among others.

[0029]

[0048] Some embodiments of the data extractor 46 further process the event sequence 52 by representing each event in the sequence as a numeric code that uniquely identifies the event type of each event (e.g., file creation, registry write, HTTP request, etc.). In such embodiments, the event sequence 52 may thus be represented as an ordered sequence of numbers. Another exemplary embodiment represents an N E A subset of N distinct event types (referred to herein as an event vocabulary) is tracked, where each event E The event vocabulary is represented as an N × 1 Boolean vector, with each row representing a distinct event type, and the value of each element (0 or 1) indicating whether the respective event is of the respective type or not. Events of types not included in the event vocabulary may be ignored or replaced with a generic placeholder (e.g., "other"). Such a representation is typically referred to as one-hot encoding. In such an embodiment, the entire event sequence 52 is N E ×M E M Erepresents the number of events in sequence 52, with each column representing a separate event, and the columns are ordered according to the timestamp of each event. Those skilled in the art will appreciate that many alternative event encodings may be used as well without departing from the scope of this description, and thus the exemplary one-hot encoding shown herein is not limiting.

[0030]

[0049] Event vocabulary size N E And / or the configuration may be chosen according to the results of experiments, for example by running the behavior classifier 60 with several distinct choices of vocabulary and comparing the results in terms of performance metrics (such as accuracy, detection rate, and / or false positive rate, amount of computing resources consumed, etc.). The configuration of the event vocabulary (i.e., the selection of event types to be monitored) may further be selected according to the ease of detection, frequency of occurrence, and security relevance of each distinct event type. As an example, the event vocabulary includes n% of the most frequently occurring event types, where n ranges from 1 to 10, further filtered to remove event types that are not considered to be relevant to computer security.

[0031]

[0050] In one particular example, each distinct item in the event vocabulary represents a distinct event type (e.g., file creation, registry write, DLL load, etc.). In other words, two file creation events with distinct file names / paths are represented as a single vocabulary item. In such an embodiment, N E The value can vary between 20 and 50, with a typical value being 36 for clients running Windows operating systems. In another example, the lexical items are tuples created by pairing an event type (e.g., file creation) with other characteristics of the respective event (e.g., file name or path in the case of a file creation event). In such an embodiment, two file creation events with distinct file names / paths are represented as two separate lexical items. Some examples of such characteristic tuples are given below:

[0032]

[0051] 'DIR_ENUM':['FileName'], 'FILE_CLOSE':['FilePath'], ' FILE_CREATE':['FilePath','CreateOptions'], 'FILE_SET_PROPERTIES':['FilePath'], 'FILE_WRITE':['FilePath'], 'KCBCreate':['KeyPath','KeyName'], 'KCBDelete':['KeyPath','KeyName'], 'REGISTRY_SET_VALUE':['KeyPath','KeyName'], 'IMAGE_LOAD':['FileName'], 'IMAGE_UNLOAD':['FileName'] 'PROCESS_CREATE':['CommandLine','ExitStatus','Flags','Image','ImageFileName','PackageFullName','ParentCommandLine','ParentImage'], 'PROCESS_TERMINATE':['CommandLine','ImageFileName','Flags','ExitStatus'] In such an embodiment, N E The values ​​are usually in the range of hundreds of thousands to several million.

[0033]

[0052] In some embodiments, behavior analyzer 60 receives event sequences 52 and outputs a behavior decision 56 indicating whether the software entity that caused the respective sequence of events is malicious. In some embodiments, behavior decision 56 includes an indication of the likelihood of maliciousness (e.g., a numerical probability, a value on a predetermined scale, etc.) or an indication of a category selected from a predetermined set of categories characterizing maliciousness (e.g., low / medium / high likelihood, clean / infected / unknown, etc.).

[0034]

[0053] 6 illustrates exemplary components of a behavior analyzer 60 according to some embodiments of the present invention. The analyzer 60 may include an event encoder 62 and a behavior classifier 64 coupled to the event encoder 62. In a preferred embodiment, the encoder 62 and the classifier 64 comprise pre-trained artificial neural networks.

[0035]

[0054] 7 illustrates an exemplary operation of an event encoder 62 according to some embodiments of the present invention. The event encoder 62 is configured to determine, for each event of the sequence 52, represented herein by a one-hot vector E0, an embedding vector 65 that includes a representation of the respective event in an abstract multi-dimensional space, considered as an embedding space. The exemplary event embedding space is spanned by a set of axes, each axis representing a distinct event feature or combination of event features (e.g., a principal component of the event feature space). Some embodiments may use an embedding vector 65 for an event vocabulary of size N E , i.e., the count of distinct event types that the security module 44 is monitoring. For example, the dimension of the event embedding space may be N E About the square root of, or N E A typical dimension according to some embodiments is on the order of a few hundred (e.g., 100 or 300 dimensions).

[0036]

[0055] In a preferred embodiment, individual events are not analyzed in isolation, but in the context of other events, and the embedding vector 65 resides in a context embedding space where two events that mostly occur in similar contexts are located relatively close to each other. In other words, two events that frequently occur together are separated in the embedding space by a distance that is less than the distance between two events that mostly occur in different contexts. Figure 7 illustrates a central event E0 and a subset of events that precede the central event according to their associated timestamps, E -k ...E -1 (k ≥ 1), and / or a subset of events E1...E following the focal event. p 1 shows an exemplary event sequence 52 including an exemplary event context consisting of k (p≧1). An exemplary embodiment uses symmetric event contexts (p=k), where p ranges from 2 to 5.

[0037]

[0056] In a preferred embodiment, the event encoder 62 comprises an artificial intelligence system, such as a multi-layer artificial neural network (e.g., a recurrent and / or feed-forward neural network). To achieve a desired representation of the event vector, parameters of the encoder 62 may be adjusted until some performance criteria are met. Such adjustments are referred to herein as training. In a neural network embodiment, exemplary adjustable parameters of the event encoder 62 include a set of synaptic weights and activation biases, among others. In some embodiments, training the event encoder 62 corresponds to constructing the embedding space itself. In other words, the embedding space is not predefined, but rather depends on the configuration of the training event corpus and the training procedure selected. Exemplary training procedures include versions of the word2vec algorithm (such as the skip-gram algorithm and the continuous bag-of-words algorithm), as well as versions of the GloVe algorithm. Further details regarding training are provided below in conjunction with FIGS. 15-16.

[0038]

[0057] In some embodiments, the embedding vector 65 generated by the trained event encoder 62 is further fed to a behavior classifier 64, which outputs a behavior decision 56 determined according to the event embedding vector 65. An example decision 56 includes a label (e.g., benign / malicious / unknown). In another example, the behavior decision 56 includes a number indicating the likelihood / probability that the respective monitored entity is malicious.

[0039]

[0058] In some embodiments, the behavior classifier 64 includes a set of interconnected artificial neural networks trained to distinguish between benign and malicious behavior according to the event sequences 52. To accurately distinguish between malicious and benign behavior, the classifier 64 is pre-trained on a corpus of example event sequences extracted from malicious and / or benign samples. Further training details are provided below.

[0040]

[0059] An exemplary architecture of the classifier 64 is shown in FIG. 8 and comprises a stack of layers / neural network modules, each layer receiving the output of the previous layer / module and providing input to the next layer in the stack. Each successive layer transforms the input received from the previous layer according to a set of pre-configured network parameters (e.g., activations, weights, biases) specific to each layer to generate an internal representation of the embedding vector 65, referred to herein as an internal vector (depicted as item 82 in FIG. 8 ). The size and range of values ​​of the internal vector 82 may vary between distinct layers / modules of the classifier 64. For example, some layers achieve dimensionality reduction of the respective input vector, as in the case of pooling or loss layers.

[0041]

[0060] In a preferred embodiment, the behavior classifier 64 comprises a convolutional neural network (CNN) layer followed by a dense layer (i.e., a fully connected layer) further coupled to a rectified linear unit (ReLU) and / or loss layer. An alternative embodiment comprises a CNN layer that further feeds into a recurrent neural network (RNN) followed by a fully connected layer and a ReLU / loss layer. In yet another exemplary embodiment, the classifier 64 lacks a CNN module and instead comprises an RNN that further feeds into a fully connected layer and a ReLU / loss layer that ultimately produces the decision 56.

[0042]

[0061] The operation of an exemplary convolutional neural network is illustrated in FIG. 9. In some embodiments, the CNN takes as input an array of event embedding vectors 65 (see, for example, the embedding array in FIG. 6). Within the array, the embedding vectors 65 are ordered in sequence according to the occurrence time of each event. The convolution effectively multiplies the embedding vector 65 with a matrix of weights (commonly called filters in the art of machine learning) to generate an embedding tensor. The weights of each convolutional layer may be adjusted in a training procedure. The convolution itself corresponds to performing multiple dot products between the elements of the embedding vector 65 and each convolutional filter. In the example of FIG. 9, each filter generates a separate two-dimensional slice of the embedding tensor, with each slice being stacked in the order of application of the convolutional filters. Within each slice i, each element T of the embedding tensor is multiplied by a matrix of weights (commonly called filters in the art of machine learning). ijhas a contribution from event j, but also from neighboring events j-1, j+1, etc. Thus, the embedding tensor collectively represents the event sequence 52 at a coarser granularity than the individual events. In some embodiments, the convolution filter has a limited effective receptive field of size r, i.e., all filter elements are zero except for r neighboring elements. When such a filter is applied as shown in FIG. 9, each element of a respective slice of the embedding tensor contains contributions from r consecutive events and / or r neighboring elements of the embedding vector 65. Typical values ​​of r according to some embodiments of the invention range from 1 to 5 and may vary between convolution filters.

[0043]

[0062] In some embodiments, the CNN layer is followed by a pooling layer that reduces the dimensionality of the embedding tensor by replacing entire groups of adjacent elements of the embedding tensor with a single number calculated according to the respective group. Exemplary pooling strategies include max pooling, where each group of values ​​is replaced with the maximum value of the group, and average pooling, where each group of values ​​is replaced with the average of the group values. A typical length of the resulting inner vector 82 according to some embodiments is on the order of a few hundred (e.g., 100 or 300). The application of pooling and / or other dimensionality reduction procedures further ensures that each element inner vector 82 characterizes the extracted event sequence 52 with a coarser granularity than individual events.

[0044]

[0063] Recurrent Neural Networks (RNNs) form a special class of artificial neural networks, where the connections between network nodes form a directed graph. FIG. 10-A illustrates a schematic of an exemplary unidirectional RNN according to some embodiments of the present invention. The illustrated RNN includes a set of hidden units (e.g., individual neurons) H1, H2, etc., configured to receive a sequence of input vectors and in response generate another sequence of output vectors, such that each output vector corresponds to a distinct input vector. As an explicit example of FIG. 10-A, each of the sequences of inner vectors corresponds to a distinct embedding vector 65. The topology of the RNN is such that each hidden unit H j Event E j , but the adjacent hidden units H j-1 and a hidden unit H j-1 is the event E in each event sequence. j Event E preceding j-1 As a result, the hidden unit H j The output of the current event E j Not only the preceding event E j-1 In other words, the depicted RNN processes information about the current event in the context of previous events.

[0045]

[0064] FIG. 10-B illustrates a two-way RNN according to some embodiments of the present invention. In contrast to the example of FIG. 10-A, the two-way RNN has an extra set of hidden units G1, G2, etc., and each hidden unit G j Event E j , but the adjacent hidden units G j+1 and a topology that ensures that the hidden unit G j+1 is the event E in each event sequence. j Event E follows j+1 Then, the hidden unit H j The output of the hidden unit Gj The output of the,t,i,-th event is then combined with the output of,the,t,i,-th event, resulting in a,two-way RNN that processes information about the,current event in the context of both previous and subsequent events.

[0046]

[0065] Several RNN architectures are known in the art. In embodiments of the present invention, the RNN layer of the behavior classifier 64 may be implemented using, for example, a long-short-term memory (LSTM) architecture and / or a graph neural network (GNN) architecture. In one such example, the RNN comprises multiple stacked LSTM networks (e.g., 2-4 layers). Some or all of the LSTM networks may be two-way. In some embodiments, the RNN layer outputs a prediction vector determined according to a sequence of event embedding vectors 65. The prediction vector may then be fed to a fully connected layer, which computes a behavior decision 56 indicating whether the event sequence 52 is malicious or not.

[0047]

[0066] In some embodiments, memory analyzer 70 (FIG. 4) is configured to receive memory snapshots 54 from data extractor 46 and output memory decisions 58 indicative of whether a software entity having a respective memory snapshot is malicious. Memory decisions 58 may include a label (e.g., benign / malicious / unknown) and / or a number indicative of the likelihood that a respective software entity is malicious.

[0048]

[0067] FIG. 11 illustrates an exemplary memory snapshot according to some embodiments of the present invention. Modem computing systems typically work with virtual memory, an abstraction of the actual physical memory 24. Typically, each software entity running on the respective computing system is assigned a virtual memory space, with each portion of said space being mapped to an address in the physical memory 24 and / or physical storage device 32. In hardware platforms that support paging, the physical memory 24 is divided into units commonly called pages, and the mapping between the physical memory and the virtual memory is done with page granularity. In the example of FIG. 11, the software entity to be monitored (e.g., a process running on the client system 10) is assigned a virtual memory space 124, which then accesses the physical memory 24 via a virtual address, also referred to in the art as a logical address. A virtual memory page 190 in the space 124 is mapped to a physical page 90 in the actual memory 24. Such a mapping essentially involves a memory address translation from a virtual address to a physical address. When a monitored entity attempts to access the contents of page 190, the address of page 190 is translated by the processor to the address of page 90 in physical memory 24 according to a page table typically configured and controlled by guest OS 40. In a hardware virtualization platform, when a monitored entity executes within a virtual machine, processor 22 typically performs an additional address translation from the virtual memory space assigned to the respective virtual machine to actual memory 24. Such translation is implemented via a mechanism called second level address translation (SLAT), e.g., the extended page table (EPT) on Intel® platforms.

[0049]

[0068] In some embodiments, memory snapshot 54 includes a copy of the contents of the set of memory pages used by each monitored entity. A page is used by an entity when the page currently contains the code and / or data of the respective software entity. Snapshot 54 may include the contents of entire pages (i.e., all data currently stored in the respective pages), or data belonging to each entity strictly in the respective memory pages. An exemplary snapshot of an OS kernel may include, among other things, copies of the kernel's code and data sections, various in-memory kernel drivers (code and / or data sections), in-memory kernel threads and corresponding stacks, a list of loaded modules, a list of processes, and other OS kernel data structures. An exemplary snapshot of an application 42 may include a copy of the memory image of application 42, including, among other things, the application's code and data sections, the in-memory stacks used by the application's threads, and the heap memory pages of application 42.

[0050]

[0069] Some embodiments build a memory snapshot 54 of monitored entities (e.g., processes) according to the contents of the executable files / binary images of the respective entities. The executable files contain processor instructions for executing the respective entities, and the processor instructions are stored on a non-volatile medium (e.g., storage device 32 of FIG. 2). In a system running Windows, exemplary executable files include files with extensions EXE, SYS, and DLL, among others. Executable files are built according to platform-specific formats, such as Microsoft portable executable (PE) and the Executable and Linkable Format (ELF) used in the Linux operating system family. An executable file typically includes a header, a set of code sections that contain a binary encoding of the executable code, and a set of non-code sections that contain various non-executable data of the respective software entity. When the respective entities are launched and executed, the header and the contents of the code sections, as well as the contents of some of the non-code sections, are loaded into memory at various addresses in a virtual memory space set up by the operating system for the respective process. The header of an executable file typically stores metadata indicating, among others, the sizes and memory offsets of the various code and non-code sections of the respective entity. For example, the header metadata may list the various sections in a particular order.

[0051]

[0070] Some embodiments of the invention detect the launch of monitored entities and, in response thereto, suspend execution of the respective entities at a point after loading the executable file into memory and determine the memory locations of various data / code sections. For example, some embodiments may identify memory pages that store header metadata for the respective executable files before allowing execution of the respective entities to resume, and use such metadata to further identify all memory pages that store code and / or data for the respective entities. When later invoked to extract memory snapshot 54, some embodiments read and concatenate the contents of each memory page in the order indicated in the header metadata of each monitored entity.

[0052]

[0071] To extract the memory snapshot 54, some embodiments cooperate with the OS 40 to obtain information such as addresses of page tables used by the OS 40 and perform address translation for each monitored entity. Some embodiments further suspend execution of the monitored entity for the duration of taking the memory snapshot 54 to ensure the integrity of the extracted memory contents. Some embodiments may further trigger a page fault to ensure that all required contents are currently in memory, i.e., not paged out to non-volatile storage 32. When the monitored entities execute within a virtual machine but the data extractor 46 executes outside of the respective virtual machine, some embodiments utilize memory introspection techniques to determine which memory pages contain code / data belonging to the monitored entity. Such techniques may include analyzing various data structures (such as execution process blocks, or EPROCESS in Windows) used by the OS 40 to manage the execution of the monitored entities. Alternative embodiments may insert a software agent within each virtual machine, the agent configured to locate the contents of the memory snapshot 54 and communicate a representation of the respective memory locations to the data extractor 46.

[0053]

[0072] 12 illustrates exemplary components of a memory analyzer 70 according to some embodiments of the present invention. The illustrated memory analyzer 70 comprises a token extractor 72 connected to a token encoder 74 and a memory classifier 76 connected to the token encoder 74.

[0054]

[0073] The classifier 76 is configured to determine whether a software entity having a memory snapshot 54 is malicious according to a set of characteristic features of the respective memory snapshot. In some embodiments, such features include a set of tokens present in the memory snapshot 54. In a preferred embodiment, the tokens consist of strings (e.g., library names, function names, names of various code and non-code sections of the respective executable files, snippets of text such as messages displayed at runtime, various URLs or other addresses of remote resources used by the respective software entities, etc.), although this aspect of the invention is not meant to be limiting. Exemplary string tokens 55a-f are illustrated in FIG. 11. Those skilled in the art will appreciate that other tokens (e.g., snippets of code, opcodes, PE section flags, etc.) may be similarly extracted from the memory snapshot 54 and used to assess maliciousness.

[0055]

[0074] In some embodiments, the token extractor 72 is configured to extract a set of strings by parsing the memory snapshot 54 for values ​​that fit the format and range of the American Standard Code for Information Exchange (ASCII) or Unicode encoding of printable characters (letters / glyphs, numbers, punctuation, etc.) and copying each value from the snapshot 54. In another example, the token extractor 72 may parse the snapshot 54 for a set of predefined token delimiters (e.g., a particular control value or character) and identify the contents of the snapshot 54 located between successive delimiters as one token. Some embodiments may split a multi-word string into individual word tokens. In some embodiments, the token extractor 72 may further arrange the extracted tokens in the sequence according to some criteria, for example, by grouping tokens of the same type together, or by concatenating the extracted tokens in the sequence according to their respective positions in the snapshot 54, for example, in ascending order of memory addresses. Some embodiments arrange the tokens in the sequence preserving the relative positions of the tokens as they are found in the binary image of each monitored entity (e.g., as indicated in the executable file of the monitored entity).

[0056]

[0075] In some embodiments, for each extracted token sequence, the encoder 74 generates a memory embedding vector 66 that includes a representation of the respective token sequence in an abstract space, referred to herein as a memory embedding space. Some embodiments first determine a memory feature vector for each token sequence, where each token in each sequence is replaced with a numeric label. One exemplary manner of determining such a memory feature vector includes replacing each token with a hash of the respective token. Another exemplary memory feature vector is a memory embedding vector 66 of size N TThe ordered vocabulary of tokens can be constructed according to the N most frequently found in a training corpus of memory snapshot / token sequences extracted from various software samples. T The alternative token vocabulary may consist of N unique tokens that most efficiently distinguish between benign and malicious software entities according to testing. T The vocabulary may consist of N distinct tokens. Each token in the vocabulary may receive a unique numeric label, for example, indicating the position of the respective token in the vocabulary. Computing the memory feature vector may then include finding each member of the token sequence in the token vocabulary and replacing each member with its respective label. In some embodiments, tokens that are not in the vocabulary are discarded from the sequence or replaced with a generic placeholder (e.g., "other"). A typical size of a token vocabulary is N T are anywhere from 100,000 to several million separate tokens.

[0057]

[0076] In a preferred embodiment, the token encoder 74 encodes each token of the memory snapshot 54 as N T The snapshot 54 may then be represented as an array of vectors, with each vector ordered according to the position of the respective token in the snapshot 54. Similar to the event encoder 62, the token encoder 74 may further analyze each memory token in the context of other memory tokens that precede or follow the respective token in the memory snapshot 54. In such an embodiment, for each token, the encoder 74 may determine an embedding vector 66 that spans the space of memory contexts, such that two tokens that occur in mostly similar memory contexts are located relatively close together. Such a representation may be achieved by a token encoder that includes a neural network trained, for example, according to the word2vec or GloVe algorithms (see training details below).

[0058]

[0077] In some embodiments, the memory classifier 76 is configured to receive the memory embedding vectors 66 and determine the memory decision 58 according to the embedding vectors 66. The classifier 76 may include a set of artificial neural networks trained to distinguish between malicious and benign software entities according to the respective memory embedding vectors. An exemplary architecture of the classifier 76 may mimic the exemplary architecture of the behavior classifier 64 detailed above. For example, the memory classifier may comprise a CNN providing a fully connected layer followed by a ReLU and / or loss layer. In such an embodiment, the CNN may compute a representation of the memory snapshot 54 at a coarser granularity than the individual memory tokens by combining information from each token with information from a set of neighboring tokens (i.e., tokens located in the vicinity of the respective token in the memory snapshot 54). In an alternative embodiment, the output of the CNN is first fed to an RNN (e.g., an LSTM network), and then the output of the RNN is fed to a fully connected layer that substantially generates the decision 58. In some embodiments, the input to the RNN is organized according to the position of each token in memory snapshot 54, thus preserving token order. Due to the particular architecture of memory classifier 76, the RNN layer of memory classifier 76 analyzes each token in the context of adjacent tokens in memory snapshot 54.

[0059]

[0078] FIG. 13 illustrates an exemplary sequence of steps performed by the security module 44 according to some embodiments of the present invention. In step 202, the data extractor 46 obtains the event sequence 52. As explained above with respect to FIG. 4, the extractor 46 may listen to events in real time and / or extract information about the occurrence of various events from an event log. In some embodiments, the data extractor 46 maintains a list of currently running software entities and / or relationships between running software entities and organizes the detected events according to the identity of the entity that caused each detected event. Events may be accumulated in the queue until an accumulation condition is met. For example, events may be accumulated until a predetermined event count is reached and / or for a predetermined amount of time (e.g., 1, 10, or 30 seconds). Experiments with real data have shown that accumulating 10 seconds' worth of events may be optimal in the sense that the resulting event sequence allows for a good detection rate while keeping the false positive rate fairly low. Some embodiments detect the initiation of each monitored entity and then organize the event sequences according to the time elapsed between the occurrence of each event and the initiation of the respective entity. One such exemplary embodiment may generate a set of separate event sequences, a first sequence including events occurring within the first 10 seconds of execution of each entity, a second sequence including events occurring between 10 and 20 seconds after the initiation of each entity, and so on. The size of such time intervals may vary over time (e.g., the first time interval may be 1 second long, the second time interval 10 seconds long, etc.). Another exemplary embodiment samples events according to an internal clock of the security module 44 that is unaware of the initiation of each entity: events may be placed into equal-sized bins (e.g., 10-second intervals) and then sorted into event sequences according to which events were caused by which monitored entities.

[0060]

[0079] When the accumulation condition is met, in step 204, the data extractor 46 may sort the detected events to generate an event sequence 52 and further send the sequence 52 to the behavior analyzer 60. Some embodiments limit the size of the event sequence 52 (event count) to control the computational cost of malware detection. In one such example, when the count of events contributing to one monitored entity in an accumulation interval exceeds a threshold, only a subset of the respective events is included in the event sequence 52. The subset may be selected from the beginning of the accumulation interval, from the end of the accumulation interval, or both. Experiments have revealed that an event sequence with about 400 events is optimal in the sense of providing a compromise between detection performance (detection rate and / or false positive rate) and memory cost, so an exemplary event sequence 52 may be compiled, for example, from the first 200 events and the last 200 events of the respective time interval.

[0061]

[0080] At step 206, the security module 44 executes the behavior analyzer 60 to generate a behavior decision 56 indicating whether the respective monitored entity is likely to be malicious according to the event sequence 52. When the likelihood of maliciousness is low, some embodiments proceed to obtain another event sequence and / or load another queued event sequence onto the behavior analyzer 60.

[0062]

[0081] The decision 56 may include a number indicating a likelihood (e.g., probability) of maliciousness. Step 206 may then include comparing the value of the decision 56 with a predefined threshold and determining whether the monitored entity is malicious according to the result of said comparison. In one such example, the monitored process may be deemed malicious when the decision 56 indicates a probability of maliciousness greater than 0.8 (80%). When the monitored entity is malicious according to the behavior decision 56, in step 208, some embodiments may suspend the execution of the respective software entity. In another step 210, the data extractor 46 may extract a memory snapshot 54 including the contents of a set of memory regions including code and / or data belonging to the suspended monitored entity. The snapshot 54 is then sent to the memory analyzer 70 in step 212.

[0063]

[0082] Step 214 executes memory analyzer 70 to generate memory decision 58 according to snapshot 54. Step 214 may further include comparing decision 58 to another pre-set threshold to determine whether decision 58 is indicative of malicious intent. If not, some embodiments proceed to resume execution of the monitored entity and obtain a new event sequence.

[0064]

[0083] In some embodiments, when the memory determination 58 indicates that the monitored entity is likely malicious, step 216 implements malware mitigation procedures, such as quarantining / disabling / removing the monitored entity and notifying a user and / or system administrator of the client system 10.

[0065]

[0084] The above description has focused on an embodiment in which all components of the security module 44 are software running on the protected machine. Those skilled in the art will appreciate that such software configurations are not meant to be limiting. In an alternative embodiment running in a hardware virtualization embodiment (e.g., a cloud computing setting), the security module 44 runs in a separate virtual machine that is separate from the protected VM running the actual monitored software entity. In yet another alternative embodiment, some of the described components run remotely on the security server 12. In one such example shown in FIG. 14, the data extractor 46 runs on the client system 10 and extracts the event sequence 52 and / or memory snapshot 54. Meanwhile, the behavior analyzer 60 and / or memory analyzer 70 may run centrally on the server 12. Various parts of the analyzers 60 and 70 may run on separate machines and / or processors, for example in a parallel computing configuration. Such a configuration may have several advantages, such as having a centrally managed example of an AI security system serving multiple clients while avoiding the need to distribute many software updates to the clients. Another advantage of such an embodiment is that the computing resources required to determine items such as behavioral and memory decisions may be highly optimized for the task. For example, some neural networks may be hardwired as Field Programmable Gate Arrays - FPGAs or other Application Specific Integrated Circuits - ASICs, implemented in firmware, etc. Potential disadvantages of such configurations include the need to transmit relatively large amounts of data to the server 12.

[0066]

[0085] An exemplary operation of the non-localized computer security system as shown in FIG. 14 may include the data extractor 46 sending an encoding of the event sequence 52 (e.g., event embedding vector 65) to the server 12. A behavior analyzer 60 running on the server 12 may determine a behavior decision 56 according to the event sequence 52. When the decision 56 indicates a high probability of maliciousness, the server 12 may send a memory analysis request 57 to the client system 10, which may extract and send a memory snapshot 54 (e.g., token embedding vector) to the server 12. Thereafter, a memory analyzer 70 running on the server 12 may determine a memory decision 58 according to the snapshot 54. When the decision 58 indicates maliciousness, the server 12 may notify the respective client via a maliciousness indicator 80.

[0067]

[0086] The following description illustrates exemplary aspects of training the behavior analyzer 60 and / or memory analyzer 70 according to some embodiments of the present invention. To compute the embedding vectors 65 and / or 66, some embodiments utilize a neural network trained according to a version of the word2vec algorithm. Figures 15-16 illustrate an exemplary word2vec training procedure according to some embodiments of the present invention. Training here refers to adjusting a set of neural network parameters (e.g., weights, biases) in a direction that reduces a cost function. Training uses a pre-organized corpus of event sequences drawn from benign and / or malicious software entities.

[0068]

[0087] For simplicity, this description focuses exclusively on event sequences, but can be extended to memory tokens as well. In an exemplary training procedure, an event encoder 62 is paired with an event decoder and trained together, both of which may include portions of feedforward and / or recurrent neural networks. In general, the encoder-decoder pair inputs a first subset of training sequences (e.g., the central event E0) and a second subset of the respective sequences (e.g., some context event E i , i≠0). In the examples of FIGS. 15-16, the predictions are shown as one-hot vectors, alternative embodiments may use different representations. For example, the predictions may be E The second subset may be represented as a 1× vector, with each number indicating the likelihood that the corresponding event type is present in the second subset.

[0069]

[0088] In the skip-gram version of training shown in Figure 15, an encoder-decoder pair is trained to generate the correct event context given a central event E0. For each sequence of events drawn from the training event corpus, an encoder 62 is configured to input a one-hot encoding of the central event E0 and generate a corresponding embedding vector 65 that represents the event E0. A decoder 162 inputs the event vector 65 and generates the predicted context event E for each event sequence. i (i≠0), some embodiments then determine a cost function that characterizes the degree of mismatch between the predicted and actual contexts of each training event sequence. The prediction error is calculated according to any method known in the art of artificial intelligence, e.g., between the predicted and actual context events E iThe cost function may be calculated by determining a distance, such as the Levenshtein distance, Euclidean distance, cosine distance, between the inputs and outputs. Alternative embodiments may determine the cost function according to a cross-entropy measure. The encoder-decoder pair may then be trained by adjusting parameters of the encoder 62 and / or the decoder 162 in an attempt to reduce the cost function. Some exemplary algorithms used for training include backpropagation using gradient descent, simulated annealing, genetic algorithms, among others. Some embodiments continue training until a termination condition is met, e.g., until the average prediction error over the training event corpus falls below a predetermined threshold. In another embodiment, training proceeds for a predetermined amount of time or for a predetermined count of iterations / epochs.

[0070]

[0089] An alternative training procedure uses a successive bag-of-words paradigm, which aims to generate the correct center event E0 of a training sequence given its respective event context. In one such example shown in FIG. 16, an event encoder 62 encodes the context events E i 15, here the encoder 62 is paired with an event decoder 262 configured to input a set of one-hot vectors representing (i≠0) and output embedding vectors 65a-c determined for each context event. In contrast to the skip-gram embodiment shown in Fig. 15, here the encoder 62 is paired with an event decoder 262 configured to input a number of embedding vectors 65a-c and generate a prediction for a central event E0 of each training sequence. The encoder-decoder pair can then be trained by adjusting parameters of the encoder 62 and / or the decoder 262 in an attempt to reduce the prediction error, i.e. the mismatch between the predicted central event and the actual central event of each training sequence.

[0071]

[0090] The training behavior classifier 64 may include organizing a training corpus of event sequences originating from software entities known to be either malicious or benign, and adjusting the parameters (e.g., RNN weights) of the classifier 64 in a direction that minimizes misclassification. In some embodiments, incorporating the training event sequence includes launching each training entity and assigning all events occurring within each successive time interval (e.g., 10 second interval) into separate event bins. To mimic the way data is collected in real-world detection settings, the time delay between successive events may be artificially altered, for example increased to simulate the operation of a slower machine. After such time scale stretching and / or shrinking, some events may move between adjacent event bins. The training event sequence may then be replenished from each event bin.

[0072]

[0091] Some embodiments rely on the observation that when a software entity creates descendant entities (e.g., child processes) during execution, the descendants are most likely to be benign when the parent is indeed benign. Conversely, when the parent is malicious, the descendants are not necessarily malicious. Some embodiments therefore select benign event sequences from benign software entities as well as their descendants. On the other hand, some embodiments incorporate malicious event sequences only from entities known to be malicious. Such a training strategy may advantageously increase the size of the event corpus and thus improve the performance of the trained classifier.

[0073]

[0092] Training the memory classifier 76 may involve a similar process of compiling a training corpus of memory snapshots of software entities known to be either malicious or benign, and adjusting the parameters (e.g., CNN weights) of the classifier 76 in a direction that minimizes misclassification. Taking memory snapshots may involve suspending execution of the training entity at various instants following startup of the training entity, and copying the current contents of the training entity's memory space. Exemplary instants include instants immediately following startup of execution, and instants approximately 1, 3, and 6 seconds after startup. Some embodiments further rely on the observation that memory snapshots taken at the end of an entity's life are most likely to indicate a malicious indicator, if one is present. Thus, some embodiments detect an attempt to terminate a malicious entity, abort the termination, and in response, extract and label the current memory snapshot as malicious.

[0074]

[0093] The aforementioned exemplary systems and methods enable efficient detection of computer security threats such as malicious software and intrusions. The disclosed systems and methods propose a combinatorial statistical behavioral approach to computer security, where threats are detected by monitoring events occurring during software execution and analyzing the memory footprint of the respective software. Various experiments have been performed with the trained behavioral analyzer and memory analyzer as described herein. The recall / sensitivity rates of typical embodiments of the behavioral analyzer 60 vary between 96% and 99%, and the false positive rates are between 0.8% and 3% (values ​​vary according to the choice of architecture and training corpus). Similar values ​​for recall and false positive rates have been reported for several embodiments of the trained memory analyzer 70.

[0075]

[0094] While each method / analyzer may be used independently of the other to detect malicious software, some embodiments use a combination of the two to reduce the rate of false positive detections, i.e., to eliminate most cases where benign / legitimate software is erroneously classified as malicious by one or the other of the detection methods. Preferred embodiments may utilize a behavior classifier to monitor computing events. As long as the behavior classifier determines that the sequence of detected events is not indicative of malicious intent, some embodiments may continue execution of the software entity that caused the respective sequence of events. On the other hand, when the behavior classifier determines that the set or sequence of detected events indicates a significant likelihood of malicious intent, some embodiments ask the memory classifier to determine whether the respective software entity is malicious according to the contents of the memory space of the respective software entity. Some embodiments then label the suspicious software as truly malicious or non-malicious according to the determination made by the memory classifier. As an example, when the memory classifier determines that the monitored software entity is non-malicious, the security software resumes execution of the suspicious entity. Thus, some embodiments combine decisions obtained by separate methods and criteria to improve the efficiency of detection.

[0076]

[0095] Some conventional anti-malware solutions are known to combine multiple detection criteria, for example by determining multiple malware indication scores according to separate aspects and / or algorithms and combining the respective scores into an aggregate score. In contrast to such conventional approaches in which different detectors are used in parallel, in some embodiments of the present invention, behavior detection and memory analysis are deliberately applied in sequence with the explicit purpose of reducing the false alarm rate. In other words, the second detector is only required to double check cases classified as likely malicious by the first detector. In computer experiments, applying the analyzers and 60 and 70 in sequence as shown herein reduces the overall false positive detection rate by a factor of 20 to 30 to about 0.1%, while keeping the true detection rate above 98%.

[0077]

[0096] The order in which behavioral analysis and memory analysis are used is also purposefully chosen to reduce the computational cost of malware detection. Some embodiments rely on the observation that memory analysis usually requires significantly more computing resources than behavioral monitoring. Furthermore, extracting memory snapshots requires interrupting the execution of the monitored entity to ensure the integrity of the respective memory snapshots, thus affecting the user experience. On the other hand, event acquisition and behavioral analysis of event sequences can be performed in real time while the monitored software is running. Thus, some embodiments utilize behavioral analysis as the first step of malware detection, and only interrupt the execution of the monitored entity for memory analysis when behavioral analysis indicates a significant likelihood of malicious intent.

[0078]

[0097] In one particular example of an alternative embodiment shown in FIG. 17, the security module 44 is installed as an add-on to machines that already have a primary anti-malware engine 144 protecting the respective machine. The primary engine 144 may utilize any method known in the art, for example any combination of statistical and behavioral detection techniques, to determine whether a software entity is malicious. Meanwhile, the security module 44 may use a neural network classifier to provide a second opinion in a manner that reduces the false alarm rate. The engine 144 and the security module 44 may even be provided by two separate developers.

[0079]

[0098] FIG. 18 illustrates an exemplary sequence of steps performed by security module 44 in one such embodiment. Security module 44 may execute at a user level of processor privileges (e.g., ring 3). In a sequence of steps 232-234, security module 44 may listen for a notification indicating that a monitored entity is likely malicious. The notification may be explicitly generated by primary engine 144 or another software component in response to engine 144 indicating potential maliciousness. When such a notification is received, a sequence of steps 236-238 extracts a memory snapshot of each suspected entity. In another step 240, security module 44 may run memory analyzer 70 on the extracted snapshot. When memory determination 58 indicates that the suspected entity is indeed malicious, step 244 may implement mitigation. If not, in step 246, the suspected entity may be declared non-malicious and allowed to resume execution.

[0080]

[0099] In some embodiments, behavior detection involves analyzing a sequence of events that occur during the execution of a monitored software entity (e.g., a process, a virtual machine, etc.). Exemplary monitored events include, among others, process launches, attempts to access certain disk files or network locations, attempts to set operating system parameters, etc. Those skilled in the art will appreciate that the systems and methods described herein may be adapted to analyze other types of events, such as events related to a user's activity on social media, a user's browsing history, and a user's gaming activity, among others.

[0081]

[0100] Traditional behavioral malware detection typically relies on a predefined set of rules that must be devised, tested, and maintained by a human operator. However, malware often changes to evade detection, and traditional methods may struggle to keep up with the pace of change. In contrast, in some embodiments of the present invention, the behavioral and / or memory classifier includes a neural network classifier trained on a corpus of samples extracted from known malicious and / or non-malicious entities. The use of machine learning techniques and training on real data may ensure that a classifier built according to some embodiments of the present invention can detect malware-identifying patterns in data without the need to provide explicit rules. Furthermore, some embodiments iteratively retrain the classifier on samples of newly detected threats. The flexibility built into the neural network classifier may allow such a system to adapt to changes in malicious behavior much more quickly and at a much lower cost than a human operator could devise new malware detection heuristics.

[0082]

[0101] Some conventional computer security systems and methods largely analyze individual events to determine whether they indicate a security threat. However, many events that occur during the operation of a computer system (e.g., opening a file, accessing a web page) may not indicate malicious intent when treated in isolation, but may be malicious when occurring in the context of other events, e.g., as a sequence of specific actions. In contrast to more conventional solutions, some embodiments of the present invention explicitly analyze events in context and are therefore better suited to such event correlation situations. Preferred embodiments represent individual events as vectors in a multidimensional embedding space that have the distinct property that a pair of events that occur with a relatively high frequency in the same event context is separated by a shorter distance than another pair of events that occur less frequently in the same event context.

[0083]

[0102] Some embodiments of the behavioral and / or memory classifier as described herein implement specific neural network architectures, including convolutional and / or recurrent neural networks, among others. The choice of such architectures is intentional, as such configurations explicitly consider individual events and / or memory tokens in context, rather than in isolation, and are therefore particularly effective for malware detection. For example, because RNNs receive and process inputs as ordered sequences, a behavioral analyzer with an RNN determines whether a software entity is malicious according to not only the types of events that occur during the execution of the respective entity, but also the order in which the respective events occur, and the context of each event. Similarly, a memory analyzer with a convolutional neural network detects maliciousness according to not only the presence of certain tokens (e.g., text strings), but also the position of each token in the memory snapshot of the respective entity, and / or the relative positions of different tokens in the memory snapshot.

[0084]

[0103] It will be apparent to those skilled in the art that the above embodiments can be modified in many ways without departing from the scope of the present invention. Therefore, the scope of the present invention should be determined by the following claims and their legal equivalents.

Claims

1. 1. A computer system including at least one hardware processor, the at least one hardware processor comprising: Running a behavior analyzer to determine whether a software entity is malicious; determining that the software entity is not malicious when, in response to executing the behavior analyzer, the behavior analyzer indicates that the software entity is not malicious; responsive to executing the behavior analyzer, when the behavior analyzer indicates that the software entity is malicious, executing a memory analyzer to determine whether the software entity is malicious; determining that the software entity is malicious when, in response to executing the memory analyzer, the memory analyzer indicates that the software entity is malicious; determining that the software entity is not malicious when, in response to executing the memory analyzer, the memory analyzer indicates that the software entity is not malicious; It is configured as follows: The behavior analyzer includes: receiving a sequence of event indicators, each event indicator characterizing a distinct event resulting from execution of the software entity, the sequence of event indicators being ordered according to a time of occurrence of each distinct event; Determining whether the software entity is malicious according to the sequence of event indicators. a first neural network configured to The memory analyzer includes: receiving a sequence of token indicators, each token indicator characterizing a distinct string token extracted from the memory snapshot of the software entity, the sequence of token indicators being ordered according to a memory location of a respective string token; determining whether the software entity is malicious according to the sequence of token indicators; a second neural network configured to: Computer system.

2. 10. The computer system of claim 1, wherein the first neural network comprises a recurrent neural network.

3. 2. The computer system of claim 1, wherein the first neural network comprises a convolutional neural network.

4. 2. The computer system of claim 1, wherein the at least one hardware processor is further configured, in response to executing the behavior analyzer, to extract the memory snapshot when the behavior analyzer indicates that the software entity is malicious, and extracting the memory snapshot comprises: identifying memory pages within a memory of the computer system according to whether the memory pages are used by the software entity; copying a set of data from the memory page into the memory snapshot; 2. A computer system comprising:

5. 2. The computer system of claim 1, wherein extracting the memory snapshot comprises: identifying a first memory page within a memory of the computer system according to whether the first memory page currently stores header metadata of an executable file of the software entity; identifying a second memory page in the memory according to the header metadata; copying a set of data from the second memory page into the memory snapshot; 2. A computer system comprising:

6. 2. The computer system of claim 1, wherein the at least one hardware processor is further configured to construct the sequence of event indicators in preparation for executing the behavior analyzer, the constructing the sequence of event indicators comprising: determining an amount of time that has elapsed between a start of the execution of the software entity and the occurrence time of each of the distinct events; determining whether to include each of the event markers characterizing each of the distinct events within the sequence of event markers according to the amount of time; 2. A computer system comprising:

7. 2. The computer system of claim 1, wherein the at least one hardware processor is further configured to construct the sequence of event indicators in preparation for executing the behavior analyzer, the constructing the sequence of event indicators comprising: identifying a number of events that occur within a predetermined time interval during the execution of the software entity; ordering the plurality of events according to their occurrence times to generate an ordered sequence; in response to determining a count of the plurality of events, when the count exceeds a predetermined threshold, including within the sequence of event indicators a first set of indicators that characterize events belonging to a beginning of the ordered sequence and a second set of indicators that characterize events belonging to an end of the ordered sequence; 2. A computer system comprising:

8. 2. The computer system of claim 1, wherein the at least one hardware processor is further configured to generate each of the event indications utilizing a trained event encoder, training the event encoder comprising: coupling the event encoder to an event decoder, the encoder-decoder pair configured to receive a first subset of a training event sequence and to output a predicted subset of events; adjusting a set of parameters of the event encoder according to a difference between the predicted subset of events and a second subset of the training event sequence; 2. A computer system comprising:

9. 2. The computer system of claim 1, wherein each of the event indicators is determined according to a predefined event vocabulary, and each member of the event vocabulary characterized by a tuple consists of an event type occurring with at least another event feature.

10. 1. A method for detecting malware, comprising utilizing at least one hardware processor, running a behavior analyzer to determine whether the software entity is malicious; determining that the software entity is not malicious when, in response to executing the behavior analyzer, the behavior analyzer indicates that the software entity is not malicious; when the behavior analyzer indicates that the software entity is malicious in response to executing the behavior analyzer, executing a memory analyzer to determine whether the software entity is malicious; determining that the software entity is malicious when, in response to executing the memory analyzer, the memory analyzer indicates that the software entity is malicious; determining that the software entity is not malicious when, in response to executing the memory analyzer, the memory analyzer indicates that the software entity is not malicious; Includes implementing The behavior analyzer includes: receiving a sequence of event indicators, each event indicator characterizing a distinct event resulting from execution of the software entity, the sequence of event indicators being ordered according to a time of occurrence of each distinct event; Determining whether the software entity is malicious according to the sequence of event indicators. a first neural network configured to The memory analyzer includes: receiving a sequence of token indicators, each token indicator characterizing a distinct string token extracted from the memory snapshot of the software entity, the sequence of token indicators being ordered according to a memory location of a respective string token; determining whether the software entity is malicious according to the sequence of token indicators; a second neural network configured to: Malware detection methods.

11. 11. The method of claim 10, wherein the first neural network comprises a recurrent neural network.

12. 11. The method of claim 10, wherein the first neural network comprises a convolutional neural network.

13. 11. The method of claim 10, further comprising, in response to utilizing the at least one hardware processor to execute the behavior analyzer, when the behavior analyzer indicates that the software entity is malicious, extracting the memory snapshot, the step of extracting the memory snapshot comprising: identifying memory pages in a memory of a computer system according to whether the memory pages are used by said software entity; copying a set of data from the memory page into the memory snapshot; A method comprising:

14. 11. The method of claim 10, wherein the step of extracting a memory snapshot comprises: identifying a first memory page in a memory of the computer system according to whether the first memory page currently stores header metadata of an executable file of the software entity; identifying a second memory page in the memory according to the header metadata; copying a set of data from the second memory page into the memory snapshot; A method comprising:

15. 11. The method of claim 10, further comprising utilizing the at least one hardware processor to construct the sequence of event indicators in preparation for executing the behavior analyzer, the constructing the sequence of event indicators comprising: determining an amount of time that has elapsed between a start of the execution of the software entity and the occurrence time of each of the distinct events; determining whether to include each of the event markers characterizing each of the distinct events within the sequence of event markers according to the amount of time; A method comprising:

16. 11. The method of claim 10, further comprising utilizing the at least one hardware processor to construct the sequence of event indicators in preparation for executing the behavior analyzer, the constructing the sequence of event indicators comprising: identifying a number of events that occur within a predetermined time interval during said execution of said software entity; ordering the plurality of events according to their occurrence times to generate an ordered sequence; responsive to determining a count of the plurality of events, when the count exceeds a predetermined threshold, including within the sequence of event indicators a first set of indicators that characterize events belonging to a beginning of the ordered sequence and a second set of indicators that characterize events belonging to an end of the ordered sequence; A method comprising:

17. 11. The method of claim 10, further comprising utilizing the at least one hardware processor to execute a trained event encoder to generate each of the event indicators, the training of the event encoder comprising: coupling the event encoder to an event decoder, the encoder-decoder pair configured to receive a first subset of a training event sequence and to output a predicted subset of events; adjusting a set of parameters of the event encoder according to a difference between the predicted subset of events and a second subset of the training event sequence; A method comprising:

18. 11. The method of claim 10, wherein each of the event indicators is determined according to a predefined event vocabulary, each member of the event vocabulary characterized by a tuple consisting of an event type occurring with at least another event feature.

19. 1. A computer-readable medium storing instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to: Run a behavior analyzer to determine whether a software entity is malicious; determining that the software entity is not malicious when, in response to executing the behavior analyzer, the behavior analyzer indicates that the software entity is not malicious; in response to executing the behavior analyzer, when the behavior analyzer indicates that the software entity is malicious, executing a memory analyzer to determine whether the software entity is malicious; determining that the software entity is malicious when the memory analyzer indicates that the software entity is malicious in response to executing the memory analyzer; determining that the software entity is not malicious when, in response to executing the memory analyzer, the memory analyzer indicates that the software entity is not malicious; The behavior analyzer includes: receiving a sequence of event indicators, each event indicator characterizing a distinct event resulting from execution of the software entity, the sequence of event indicators being ordered according to a time of occurrence of each distinct event; Determining whether the software entity is malicious according to the sequence of event indicators. a first neural network configured to The memory analyzer includes: receiving a sequence of token indicators, each token indicator characterizing a distinct string token extracted from the memory snapshot of the software entity, the sequence of token indicators being ordered according to a memory location of a respective string token; determining whether the software entity is malicious according to the sequence of token indicators; a second neural network configured to: A computer-readable recording medium.

Images