HK1247295B - Computer security systems and methods using asynchronous introspection exceptions - Google Patents

Description

Computer security system and method using asynchronous self-test exceptions

Related applications

This application claims the benefit of U.S. Provisional Patent Application No. 62/192,384, filed on July 14, 2015, entitled “Computer Security Systems and Methods Using Asynchronous Introspection Exceptions,” which is hereby incorporated by reference in its entirety.

Technical Field

The present invention relates to computer security systems and methods, and in particular to systems and methods for protecting hardware virtualization environments from computer security threats.

Background Art

Malicious software (also known as malware) affects numerous computer systems worldwide. Malware, in its many forms (e.g., computer viruses, worms, rootkits, spyware, and unwanted adware), poses a serious risk to millions of computer users, exposing them to loss of data and sensitive information, identity theft, and loss of productivity.

Computer security software can be used to protect computer systems from malware. Common methods for detecting and combating malware include signature matching and behavioral approaches. Signature-based approaches attempt to match code segments of a target software entity with a collection of code snippets extracted from known malware. Behavioral approaches typically involve detecting the occurrence of events caused by or occurring during the execution of the target software entity and analyzing these events to determine whether they indicate a potential security threat.

Conventional event detection typically relies on methods known in the art, such as hooks. These methods are often vulnerable to attack and can be thwarted by malware. Furthermore, conventional behavioral methods often suspend the execution of the entity that caused the detected event while analyzing the corresponding event for malicious indicators. These pauses can negatively impact the user experience, especially in hardware virtualization configurations where security software executes outside of the protected virtual machine.

There is a continuing desire to improve the effectiveness of computer security systems and methods, and in particular to develop systems and methods that address the aforementioned shortcomings associated with event detection and analysis.

Summary of the Invention

According to one aspect, a host system includes a hardware processor and memory. The hardware processor is configured to execute a target entity, a synchronous exception analyzer, and an asynchronous exception analyzer. The hardware processor is further configured to, in response to detecting the occurrence of an event caused by the execution of the target entity, suspend the execution of the target entity and switch to executing the synchronous exception analyzer. The synchronous exception analyzer is configured to determine whether the target entity is suspected of being malicious based on the event. The synchronous exception analyzer is further configured to, in response, when the target entity is suspected of being malicious, selectively retrieve a rule exception signature from a plurality of rule exception signatures, the rule exception signature retrieved based on the event, wherein the rule exception signature includes an encoding of a first condition and an encoding of a second condition. The synchronous exception analyzer is further configured to, in response to retrieving the rule exception signature, determine whether the first condition is satisfied based on the event and based on the target entity. In response to determining whether the first condition is satisfied, the synchronous exception analyzer is further configured to cause the hardware processor to resume execution of the target entity if the first condition is satisfied. The synchronous exception analyzer is further configured to: in response to determining whether the first condition is satisfied, determine that the target entity is malicious when the first condition is not satisfied. The asynchronous exception analyzer is configured to: in response to the hardware processor resuming execution of the target entity, determine whether the second condition is satisfied based on the event and based on the target entity. The asynchronous exception analyzer is further configured to: in response to determining whether the second condition is satisfied, determine that the target entity is not malicious when the second condition is satisfied. The asynchronous exception analyzer is further configured to: in response to determining whether the second condition is satisfied, determine that the target entity is malicious when the second condition is not satisfied.

According to another aspect, a non-transitory computer-readable medium stores processor instructions that, when executed by a hardware processor of a host system, cause the host system to form a synchronous exception analyzer and an asynchronous exception analyzer. The hardware processor is further configured to, in response to detecting the occurrence of an event caused by execution of the target entity, suspend the execution of the target entity, and, in response to suspending the execution of the target entity, switch to executing the synchronous exception analyzer. The synchronous exception analyzer is configured to determine whether the target entity is suspected of being malicious based on the event. The synchronous exception analyzer is further configured to, in response, when the target entity is suspected of being malicious, selectively retrieve a rule exception signature from a plurality of rule exception signatures, the rule exception signature retrieved based on the event, wherein the rule exception signature includes an encoding of a first condition and an encoding of a second condition. The synchronous exception analyzer is further configured to, in response to retrieving the rule exception signature, determine whether the first condition is satisfied based on the event and based on the target entity. In response to determining whether the first condition is satisfied, the synchronous exception analyzer is further configured to cause the hardware processor to restart execution of the target entity when the first condition is satisfied. The synchronous exception analyzer is further configured to, in response to determining whether the first condition is satisfied, determine that the target entity is malicious when the first condition is not satisfied. The asynchronous exception analyzer is configured to, in response to the hardware processor restarting execution of the target entity, determine whether the second condition is satisfied based on the event and based on the target entity. The asynchronous exception analyzer is further configured to, in response to determining whether the second condition is satisfied, determine that the target entity is not malicious when the second condition is satisfied. The asynchronous exception analyzer is further configured to, in response to determining whether the second condition is satisfied, determine that the target entity is malicious when the second condition is not satisfied.

According to another aspect, a method for protecting a host system from computer security threats, wherein the host system includes a hardware processor and a memory. The method includes: using the hardware processor to detect the occurrence of an event caused by the execution of a target entity. The method further includes: in response to detecting the occurrence of the event, using the hardware processor to suspend the execution of the target entity and switch to executing a synchronous anomaly analysis program. The synchronous anomaly analysis program is configured to determine whether the target entity is suspected of being malicious based on the event. When the target entity is suspected of being malicious, in response, the synchronous anomaly analysis program is configured to selectively retrieve a rule anomaly signature from a plurality of rule anomaly signatures, the rule anomaly signature being retrieved based on the event, wherein the rule anomaly signature includes an encoding of a first condition and an encoding of a second condition. The synchronous anomaly analysis program is further configured to determine whether the first condition is satisfied based on the event and based on the target entity in response to retrieving the rule anomaly signature. The synchronous anomaly analysis program is further configured to, in response to determining whether the first condition is satisfied, cause the hardware processor to restart execution of the target entity when the first condition is satisfied, and determine that the target entity is malicious when the first condition is not satisfied. The method further includes, in response to the hardware processor restarting execution of the target entity, employing the hardware processor to determine whether the second condition is satisfied based on the event and based on the target entity. The method further includes, in response to determining whether the second condition is satisfied, determining that the target entity is not malicious when the second condition is satisfied, and determining that the target entity is malicious when the second condition is not satisfied.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and advantages of the present invention will become immediately better understood upon reading the following detailed description and upon reference to the accompanying drawings, in which:

FIG. 1 shows an exemplary hardware configuration of a host system protected from computer security threats according to some embodiments of the present invention.

FIG. 2-A shows an exemplary computer security application (CSA) protecting a host system according to some embodiments of the present invention in a configuration not involving hardware virtualization.

2-B shows an alternative configuration in which a set of exemplary protected virtual machines are exposed by a hypervisor executing on a host system and in which a CSA executes externally to the protected virtual machines, according to some embodiments of the invention.

FIG3 illustrates exemplary components of a computer security application according to some embodiments of the present invention.

FIG. 4-A shows an exemplary configuration in which a notification handler executes within a protected virtual machine and in which synchronous and asynchronous exception analyzers execute outside the protected virtual machine.

4-B shows an alternative configuration in which the notification handler executes outside the protected virtual machine and in which the synchronous and asynchronous exception analyzers execute within the protected virtual machine, according to some embodiments of the invention.

4-C shows yet another exemplary configuration in which the asynchronous exception analyzer executes within a secure virtual machine distinct from a protected virtual machine, according to some embodiments of the present invention.

FIG5 shows an exemplary interaction of components of a computer security application according to some embodiments of the invention.

FIG6 illustrates an exemplary format of a rule exception according to some embodiments of the present invention.

FIG7 shows an exemplary format of an exception analysis request (EAR) according to some embodiments of the invention.

FIG8 shows a series of exemplary steps performed by a notification handler according to some embodiments of the invention.

FIG. 9 shows a series of exemplary steps performed by a synchronization anomaly analysis program according to some embodiments of the present invention.

FIG. 10 shows a series of exemplary steps performed by an asynchronous exception analyzer according to some embodiments of the invention.

FIG. 11 illustrates a series of exemplary steps performed by a termination observation procedure according to some embodiments of the present invention.

DETAILED DESCRIPTION

In the following description, it should be understood that all of the connections between structures may be direct operational connections or indirect operational connections through intermediate structures. A group of elements includes one or more elements. Any reference to an element should be understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise required, any of the described method steps need not necessarily be performed in the specific order illustrated. A first element (e.g., data) derived from a second element encompasses a first element that is equal to the second element and a first element and optionally other data generated by processing the second element. Making a determination or decision based on a parameter encompasses making a determination or decision based on the parameter and, optionally, other data. Unless otherwise specified, an indicator of some quantity/data may be the quantity/data itself, or an indicator different from the quantity/data itself. Computer security encompasses protecting users and equipment from unintentional or unauthorized access to data and/or hardware, unintentional or unauthorized modification of data and/or hardware, and destruction of data and/or hardware. A computer program is a sequence of processor instructions that implements a task. The computer program described in some embodiments of the present invention may be an independent software entity or a sub-entity (e.g., a subroutine, a library) of another computer program. Unless otherwise specified, a process is an instance of a computer program, such as an application or part of an operating system, and is characterized by having at least one thread of execution and a virtual memory space assigned to the process, wherein the contents of the corresponding virtual memory space contain executable code. Unless otherwise specified, a guest process is a process executing within a virtual machine. A process is considered to be executing within a virtual machine when it executes on a virtual processor of the corresponding virtual machine. Unless otherwise specified, a page represents the smallest unit of virtual memory that can be individually mapped to the physical memory of the host system. Computer-readable media encompasses: non-transitory media, such as magnetic storage media, optical storage media, and semiconductor storage media (such as hard drives, optical disks, flash memory, DRAM); and communication links, such as conductive cables and fiber optic links. According to some embodiments, the present invention provides, among other things, a computer system comprising hardware (e.g., one or more microprocessors) programmed to perform the methods described herein, and computer-readable media encoding instructions for performing the methods described herein.

The following description illustrates embodiments of the invention by way of example and not necessarily by way of limitation.

FIG1 shows an exemplary hardware configuration of a host system 10 protected from computer security threats according to some embodiments of the present invention. Host system 10 can represent any electronic device having a processor and memory. Exemplary host systems 10 include: personal computers, servers, laptop computers, tablet computers, mobile telecommunication devices (e.g., smartphones), media players, TVs, game consoles, home appliances (e.g., refrigerators, thermostats, smart heating and/or lighting systems), and wearable devices (e.g., smart watches, sports and fitness equipment), among others.

FIG1 illustrates a computer system; the hardware configuration of other host systems (e.g., smartphones and smartwatches) may differ from the illustrated configuration. Host system 10 includes a set of physical devices, including a processor 12 and a memory unit 14. In some embodiments, processor 12 comprises a physical device (e.g., a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate, etc.) configured to perform computational and/or logical operations using a set of signals and/or data. In some embodiments, these operations are delivered to processor 12 in the form of a sequence of processor instructions (e.g., machine code or other type of encoding). Memory unit 14 may include volatile computer-readable media (e.g., DRAM, SRAM) that stores instructions and/or data accessed or generated by processor 12.

Depending on the type and capabilities of the devices, host system 10 may further include a set of input devices 16 (e.g., a keyboard, mouse, touch screen, etc.) to enable a user to enter data and/or instructions into host system 10. A set of output devices 18 (e.g., a monitor or liquid crystal display) can convey information to the user, for example, via a graphical user interface. Storage device 20 includes computer-readable media that enables non-volatile storage, reading, and writing of processor instructions and/or data. Exemplary storage devices 20 include magnetic and optical disks and flash memory devices, as well as removable media such as CD and/or DVD disks and drives. A set of network adapters 22 enables host system 10 to connect to a computer network and/or to other devices/computer systems. Controller hub 24 generally represents multiple system, peripheral, and/or chipset buses and/or all other circuitry that enables communication between processor 12 and devices 14, 16, 18, 20, and 22. For example, controller hub 24 may include a memory management unit (MMU), an input/output (I/O) controller, an interrupt controller, and the like. In another example, controller hub 24 may include a north bridge that connects processor 12 to memory 14 and/or a south bridge that connects processor 12 to devices 16, 18, 20, and 22. In some embodiments, controller hub 24 may be partially or fully integrated with processor 12, e.g., an MMU may share a common semiconductor substrate with processor 12.

Computer security application (CSA) 40 protects host system 10 from computer security threats, such as malware, spyware, unwanted adware, and the like. In some embodiments, CSA 40 is configured to monitor the behavior of multiple executable entities (e.g., processes, threads, applications, components of an operating system) and, based on their behavior, determine whether any of these monitored entities is malicious. Monitored entities may include components of an operating system and user applications, among others. In response to determining that an entity is malicious, CSA 40 may take protective action against the respective entity, such as stopping, isolating, or otherwise disabling the respective malicious entity.

Figures 2-A through 2-B illustrate exemplary software configurations according to some embodiments of the present invention. In the example of Figure 2-A, host system 10 executes an operating system (OS) 34, a set of exemplary application programs 36a-36b, and a CSA 40. Application programs 36a-36b generally represent any computer program, such as word processing, image processing, media player, database, calendar, personal contact management, browser, game, voice communication, and data communication applications. Operating system 34 may include any widely available operating system, such as Windows XP, Windows XP, or Windows XP Professional. OS 34 provides an interface between application programs 36a-36b and the hardware of host system 10. The illustrated location of CSA 40 indicates that CSA 40 can execute at various processor privilege levels. For example, portions of CSA 40 can execute at the processor privileges of the OS kernel (e.g., ring 0, kernel mode), while other portions can execute at the processor privileges of application programs 36a-36b (e.g., ring 3, user mode).

FIG2-B shows an alternative embodiment of the present invention, in which the host system 10 uses hardware virtualization technology to operate a set of guest virtual machines. Hardware virtualization is commonly used in applications such as cloud computing and server consolidation, as well as for other purposes. A virtual machine (VM) simulates an actual physical machine/computer system and is capable of running an operating system and other applications. In some embodiments, a hypervisor 30 is executed on the host system 10. The hypervisor 30 is configured to create or achieve multiple virtualized devices (e.g., virtual processors and virtual memory management units) and present these virtualized devices to other software in place of the real physical devices of the host system 10. These operations are generally referred to as public virtual machines in the art. The hypervisor 30 can further enable multiple virtual machines to share the hardware resources of the host system 10, so that each VM operates independently and is unaware of other VMs executing simultaneously on the host system 10. Examples of popular hypervisors include VMware vSphere ^™ and the open source Xen hypervisor from VMware, among others.

FIG2-B shows a set of guest VMs 32a-32b disclosed on a host system 10. Each VM 32a-32b includes a virtualized processor and may further include other virtualized devices, such as virtualized input, output, storage, and network devices, as well as virtualized controllers. Each virtualized processor includes a simulation of at least some of the functionality of the hardware processor 12 and is configured to receive processor instructions for execution. Software executed using a corresponding virtual processor is considered to be executed within the corresponding virtual machine. For example, in the example of FIG2-B, the guest OS 34a and application 36c are considered to be executed within the guest VM 32a. In contrast, the hypervisor 30 is considered to be executed outside of the guest VM 32a-32b or within the guest VM 32a-32b. Each virtualized processor can interact with these virtualized devices just as it would with a corresponding physical device. For example, software executing within VM 32a can send and/or receive network traffic via the virtualized network adapter of VM 32a. In some embodiments, hypervisor 30 may expose only a subset of virtualized devices to each guest VM and may give selected guest VMs direct and exclusive use of some hardware devices of host system 10. In one such example, VM 32a may have exclusive use of input device 16 and output device 18, but lack a virtualized network adapter. Meanwhile, VM 32b may have direct and exclusive use of network adapter 22. For example, these configurations may be implemented using techniques from

Each VM 32a-32b executes a guest operating system (OS) 34a-34b, respectively. Each OS 34a-34b provides an interface between applications 36c-36d executing within the respective VM and the virtualized hardware devices of the respective VM. In the exemplary embodiment of FIG2-B , CSA 40 executes externally to the guest VM and is configured to protect the respective guest VM from computer security threats. A single computer security application can protect multiple virtual machines. CSA 40 may, for example, be incorporated into hypervisor 30 as a library, or may be delivered as a computer program distinct and independent from hypervisor 30, but executed at the processor privilege level of hypervisor 30 (e.g., root mode, ring 1). CSA 40 may be a process with a separate, pre-scheduled thread of execution, or may operate as a non-pre-scheduled collection of code objects that executes when triggered by a specific notification event, as further illustrated below.

Several methods are known in the art for protecting host systems (including hardware virtualization platforms) from malware. One particular class of methods is known as behavioral analysis. Typical behavioral analysis methods employ a notification mechanism, whereby security software is notified of the occurrence of events within a monitored VM. These events are triggered by and/or occur during the execution of a software entity (e.g., an application or operating system component). The security software can then analyze the corresponding events to determine whether they indicate a potential security threat.

3 shows exemplary components of a computer security application 40 according to some embodiments of the present invention. Engine 40 includes a notification handler 42, a synchronous exception analyzer 44 connected to handler 42, an asynchronous exception analyzer 46, and a termination observer 48 communicatively coupled to analyzer 46.

In some embodiments, notification handler 42 is configured to detect the occurrence of specific events related to computer security. Exemplary detected events include calls to specific OS functions and system calls, among others. Other types of detected events may include: opening a file, creating a file, writing to a file, deleting a file, copying a file, creating a process, terminating a process, pre-scheduling a thread for execution, pausing a thread due to a synchronization event (e.g., mutual exclusion), creating a heap, allocating memory from the heap, expanding the size of the execution stack, changing memory access permissions, performing a swap-in (e.g., disk-to-memory) operation, performing a swap-out (e.g., memory-to-disk) operation, loading an executable module (e.g., a shared library - DLL), opening a registry key, renaming a registry key, detecting the attachment of a new hardware device, establishing a new network connection, receiving a network packet, elevating the execution privileges of a thread, changing the discretionary access control (DAC) permissions associated with a file. Several methods are known in the art for detecting these events. These include hooking specific OS functions, modifying the dispatch table, and so on. These methods configure processor 12 to switch from executing a triggering entity (e.g., a process) to executing a handler routine in response to the occurrence of a corresponding event. Registering notification handler 42 as a handler routine allows handler 42 to detect various events and communicate the occurrence of those events to CSA 40.

In hardware virtualization platforms, a special category of detected events that may be relevant to computer security includes detecting violations of memory access permissions. Detecting these violations provides an alternative to conventional hooking. Most modern computer systems are configured to operate with virtual memory and use specialized data structures (e.g., page tables) to manage memory address translation. Systems configured to support hardware virtualization typically use a second layer of address translation, translating from the guest physical memory visible to each public VM to the host system's actual physical memory 14. This second address translation is typically implemented using hardware-accelerated specialized data structures and a mechanism controlled by the processor 12, known as the Second Level Address Translation (SLAT). Popular SLAT implementations include the Extended Page Table (EPT) on the platform and the Rapid Virtualization Index (RVI)/Nested Page Table (NPT) on the platform. The SLAT typically allows memory access permissions, such as read/write/execute, to be set for each memory page. The processor 12 can be configured to trigger a processor event (e.g., a VM exit event or virtualization exception) when software attempts to access the corresponding page in a manner that violates the current access permissions. A VM exit event (e.g., VMExit on a platform) suspends execution of code within the corresponding VM and switches processor 12 to executing code at the level of hypervisor 30. In contrast, a virtualization exception (e.g., #VE on a platform) can switch processor 12 to executing code within the same VM. In some embodiments, CSA 40 registers notification handler 42 as the handler for VM exits (e.g., in a configuration such as FIG. 4-B ) or virtualization exceptions (e.g., in configurations such as FIG. 4-A and 4-C ). This enables handler 42 to detect attempts to violate memory access permissions within a protected virtual machine and communicate these attempts to CSA 40.

Conventional security systems often rely on malware behavioral signatures to detect malicious entities. A malware behavioral signature consists of a set of conditions that, when met by an event (or series of events), indicate that the entity that triggered the corresponding event is malicious. For example, injecting a code sequence that is subsequently written to disk can be considered an indicator of maliciousness. Malware behavioral signatures can achieve high detection rates, but they also typically produce relatively high false positive rates (benign entities are mistakenly labeled as malicious). Reducing the false positive rate can require increasing the complexity of the malware behavioral signature, which can substantially increase computational overhead.

Compared to such signature-based approaches, the present invention introduces a set of rule exceptions to replace or supplement malware behavior signatures. In some embodiments, a rule exception includes a set of conditions that, when satisfied by an <event, triggering entity> tuple, determine that the corresponding triggering entity is benign (non-malicious). An <event, triggering entity> tuple that satisfies the rule exception conditions is referred to herein as matching the corresponding rule exception. A typical usage scenario for these rule exceptions involves first applying a malware behavior signature to a detected event. When an event matches a signature indicating maliciousness, CSA 40 may further attempt to match the event against a set of rule exceptions. If no rule exceptions match the detected event, CSA 40 may infer that the triggering entity is indeed malicious. Conversely, if an event matches at least one rule exception, CSA 40 may infer that the triggering entity is benign. This analysis strategy can substantially reduce false positive rates while also controlling computational overhead. For example, the reduction in computational cost can be achieved by using simpler malware behavior signatures than conventional computer security systems.

Conventional behavioral security methods involve pausing the execution of a triggering entity while analyzing detected events. This type of event analysis is typically considered synchronous. In contrast, in some embodiments of the present invention, only a portion of the event analysis is performed synchronously, while another portion of the analysis is performed asynchronously. The term "asynchronous" is used herein to refer to a method of analyzing events and/or rule exceptions in which the triggering entity is allowed to continue executing while data regarding the corresponding events/exceptions is saved for later analysis.

In particular, in some embodiments of the present invention, some rule exception matches are performed synchronously, while other rule exception matches are performed asynchronously. The synchronous exception analyzer 44 can be configured to perform synchronous analysis on events occurring within a protected host system or guest VM to determine whether the event satisfies (matches) any one of a set of predetermined rule exceptions. A set of rule exceptions checked by the synchronous exception analyzer 44 is considered herein as synchronous exceptions (more details below). Synchronous exceptions typically include rule exceptions that have a relatively low computational cost to match with the event. In some embodiments, synchronous exceptions may include a subset of rule exceptions that are critical to assessing the security risks posed by the monitored entity. In another example, synchronous exceptions include rule exceptions whose checking relies solely on resources local to the host system 10 (for example, a signature database stored locally on the storage device 20).

Conversely, asynchronous exception analyzer 46 can be configured to perform asynchronous analysis on events occurring within a protected host system or guest VM to determine whether the event matches any of another set of predetermined rule exceptions. The set of rule exceptions checked by asynchronous exception analyzer 46 is referred to herein as asynchronous exceptions. In contrast to synchronous analysis, asynchronous analysis module 46 operates independently of the execution of the triggering entity, meaning that the triggering entity is allowed to continue executing while operations to match the triggered event with exceptions can be performed later. Asynchronous exceptions typically include rule exceptions that require a relatively high computational cost to match against the event, or rule exceptions that are not considered critical to the security of host system 10. Exemplary operations that form part of asynchronous exception matching include determining the integrity of the triggering entity (for example, using hash matching), performing remote scanning of the triggering entity (for example, by sending information about the corresponding entity to a remote cloud server that receives a malicious verdict from the corresponding server), and determining whether the triggering entity is the recipient of code injected by another entity, among other things.

Figures 4-A, 4-B, and 4-C illustrate various exemplary locations for a notification handler 42, a synchronous exception analyzer 44, and an asynchronous exception analyzer 46, according to some embodiments of the present invention. Those skilled in the art will appreciate that components 42, 44, and 46 can execute outside a protected VM (e.g., at the processor privilege level of hypervisor 30), within a protected VM (e.g., in kernel mode), or within a separate secure VM. Placing components within a protected VM allows the components to access a wealth of information about entities executing within the VM, but can make the components vulnerable to malware executing at the same processor privilege level. A set of techniques, such as alternating multiple EPT views based on #VE (virtualized exceptions) and VMFUNC on the platform, can be used to enhance the security of secure components placed within a protected VM. While components are relatively secure when executed outside a protected VM, certain operations required to parse the semantics of entities and events can be computationally intensive.

FIG4-A shows an exemplary configuration in which synchronous exception analyzer 44 executes outside of a protected guest VM, while FIG4-B and FIG4-C show that analyzer 44 executes in kernel mode within the corresponding guest VM. Given that synchronous processing pauses the execution of triggering entities and should therefore be as fast as possible to avoid impacting the user experience, a configuration in which synchronous exception analyzer 44's operation does not require a high cost to exit from the monitored VM is preferred. In a preferred embodiment, synchronous exception analyzer 44 can execute within the context of notification handler 42 (e.g., FIG4-C ).

The asynchronous exception analyzer 46 may be executed outside or inside the protected guest VM. In some embodiments (eg, see FIG. 4-C ), the analyzer 46 may be executed in a dedicated secure VM 33 exposed on the host system, the secure VM 33 being distinct from the protected guest VM.

Depending on the execution context of components 42, 44, 46, their operation may require complex signaling/messaging, sometimes across virtual machine boundaries. Such signaling may be implemented using any technique known in the art of hardware virtualization. For example, data may be transmitted via a memory segment shared between two components, and signaling may include a combination of VM exits and event injection.

FIG5 illustrates exemplary exchanges among components 42, 44, 46, and 48 according to some embodiments of the present invention. When a triggering entity causes an event to occur within a guest VM, the event causes an event notification 52 (e.g., a processor event, such as a VM exit or virtualization exception) to be delivered to handler 42. Handler 42 may then determine the type of event being notified and a set of parameters. Exemplary event types include code injection, specific system calls, disk file creation, and HTTP requests, among others. Event parameters may be unique to each type of notified event. Some exemplary event parameters include an identifier of the process or thread that caused the notified event (e.g., a process ID), a file name, a path, a memory address, and operands of a processor instruction, among others.

In some embodiments, handler 42 then passes event indicator 54 to synchronization exception analyzer 44. Event indicator 54 may include, among other things, a unique identifier for the corresponding event (event ID), an indicator of the event type, and a set of event parameters. Synchronization exception analyzer 44 may then attempt to match the corresponding event to a set of synchronization rule exceptions, for example, by querying exception knowledge base 50.

In some embodiments, the anomaly knowledge base 50 stores, for example, a set of rule anomaly entries on a computer-readable medium that forms part of or is communicatively coupled to the host system 10. FIG6 shows an exemplary format of a rule anomaly entry 60 according to some embodiments of the present invention. The anomaly entry 60 includes a synchronization flag 62 that may indicate whether the corresponding entry has an asynchronous portion. The entry 60 may further include an event type indicator 64 that indicates the type of event (e.g., a numeric ID associated only with each event type). The event type indicator 64 may allow the knowledge base 50 to selectively retrieve the rule anomaly entry based on the type of event detected. Alternatively, the knowledge base 50 may maintain an internal mapping (e.g., a hash index) that associates each rule anomaly entry with the event type associated with the corresponding rule anomaly.

Rule exception entry 60 may further include a synchronous exception signature 66 and an asynchronous exception signature 68. Signature 66 includes an encoding of a synchronous rule exception, i.e., an encoding of a set of conditions that are verified synchronously by analyzer 46. In contrast, asynchronous signature 68 includes an encoding of an asynchronous rule exception, i.e., an encoding of a set of conditions that are verified asynchronously by asynchronous exception analyzer 46.

When a rule exception entry associated with the current type of event being notified has an asynchronous portion, the synchronous exception analyzer 44 may insert an exception analysis request (EAR) 56 into an EAR list 58 for later processing (more details below). In some embodiments, the EAR list 58 includes a data structure having multiple entries, each encoding a request for an asynchronous rule exception match. The EAR list 58 may be organized as a multi-producer, multi-consumer queue (e.g., a first-in, first-out queue). FIG7 illustrates an exemplary format for an exception analysis request according to some embodiments of the present invention. The illustrated EAR includes only event IDs associated with the event that triggered the corresponding analysis. The EAR 56 may further include an exception ID that identifies only a specific entry 60 of the exception knowledge base 50. The EAR 56 may further include an indicator of the triggering entity. The inclusion of this entity ID in the EAR 56 may help the termination observer 48 determine whether there are any pending exception analysis requests associated with a specific execution entity (see more details below). In some embodiments, EAR 56 further includes various context data determined by notification handler 42 and/or synchronous exception analyzer 44, including information about the corresponding event and/or about the triggering entity. The context data may include a memory address, a process ID, the value of the instruction pointer (RIP) corresponding to the time when the triggered event occurred, and the like. This context data may be used by asynchronous exception analyzer 46 when performing asynchronous rule exception matching.

FIG8 shows a series of illustrative steps performed by notification handler 42 according to some embodiments of the present invention. As shown above, handler 42 executes in a location that allows handler 42 to effectively suspend execution of the triggering entity. For example, handler 42 can be registered as an event handler for VM exits and/or virtualization exceptions, where these processor events are triggered in response to the occurrence of specific monitored events caused by software (e.g., an attempt to access a specific memory page). In response to these events, processor 12 suspends execution of the triggering entity and switches to executing notification handler 42. Thus, notification handler 42 is notified of the occurrence of the monitored event while execution of the triggering entity is suspended. When the processor event is a VM exit, handler 42 can execute at the level of hypervisor 30.

When the handler 42 receives the event notification, a series of steps 106 to 108 determine the type of event that occurred within the protected guest VM and a set of parameters for the corresponding event. The handler 42 may then transmit the event indicator 54 to the synchronization exception analyzer 44 (step 110). In step 112, the handler 42 may wait for a release signal from the analyzer 44. In some embodiments, this release signal indicates that the current event has matched a synchronization rule exception, or that the EAR associated with the current event has been added to the EAR list 58 (see below for more details on FIG. 9). In response to receiving the release signal, the handler 42 may instruct the processor 12 to restart execution of the triggering entity.

FIG9 shows a series of exemplary steps implemented by the synchronous anomaly analyzer 44 according to some embodiments of the present invention. In response to receiving the event indicator 54 from the notification handler 42, step 124 performs a preliminary security assessment of the triggering entity. For example, the analyzer 44 may determine whether the corresponding event is indicative of malware. In some embodiments, step 124 attempts to match the current <event, entity> tuple with a set of malware behavior signatures. An example of such a malware-indicative signature includes a sequence of events: a first entity downloads an executable file without a valid digital signature, the first entity opens a second entity from the executable file, and the second entity attempts to register itself to start automatically at system startup. Another example of a malware behavior signature includes: a driver attempts to overwrite a system service descriptor table (SSDT) entry. When the preliminary assessment indicates that the triggering entity is unlikely to be malicious, the analyzer 44 may signal the notification handler 42 to restart execution of the triggering entity (see above).

When the preliminary assessment indicates that the triggering entity is suspected of being malicious, step 126 selectively retrieves a set of rule exception entries from anomaly knowledge base 50 based on the event type of the current event. When knowledge base 50 does not contain any rule exception entries associated with the type of the current event, CSA 40 may take anti-malware action against the triggering entity in step 130. This protective action may include terminating, isolating, or otherwise disabling the triggering entity, reverting a set of changes made to host system 10 due to the execution of the triggering entity, and so on. In some embodiments, CSA 40 maintains a set of malware-indicative scores associated with each monitored entity. Step 130 may include incrementing the respective scores by an amount that may be specific to the event. CSA 40 may further compare the scores to a threshold and take anti-malware action only if, for example, the scores exceed a predetermined threshold.

When the knowledge base 50 contains at least one rule exception entry 60 associated with the event type of the current event, step 131 determines whether the current event matches the synchronization rule exception of the corresponding rule exception entry. Step 131 may include testing whether the <current event, triggering entity> tuple satisfies a set of conditions encoded by the synchronization signature 66 of the corresponding rule exception. Thus, step 131 may include performing a set of calculations, for example, to determine the entity type of the triggering entity based on the event indicator 54. Exemplary entity types include a specific component of the OS 34, an instance of a specific application (e.g., ), a specific class of entity (e.g., a file manager, a browser), etc. Other instance types of entities include drivers, shared libraries (e.g., dynamic link libraries (DLLs), and injected code segments.

When no synchronization signature match is found, the analyzer 44 infers that the triggering entity is indeed malicious and proceeds to step 130 described above. When the current event matches the synchronization signature of at least one rule exception, in step 134, the analyzer 44 determines whether the corresponding rule exception entry also includes an asynchronous signature. In some embodiments, step 134 includes checking the value of the synchronization flag 62 (see Figure 6). When "no", the analyzer 44 signals the handler 42 to restart the execution of the triggering entity. When "yes", step 136 determines context data about the current event and/or about the triggering entity. Another step 138 formulates the EAR 56 and adds the EAR 56 to the EAR list 58. The synchronization exception analyzer 44 may then signal the handler 42 to restart the execution of the triggering entity.

FIG10 shows a series of exemplary steps performed by this instance of asynchronous exception analyzer 46. In some embodiments, computer security application 40 manages a pool of threads for asynchronous rule exception matching. The threads of the pool can execute outside of a protected VM, within a protected VM, or within a separate secure VM (e.g., see FIG4-C ). When these threads execute within the respective protected VMs, they can execute in kernel mode (ring 0). CSA 40 can start an instance of asynchronous exception analyzer 46 whenever a thread from the pool becomes available.

In a series of steps 142 through 144, asynchronous exception analyzer 46 determines whether any outstanding exception analysis requests currently exist. When EAR list 58 is not empty, analyzer 46 may remove an EAR from list 58 and attempt to match the event indicated by the corresponding EAR with the asynchronous rule exception indicated by the corresponding EAR. Step 148 may include further determining event parameters and/or information about the entity that triggered the corresponding event. For example, these calculations may include hash calculations, memory queries, establishing filiation relationships between various software entities (e.g., this process has spawned other processes), simulations, etc. In some embodiments, step 148 includes exchanging data with a remote security server (cloud scanning).

In some embodiments, when the corresponding event matches the asynchronous rule exception, analysis program 46 ends. Terminating the current instance of analysis program 46 indicates that the corresponding event does not indicate a computer security threat and, therefore, the corresponding event no longer needs to be analyzed. When analysis program 46 determines that the event does not match the corresponding asynchronous rule exception, step 152 may signal CSA 40 to take protective anti-malware action (see step 130 in FIG. 9 above).

In alternative embodiments, asynchronous rule exceptions are formulated such that a match indicates that the corresponding entity is malicious. In these embodiments, when an event does not match a corresponding rule exception, the analyzer 46 may terminate, and when an event does match a corresponding rule exception, the CSA 40 may take anti-malware action.

11 shows a series of illustrative steps performed by termination observer 48 according to some embodiments of the present invention. Termination observer 48 may execute outside of or within a protected virtual machine and be communicatively coupled with at least asynchronous exception analyzer 46.

Because asynchronous rule exception analysis is independent of the execution of the triggering entity, situations may arise in which the triggering entity terminates execution before the asynchronous exception analyzer 46 begins processing an exception analysis request related to the corresponding entity. In these situations, the malicious entity may escape detection or may cause some irreversible damage. To prevent these situations, in some embodiments of the present invention, the termination observer 48 detects attempts by the OS to terminate the entity (steps 162 to 164). Detecting the termination attempt can effectively pause the execution of the terminating entity. Step 162 may include cooperating with the notification handler 42, for example, the handler 42 may actually detect the termination attempt and signal the termination observer 48.

In response to detecting a termination attempt, termination observer 48 may determine, in a series of steps 166 through 168, whether there are any outstanding exception analysis requests for the terminating entity. If not, step 170 may instruct processor 12 to resume execution of the terminating entity, effectively allowing the corresponding entity to terminate. In some embodiments, step 170 includes sending a release signal to notification handler 42, thereby instructing handler 42 to release the terminating entity.

When EAR list 58 contains at least one EAR associated with a terminating entity, termination observer 48 may maintain the corresponding entity in a suspended state until all such pending requests are processed. A series of steps 172 through 174 cause requests associated with the corresponding terminating entity to be processed (the series of steps may be repeated until all such requests are processed). Step 174 may include invoking asynchronous exception analyzer 46 to process each outstanding EAR associated with the terminating entity. When analyzer 46 determines that an event indicated by the corresponding EAR does not match an asynchronous rule exception indicated by the corresponding EAR, step 178 may signal CSA 40 to take protective action against the terminating entity (see above with respect to Figures 9-10).

The exemplary systems and methods described above enable efficient behavioral monitoring of software entities. In some embodiments, a notification mechanism is deployed to detect the occurrence of security-related events within a protected host system or virtual machine and report the events to security software. The security software then analyzes the events to determine whether they indicate a computer security threat, such as malware, spyware, or unauthorized intrusion.

Some conventional behavioral systems and methods rely on malware behavioral signatures to determine whether an entity is malicious. Malware behavioral signatures typically include a set of conditions that, when satisfied by an <event, entity> tuple, determine that the corresponding event indicates maliciousness, and therefore the software entity that triggered the corresponding event is likely malicious. To prevent the triggering entity from carrying out its malicious activities, conventional systems and methods suspend the execution of the triggering entity while analyzing the triggered event for indicators of maliciousness.

Some embodiments of the present invention rely on two observations. First, not all occurrences of a particular type of event are equally indicative of malware. The same type of event (e.g., accessing a URL, opening a disk file, etc.) may indicate malware in some scenarios and be completely benign in others. In one such example, an event may not indicate malware when viewed in isolation, but may be indicative of malware when occurring as part of a specific series of events. For example, writing to a disk file may be a benign operation when viewed in isolation (i.e., many processes and applications legitimately access disks). However, when the entity performing the write is the recipient of code injected from another entity, the write event may become suspicious. This observation suggests that successful malware detection may require a fairly complex malware behavioral signature capable of distinguishing between the various scenarios described above. Using such complex behavioral signatures often carries a relatively high computational cost. Furthermore, optimizing malware behavioral signatures to achieve high detection rates often results in an increase in false positive detections (benign events are incorrectly classified as indicative of malware, and legitimate entities are incorrectly classified as malicious). False positive classifications are particularly undesirable in the field of computer security because they can lead to data loss and loss of user productivity.

A second observation is that pausing the execution of the triggering entity for the entire duration of malware behavioral signature matching negatively impacts the user experience. This is particularly true in the case of complex behavioral signatures and in hardware virtualization configurations where event analysis is performed at a location external to the VM where the event occurred (e.g., at the hypervisor level).

In contrast to such conventional computer security systems and methods, some embodiments supplement malware behavior signatures with a set of rule anomaly signatures. A rule anomaly signature comprises a set of conditions that, when satisfied by an <event, entity> tuple, determine that the corresponding event is benign, and therefore that the triggering entity is not malicious. Thus, rule anomalies provide an encoding of an exception to a rule that would normally indicate malicious behavior. In an exemplary use case scenario, the security software may first attempt to match the detected event against a set of relatively simple, computationally inexpensive malware behavior signatures to determine whether the triggering entity is likely to be malicious. When "yes", the security software may further attempt to match the corresponding event against a set of rule anomaly signatures. A rule anomaly signature match may indicate that the triggering entity is, in fact, benign.

Adding rule anomaly signatures creates the opportunity to use relatively simple signatures rather than the fairly complex signatures that would be necessary when using only malware behavior signature matching.Thus, some embodiments reduce the computational overhead incurred by security software while also reducing false positive detection rates.

Furthermore, in some embodiments of the present invention, matching of rule anomaly signatures is performed at least partially asynchronously, i.e., while the entity that triggered the corresponding event is allowed to continue executing. By choosing not to suspend execution of the triggering entity for the entire duration of the security analysis, the impact on the user experience can be significantly reduced. In some embodiments, rule anomaly signatures are optimized for low overhead: signatures with relatively low computational cost are used in synchronous matching, while signatures with relatively high cost are used in asynchronous matching.

While there are some similarities between regular malware behavior signatures and rule-based anomaly signatures, their usage and semantics are very different. For example, it's incorrect to say that rule-based anomaly signatures are simply the complement or opposite of malware behavior signatures. Malware behavior signatures and rule-based anomaly signatures are not mutually exclusive. For example, when an event matches a malware behavior signature, it doesn't mean it can't also match a rule-based anomaly signature. On the contrary, it's in situations where an event matches both a malware behavior signature and a rule-based anomaly signature that rule-based anomaly signatures are most valuable, as they allow for an efficient decision-making process for malware detection.

An example of synchronous rule exceptions versus asynchronous rule exceptions and their correlation with malware behavior signatures includes detecting attempts by monitored software entities to patch the code of shared executable modules (e.g., libraries). Code patching generally indicates malicious intent and, therefore, can be encoded in malware behavior signatures. Whenever code patching is detected, a malware alert can be triggered using the corresponding signature. However, for example, various software entities (e.g., the OS) can perform legitimate code patching when starting a new process. Similarly, a process from a given software application suite (e.g., ) can legitimately patch another process from the same suite. In some embodiments of the present invention, rule exceptions can be used to address these situations. An exemplary synchronous rule exception can check whether the patching process is one of the trusted OS processes and whether the target process (the process being patched) is started. If both conditions are met, the patching entity is considered benign (legitimate). Thus, when the OS starts the process and performs the patch, it can proceed without being blocked by CSA 40. In contrast, according to the above rule exception, if an unknown process attempts to perform the same patch operation, it will be blocked. To allow patching of some unknown processes, some embodiments may use a two-part rule exception signature: a synchronous part may verify the identity of the entity involved in the code patching, while an asynchronous part may verify the injected buffer/code itself (e.g., by decomposing the code and/or searching for specific code patterns within the code). When the injected code is not malicious, the unknown process may be considered benign.

In another example, a malware behavior signature may indicate that a code injection is indicative of malware. A synchronous rule exception signature may allow code injection when the process performing the injection is well-known and trusted. However, the same rule exception signature may have an asynchronous portion that performs content analysis on the injected code. When the content appears unusual for that particular process, the corresponding process may be deemed malicious. In this example, the content analysis, which is relatively expensive in terms of computational overhead, is performed asynchronously (i.e., while the corresponding process is executing) to minimize the impact on the user experience.

In yet another example, a malware behavior signature may indicate that an attempt by a browser to load a plug-in is indicative of malware. However, some plug-ins are benign and should be allowed to operate. In an exemplary embodiment, a synchronous rule exception may test whether the corresponding plug-in is digitally signed by a particular authority, and when "yes", determine that the browser is benign. In the event that the synchronous signature matches, the browser may be allowed to load and execute the plug-in. Then, another rule exception may asynchronously determine whether the certificate used to sign the plug-in is currently valid or has been revoked. When the corresponding certificate has been revoked, the CSA 40 may terminate the browser and/or display a warning. Testing certificate validity typically requires sending a request to a remote server, and therefore can substantially impact the user experience if done synchronously.

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 invention. Therefore, the scope of the invention should be determined by the appended claims and their legal equivalents.

Claims (19)

1. A host system comprising a hardware processor and a memory, the hardware processor being configured to execute a target entity, a synchronous exception analyzer, and an asynchronous exception analyzer, wherein the hardware processor is further configured to: In response to detecting an event caused by the execution of the target entity, the execution of the target entity is suspended, and In response to pausing the execution of the target entity, the execution of the synchronization anomaly analysis program is switched to proceed. The synchronization anomaly analysis program is configured to: Based on the events described, determine whether the target entity is suspected of malicious intent. In response, when the target entity is suspected of malicious activity, a rule-specific abnormal signature is selectively retrieved from multiple rule-specific abnormal signatures. This rule-specific abnormal signature is retrieved based on the event, and it includes the encoding of a first condition and the encoding of a second condition. In response to the retrieval of the rule-abnormal signature, it is determined, based on the event and the target entity, whether the first condition is met. In response to determining whether the first condition is met, if the first condition is met, the hardware processor is caused to restart the execution of the target entity, and In response to determining whether the first condition is met, if the first condition is not met, it is determined that the target entity is malicious; and The asynchronous exception analyzer is configured to: In response to the hardware processor resuming execution of the target entity, it is determined, based on the event and the target entity, whether the second condition is satisfied. In response to determining whether the second condition is met, if the second condition is met, it is determined that the target entity is not malicious. In response to determining whether the second condition is met, if the second condition is not met, it is determined that the target entity is malicious. 2. The host system according to claim 1, wherein: The synchronous anomaly analysis procedure is further configured to: in response to determining whether the first condition is met, insert an analysis request into a request queue when the first condition is met, the analysis request being formulated based on the second condition, based on the event, and further based on the target entity; and The asynchronous exception analysis program is further configured to remove the analysis request from the request queue when it is ready to determine whether the second condition is met. 3. The host system according to claim 1, wherein the hardware processor is further configured to: In response to detecting an attempt to terminate the target entity, the attempt is suspended; and In response to pausing the attempt, switching to execution of a termination watch connected to the asynchronous exception analyzer, the termination watch being configured to: The search request queue is used to obtain a second analysis request based on the target entity, the second analysis request indicating a third condition. The asynchronous exception analyzer is invoked to process the second analysis request, and In response to the invocation of the asynchronous exception analyzer, when the asynchronous exception analyzer determines that the third condition is met, the hardware processor causes the hardware processor to restart the attempt to terminate the target entity. 4. The host system of claim 1, wherein the target entity is executed within a guest virtual machine exposed by the host system, and wherein the asynchronous exception analyzer is executed outside the guest virtual machine. 5. The host system according to claim 1, wherein the asynchronous exception analyzer is executed within a secure virtual machine exposed by the host system, and the secure virtual machine and the guest virtual machine are executed simultaneously. 6. The host system of claim 1, wherein the rule exception signature is configured such that the computational cost of determining whether the first condition is met is lower than the computational cost of determining whether the second condition is met. 7. The host system of claim 1, wherein the event includes an attempt to access the memory in a manner that violates memory access permissions. 8. The host system according to claim 1, wherein: Determining whether the first condition is met includes determining whether the target entity has injected code into the second entity; and Determining whether the second condition is met includes determining whether the code is malicious. 9. A non-transitory computer-readable medium storing processor instructions, said processor instructions, when executed by a hardware processor of a host system, causing the host system to form a synchronous exception analyzer and an asynchronous exception analyzer, said hardware processor being configured to: In response to detecting an event caused by the execution of the target entity, the execution of the target entity is suspended, and In response to pausing the execution of the target entity, the execution of the synchronization anomaly analysis program is switched to proceed. The synchronization anomaly analysis program is configured to: Based on the events described, determine whether the target entity is suspected of malicious intent. In response, when the target entity is suspected of malicious activity, a rule-specific abnormal signature is selectively retrieved from multiple rule-specific abnormal signatures. This rule-specific abnormal signature is retrieved based on the event, and it includes the encoding of a first condition and the encoding of a second condition. In response to the retrieval of the rule-abnormal signature, it is determined, based on the event and the target entity, whether the first condition is met. In response to determining whether the first condition is met, if the first condition is met, the hardware processor is caused to restart the execution of the target entity, and In response to determining whether the first condition is met, if the first condition is not met, it is determined that the target entity is malicious; and The asynchronous exception analyzer is configured to: In response to the hardware processor resuming execution of the target entity, it is determined, based on the event and the target entity, whether the second condition is satisfied. In response to determining whether the second condition is met, if the second condition is met, it is determined that the target entity is not malicious. In response to determining whether the second condition is met, if the second condition is not met, it is determined that the target entity is malicious. 10. The computer-readable medium according to claim 9, wherein: The synchronous anomaly analysis procedure is further configured to: in response to determining whether the first condition is met, insert an analysis request into a request queue when the first condition is met, the analysis request being formulated based on the second condition, based on the event, and further based on the target entity; and The asynchronous exception analysis program is further configured to remove the analysis request from the request queue when it is ready to determine whether the second condition is met. 11. The computer-readable medium of claim 10, wherein the hardware processor is further configured to: In response to detecting an attempt to terminate the target entity, the attempt is suspended; and In response to pausing the attempt, switching to execution of a termination watch connected to the asynchronous exception analyzer, the termination watch being configured to: The request queue is searched to obtain a second analysis request based on the target entity, the second analysis request indicating a third condition. The asynchronous exception analyzer is invoked to process the second analysis request, and In response to the invocation of the asynchronous exception analyzer, when the asynchronous exception analyzer determines that the third condition is met, the hardware processor causes the hardware processor to restart the attempt to terminate the target entity. 12. The computer-readable medium of claim 9, wherein the target entity is executed within a guest virtual machine exposed by the host system, and wherein the asynchronous exception analyzer is executed outside the guest virtual machine. 13. The computer-readable medium of claim 12, wherein the asynchronous exception analyzer is executed within a secure virtual machine exposed by the host system, the secure virtual machine being executed simultaneously with the guest virtual machine. 14. The computer-readable medium of claim 9, wherein the rule-based exception signature is configured such that the computational cost of determining whether the first condition is satisfied is lower than the computational cost of determining whether the second condition is satisfied. 15. The computer-readable medium of claim 9, wherein the event includes an attempt to access the memory of the host system in a manner that violates memory access rights. 16. The computer-readable medium according to claim 9, wherein: Determining whether the first condition is met includes determining whether the target entity has injected code into the second entity; and Determining whether the second condition is met includes determining whether the code is malicious. 17. A method for protecting a host system from computer security threats, the host system including a hardware processor and memory, the method comprising: The hardware processor is used to detect the occurrence of events caused by the execution of the target entity; In response to the detection of the event, the hardware processor is used to suspend the execution of the target entity; In response to pausing the execution of the target entity, the hardware processor is switched to execute a synchronous exception analyzer configured to: Based on the events described, determine whether the target entity is suspected of malicious intent. In response, when the target entity is suspected of malicious activity, a rule-specific abnormal signature is selectively retrieved from multiple rule-specific abnormal signatures. This rule-specific abnormal signature is retrieved based on the event, and it includes the encoding of a first condition and the encoding of a second condition. In response to the retrieval of the rule-abnormal signature, it is determined, based on the event and the target entity, whether the first condition is met. In response to determining whether the first condition is met, if the first condition is met, the hardware processor is caused to restart the execution of the target entity, and In response to determining whether the first condition is met, if the first condition is not met, it is determined that the target entity is malicious; In response to the hardware processor restarting the execution of the target entity, the hardware processor is used to determine whether the second condition is satisfied based on the event and based on the target entity; In response to determining whether the second condition is met, if the second condition is met, it is determined that the target entity is not malicious; and In response to determining whether the second condition is met, if the second condition is not met, it is determined that the target entity is malicious. 18. The method of claim 17, further comprising: In response to determining whether the first condition is met, if the first condition is met, the hardware processor is used to insert an analysis request into a request queue, the analysis request being formulated based on the second condition, the event, and further, the target entity; and When preparing to determine whether the second condition is met, the hardware processor is used to remove the analysis request from the queue. 19. The method of claim 18, further comprising: In response to detecting an attempt to terminate the target entity, the hardware processor is used to suspend the attempt; In response to pausing the attempt, the hardware processor is used to search the request queue to obtain a second analysis request based on the target entity, the second analysis request indicating a third condition; In response to the discovery of the second analysis request, it is determined whether the third condition is met based on the target entity; In response, when the third condition is met, the hardware processor is used to terminate the target entity.