HK1216930B - Process evaluation for malware detection in virtual machines - Google Patents

Description

Process Evaluation for Malware Detection in Virtual Machines

Technical Field

The present invention relates to a system and method for protecting a computer system from malware attacks, and more particularly to an anti-malware system using hardware virtualization technology.

Background Art

Malicious software (malware) affects a large number of computer systems worldwide. In its many forms, such as computer viruses, worms, and rootkits, malware poses a serious threat to millions of computer users, exposing them to data and sensitive information loss, identity theft, and productivity loss.

Hardware virtualization technology allows the creation of simulated computer environments, often called virtual machines, that behave in many ways like physical computer systems. In typical applications, such as server consolidation and Infrastructure as a Service (IaaS), several virtual machines can run simultaneously on the same physical machine, sharing hardware resources between them and thus reducing investment and operating costs. Each virtual machine can run its own operating system and/or software applications independently of the other virtual machines. Due to the steady proliferation of malware, each virtual machine operating in such an environment potentially requires malware protection.

Virtualization solutions commonly used in the field include a hypervisor (also known as a virtual machine monitor), which consists of a software layer that operates between the computing hardware and the virtual machine's operating system (OS) and has more processor privileges than the corresponding OS. Because some malware (e.g., rootkits) operate at the OS privilege level, it is advantageous to develop anti-malware solutions that execute at the hypervisor's privilege level.

Summary of the Invention

According to one aspect, a host system includes at least one processor configured to execute: a hypervisor configured to expose a virtual machine; a process evaluator executing within the virtual machine; a memory introspection engine executing external to the virtual machine; and a process scoring module. The process evaluator is configured to determine whether an evaluated process executing within the virtual machine performs an action, and in response, transmits a first process evaluation indicator to the process scoring module when the evaluated process performs the action, the first process evaluation indicator being determined for the evaluated process. The memory introspection engine is configured to intercept calls to operating system functions to detect the launch of a protected process executing within the virtual machine, wherein the operating system function is configured to add the protected process to a list of processes executing within the virtual machine, and in response to detecting the launch, determine whether the evaluated process attempts to modify a memory page of the protected process, and in response, transmits a second process evaluation indicator to the process scoring module when the evaluated process attempts to modify the memory page, the second process evaluation indicator being determined for the evaluated process. The process scoring module is configured to receive the first and second process evaluation indicators and, in response, determine whether the evaluated process is malicious based on the first and second process evaluation indicators.

According to another aspect, a non-transitory computer-readable medium encodes instructions that, when executed on a host system comprising at least one processor, cause the host system to form: a hypervisor configured to expose a virtual machine; a process evaluator executing within the virtual machine; a memory introspection engine executing external to the virtual machine; and a process scoring module. The process evaluator is configured to determine whether an evaluated process executing within the virtual machine performs an action, and in response, transmit a first process evaluation indicator to the process scoring module when the evaluated process performs the action, the first process evaluation indicator being determined for the evaluated process. The memory introspection engine is configured to intercept a call to an operating system function to detect the launch of a protected process executing within the virtual machine, wherein the operating system function is configured to add the protected process to a list of processes executing within the virtual machine, and in response to detecting the launch, determine whether the evaluated process attempts to modify a memory page of the protected process, and in response, transmit a second process evaluation indicator to the process scoring module when the evaluated process attempts to modify the memory page, the second process evaluation indicator being determined for the evaluated process. The process scoring module is configured to receive the first and second process evaluation indicators and, in response, determine whether the evaluated process is malicious based on the first and second process evaluation indicators.

According to another aspect, a method includes, using at least one processor of a host system, receiving a first process evaluation indicator determined for an evaluated process, the evaluated process executing within a virtual machine exposed by a hypervisor executing on the host system. The method further includes, using the at least one processor, receiving a second process evaluation indicator determined for the evaluated process, and in response to receiving the first and second process evaluation indicators, using the at least one processor to determine whether the evaluated process is malicious based on the first and second process evaluation indicators. Determining the first process evaluation indicator includes determining, using a process evaluator executing within the virtual machine, whether the evaluated process performs a first action. Determining the second process evaluation indicator includes determining, using a memory introspection engine executing external to the virtual machine, whether the evaluated process performs a second action.

According to another aspect, a method includes, using at least one processor of a host system to execute a memory introspection engine, the memory introspection engine executing outside of a virtual machine exposed by a hypervisor executing on the host system, wherein executing the memory introspection engine includes detecting the launch of a process executing within the virtual machine. The method further includes, in response to the memory introspection engine detecting the launch of the process, determining, using the at least one processor, first and second process evaluation indicators for the process. The method further includes, in response to determining the first and second evaluation indicators, determining, using the at least one processor, whether the process is malicious based on the first and second process evaluation indicators.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and advantages of the present invention will be better understood after reading the following detailed description and after referring to the accompanying drawings, in which:

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

2 shows an exemplary set of virtual machines exposed by a hypervisor executing on the host system of FIG. 1 , and a security application operating in conjunction with a memory introspection engine to protect the virtual machines, according to some embodiments of the present invention.

3 illustrates an exemplary hierarchy of software objects executing on a host system at various processor privilege levels, including a set of anti-malware objects according to some embodiments of the present invention.

4 shows an exemplary process scoring module that receives a plurality of process evaluation indicators determined for a process by a plurality of process evaluators, according to some embodiments of the invention.

FIG. 5 shows an exemplary sequence of steps performed by the process scoring module of FIG. 4 , according to some embodiments of the present invention.

6 shows an exemplary mapping of memory addresses in the system configuration of FIG. 2 , according to some embodiments of the present invention.

Figure 7 illustrates an exemplary execution flow of a collection of processes in an environment. Solid arrows indicate the exemplary execution flow in the absence of an anti-malware system. Dashed arrows indicate modifications to the execution flow introduced by a plurality of process evaluators operating in accordance with some embodiments of the present invention.

8 illustrates an exemplary sequence of steps performed by the memory introspection engine of FIGs. 2-3, according to some embodiments of the invention.

9 shows an exemplary sequence of steps performed by a memory introspection engine to protect a memory page, according to some embodiments of the invention.

FIG. 10 illustrates an exemplary configuration including multiple host systems connected to a secure server via a computer network.

11 shows an exemplary anti-malware transaction between a host system and a secure server according to some embodiments of the present invention.

DETAILED DESCRIPTION

In the following description, it should be understood that all enumerated connections between structures may be direct operational connections or indirect operational connections through intermediary structures. An element set includes one or more elements. Any enumeration of elements should be understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise required, any described method steps do not necessarily need to be performed in the specific order described. A first element (e.g., data) derived from a second element encompasses a first element that is equal to the second element, as well as 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 a parameter and optionally based on 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. Unless otherwise specified, a process represents an example of a computer program, wherein a computer program is a sequence of instructions that determines a computer system to perform a specified task. Unless otherwise specified, a page represents the smallest unit of virtualized physical memory that is individually mapped to the physical memory of a computer system. Computer-readable media encompasses non-transitory media such as magnetic, optical, and semiconductor storage media (e.g., hard drives, optical disks, block flash memory, DRAM), as well as 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 processors) programmed to perform the methods described herein and a computer-readable medium encoding instructions to perform 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 that performs anti-malware operations according to some embodiments of the present invention. Host system 10 may represent a corporate computing device (e.g., an enterprise server) or an end-user device (e.g., a personal computer or smartphone, etc.). Other host systems include entertainment devices, such as televisions and game consoles, or any other device with memory and a processor that supports virtualization and requires malware protection. FIG1 shows a computer system for illustrative purposes; other client devices (e.g., mobile phones or tablet computers) may have different configurations. In some embodiments, system 10 includes a collection of physical devices, including a processor 12, a memory unit 14, a collection of input devices 16, a collection of output devices 18, a collection of storage devices 20, and a collection of network adapters 22, all connected by a collection of buses 24.

In some embodiments, processor 12 comprises a physical device (e.g., a multi-core integrated circuit) configured to perform computations and/or logical operations using signals and/or data sets. In some embodiments, such logical operations are delivered to processor 12 in the form of a sequence of processor instructions (e.g., machine code or other software type). Memory unit 14 may comprise volatile computer-readable media (e.g., RAM) that stores data/signals accessed or generated by processor 12 during the execution of instructions. Input devices 16 may include a computer keyboard, mouse, microphone, etc., including corresponding hardware interfaces and/or adapters that allow a user to enter data and/or instructions into system 10. Output devices 18 may include a display device (e.g., a monitor and speakers, etc.), as well as hardware interfaces/adapters (e.g., a graphics card) that allow system 10 to communicate data to the user. In some embodiments, input devices 16 and output devices 18 may share common hardware, as is the case in the case of a touchscreen device. Storage device 20 comprises computer-readable media that enables non-volatile storage, reading, and writing of software instructions and/or data. Exemplary storage devices 20 include magnetic and optical disks and flash memory devices, as well as removable media (e.g., CD and/or DVD disks and drives). A collection of network adapters 22 enables system 10 to connect to a computer network and/or other devices/computer systems. Bus 24 collectively represents multiple system, peripheral, and chipset buses, and/or all other circuitry that enables intercommunication among devices 12-22 of host system 10. For example, bus 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-22, and so on.

FIG2 shows an exemplary set of guest virtual machines 32a-b executing on a host system 10 and exposed by a hypervisor 30, according to some embodiments of the present invention. A virtual machine (VM) is generally referred to in the art as a software emulation of an actual physical machine/computer system, each capable of running its own operating system and software independently of other VMs. Hypervisor 30 includes software that allows multiple virtual machines to multiplex (share) the hardware resources of host system 10, such as processor operations, memory, storage, input/output, and networking devices. In some embodiments, hypervisor 30 enables multiple virtual machines and/or operating systems (OSs) to run simultaneously on host system 10 with varying degrees of isolation. To achieve such a configuration, the software component of hypervisor 30 may generate multiple virtualized (i.e., software-emulated) devices, each emulating a physical hardware device of system 10, such as processor 12 and memory 14, etc. Hypervisor 30 may further assign a set of virtual devices to each VM operating on host system 10. Thus, each VM 32a-b operates as if it had its own collection of physical devices, ie, as a more or less complete computer system. Examples of popular hypervisors include VMware vSphere ^™ from VMware Inc, and the open-source Xen hypervisor, among others.

In some embodiments, hypervisor 30 includes a memory introspection engine 40 that is configured to perform anti-malware operations, as described further below. Engine 40 may be incorporated into hypervisor 30, or may be delivered as a software component distinct and independent from hypervisor 30, but executing at a substantially similar processor privilege level as hypervisor 30. A single engine 40 may be configured to protect multiple VMs executing on host system 10 from malware.

Although FIG2 shows only two VMs 32a-b for simplicity, host system 10 can execute a large number (e.g., hundreds) of VMs simultaneously, and the number of such VMs can change during operation of host system 10. In some embodiments, each VM 32a-b executes a guest operating system 34a-b and/or a collection of software applications 42a-b, 42c, and 44, respectively, simultaneously and independently of other VMs running on host system 10. Each OS 34a-b includes software that provides an interface to the (virtualized) hardware of the respective VM 32a-b and serves as a host for software applications executing on the respective OS. Operating systems 34a-b can include any widely available operating system, such as iOS or Android ^™ , among others. Applications 42a-c can include word processing, image processing, database, browser, and electronic communication applications, among others. In the following description, software executing on a virtual processor of a virtual machine is said to be executing within the respective virtual machine. 2, application 42b is said to be executing within VM 32a, while application 42c is said to be executing within VM 32b. In contrast, memory introspection engine 40 is said to be executing external to VMs 32a-b.

2 , a security application 44 is executed on guest OS 34 b, with application 44 being configured to perform anti-malware (AM) operations (as described below) in conjunction with memory introspection engine 40 to protect virtual machine 32 b from malware. In some embodiments, an instance of application 44 may be executed on each of a plurality of VMs operating on host system 10, each such instance being configured to interface with introspection engine 40 to protect the respective virtual machine. Security application 44 may be a standalone program, or may form part of a software suite that includes anti-malware, anti-spam, and anti-spyware components, among others.

Figure 3 illustrates a hierarchy of software objects executing on a host system 10 according to some embodiments of the present invention. Figure 3 is presented from the perspective of processor privilege levels, also known in the art as layers or protection rings. In some embodiments, each such layer or protection ring is characterized by a set of instructions that allow execution of software objects executing at the corresponding processor privilege level. When a software object attempts to execute an instruction that is not allowed within the corresponding privilege level, the attempt may trigger a processor event, such as an exception, fault, or virtual machine exit event. In some embodiments, switching between privilege levels may be accomplished via a set of specialized instructions. Such exemplary instructions include SYSCALL/SYSENTER, which switches from user level to kernel level; SYSRET/SYSEXIT, which switches from kernel level to user level; VMCALL, which switches from user level or kernel level to root level; and VMRESUME, which switches from root level to kernel level or user level.

In some embodiments, hypervisor 30 controls processor 12 at the highest privilege level (e.g., VMX root on platforms that support virtualization, and also referred to as ring-1 or root mode), thereby creating a hardware virtualization platform that appears as virtual machines 32 to other software executing on host system 10. An operating system 34 (e.g., OS 34 a-b in FIG. 2 ) executes within the virtual environment of VM 32, with OS 34 having fewer processor privileges (e.g., ring 0, or kernel mode, on Intel platforms) than hypervisor 30. A collection of application programs 42 d-e executes with fewer processor privileges (e.g., ring 3, or user mode) than OS 34.

In some embodiments, portions of security application 44 may execute at user-level processor privileges (i.e., at the same level as applications 42d-e). For example, such portions may include a graphical user interface that notifies the user of any malware or security threats detected on the respective VM and receives input from the user indicating, for example, desired configuration options for application 44. Another example of a component executing at user level is a user-level process evaluator, as described in detail below. Other portions of application 44 may execute at kernel privilege levels. For example, application 44 may install an anti-malware driver 36 and a process scoring module 38, both of which operate in kernel mode. The exemplary AM driver 36 provides functionality to anti-malware application 44, for example, to scan memory for malware signatures and/or detect malware-indicative behavior in processes and/or other software objects executing on OS 34.

In some embodiments, the process scoring module 38 is configured to receive process evaluation data from a plurality of software components, determine the process evaluation data for an evaluated process, and determine whether the evaluated process is malicious based on the corresponding data. A process is an example of a computer program (e.g., an application or part of an operating system) and is characterized by having at least one thread of execution and a segment of virtual memory assigned to the at least one thread of execution by the operating system, the segment comprising executable code. In some embodiments, the operating system manages the processes currently executing on the host system 10 (or within the virtual machine 32 (in the case of virtualization)), such management including, among other things, assigning virtual memory to each process and scheduling each process or its thread for execution.

FIG4 shows an exemplary process scoring module 38 that receives a plurality of process evaluation indicators 52a through d, each of which is determined by a process evaluator component. In FIG4 , this evaluation component includes a user-level process evaluator 50a, a kernel-level process evaluator 50b, and a system call evaluator 50c, among others. Evaluators 50a through c may be established by or form part of the anti-malware driver 36. Each of these evaluators may execute independently of the other evaluators and may each determine a plurality of different process evaluation indicators for the evaluated process. The operation of evaluators 50a through c will be described in further detail below. In some embodiments, some process evaluation indicators (e.g., indicators 52a through c in FIG4 ) are determined by components executing within the VM 32, while other process evaluation indicators (e.g., 52d) are determined by components executing outside the VM 32 (e.g., by the memory introspection engine 40).

Some evaluation indicators may be malware-indicative (i.e., may indicate that the evaluated process is malicious). Some evaluation indicators may not be malware-indicative on their own, but may be indicative of maliciousness when combined with other evaluation indicators. Each evaluation indicator 52a-d may be determined according to different methods or criteria. Exemplary process evaluation indicators determined for an evaluated process may include, for example, a behavior indicator indicating whether the evaluated process performs or attempts to perform a particular action (e.g., edits a system register key of VM 32 or writes to a memory page belonging to a protected software object). Another exemplary process evaluation indicator may indicate whether a segment of memory belonging to the evaluated process contains a malware-indicative signature. In some embodiments, each process evaluation indicator 52a-d includes a process identification indicator (e.g., a process ID, a tag, or a hash index) to allow module 38 to identify the process for which the corresponding indicator is determined.

In some embodiments, a process evaluation indicator may include a numerical score determined by a corresponding process evaluator that indicates the degree of maliciousness of the corresponding process. Alternatively, such a score may be determined by module 38 based on process evaluation indicators 52a-d. The maliciousness score may be binary (1/0, yes/no) or may vary within a continuous range of values. An exemplary maliciousness score that may vary within a range of values includes a number (e.g., a probability) indicating the likelihood that the evaluated process is malicious; such a score may vary, for example, between 0 and 1 or between 0% and 100%. The score values may be behavior-specific. For example, an evaluated process may receive a maliciousness score of 0.2 when it creates a disk file and a maliciousness score of 0.7 when it modifies a Windows registry value.

FIG5 shows an exemplary sequence of steps performed by process scoring module 38 according to some embodiments of the present invention. In step 302, module 38 receives process evaluation indicators (e.g., indicators 52a-d in FIG4 ) from a process evaluator, which may be operable within VM 32 (see, for example, evaluators 50a-c in FIG4 ) or outside VM 32 (e.g., memory introspection engine 40). In step 304, module 38 may identify the process for which the corresponding process evaluation indicator was determined. In some embodiments, process scoring module 38 may save a per-process record of all process evaluation indicators received from the various process evaluators; step 304 may further include adding the indicator received in step 302 to the record of the corresponding process.

To determine whether the evaluated process is malicious, in step 306, the process scoring module 38 may determine a cumulative score by combining the individual scores determined for the corresponding process and received from various process evaluators. Exemplary cumulative scores include a weighted sum and a weighted average of the individual scores. In some embodiments, the cumulative score may combine the process evaluation indicator/score determined for the evaluated process with process evaluation indicators/scores determined for other processes or software objects. For example, the score determined for the evaluated process may be combined with scores determined for child processes of the evaluated process and/or with a score determined for the parent process of the evaluated process.

In step 308, module 38 may compare the cumulative score to a predetermined threshold. If the cumulative score does not exceed the threshold, module 38 may return to step 302 described above. In some embodiments, the threshold may be set to a value determined based on input received from a user of the corresponding VM (e.g., via a user interface exposed by security application 44). The threshold may reflect the security preferences of the corresponding user. For example, when the user selects tight security, the threshold may be set to a relatively low value; when the user prefers a more permissive security setting, the threshold may be set to a relatively high value. In some embodiments, the threshold may be received from a remote security server, as described below with respect to Figures 10 and 11.

In some embodiments, in steps 306-308, process scoring module 38 may determine multiple cumulative scores and compare each cumulative score to a (possibly different) threshold. Each such cumulative score may be determined based on a different subset of process evaluation indicators. In an exemplary embodiment, each such set of process evaluation indicators may represent a particular class or type of malware (e.g., Trojans, rootkits, etc.), thereby allowing module 38 to perform classification of the detected malware.

When the cumulative score exceeds a threshold, module 38 may determine that the evaluated process is malicious and may take anti-malware action in step 310. In some embodiments, such anti-malware action may include, among other things, terminating the evaluated process, isolating the evaluated process, and removing or disabling the source of the evaluated process (e.g., a file or memory segment). In some embodiments, the anti-malware action may further include alerting a user of host system 10, and/or alerting a system administrator, for example, by sending a message to the system administrator via a computer network connected to host system 10 via network adapter 22. In some embodiments, the anti-malware action may also include sending a security report to a remote security server, as described below with respect to Figures 10-11.

3-4 operates at an OS processor privilege level (e.g., kernel mode) within VM 32. In alternative embodiments, process scoring module 38 may execute in user mode within VM 32, or even operate outside VM 32 at the processor privilege level of hypervisor 30.

In some embodiments, introspection engine 40 executes at substantially the same privilege level as hypervisor 30 and is configured to perform introspection of a virtual machine (e.g., VM 32). Introspection of a VM, or software objects executing on a respective VM, may include analyzing the behavior of the software objects, determining and/or accessing memory addresses of such software objects, restricting access of certain processes to the contents of memory located at such addresses, analyzing such contents, and determining a process evaluation indicator (e.g., indicator 52d in FIG. 4 ) for the respective software objects. In some embodiments, software objects that are targets of introspection engine 40 include, among others, processes, instruction streams, registers and data structures (e.g., page tables), and driver objects for the respective VM.

To perform introspection of VM 32 from outside the corresponding VM, some embodiments of engine 40 utilize memory mapping structures and mechanisms of processor 12. Virtual machines typically operate with virtualized physical memory (i.e., a virtual representation of actual physical memory 14 of host system 10). Virtualized physical memory comprises a contiguous space of virtualized addresses, specific to each guest VM executing on host system 10, with portions of the corresponding space mapped to addresses within physical memory 14 and/or physical storage devices 20. In systems configured to support virtualization, this mapping is typically implemented via dedicated data structures controlled by processor 12, such as extended page tables (EPTs) or nested page tables (NPTs). In such systems, virtualized physical memory may be divided into units known in the art as pages. A page represents the smallest unit of virtualized physical memory that is individually mapped to physical memory via mechanisms such as the EPT and/or NPT. That is, mapping between physical and virtualized physical memory is performed using a page granularity. All pages typically have a predetermined size, such as 4 kilobytes, 2 megabytes, and so on. The division of virtualized physical memory into pages is typically configured by the hypervisor 30. In some embodiments, the hypervisor 30 also configures the EPT/NPT and, therefore, the mapping between physical memory and virtualized physical memory. The actual translation of the virtualized memory address to the physical memory address may include looking up the physical memory address in a translation lookaside buffer (TLB) of the host system 10. In some embodiments, address translation includes performing a page walk, which includes a set of consecutive address lookups in a set of page tables, and performing calculations (e.g., adding a page offset to an address associated with the corresponding page).

Some hardware configurations allow the hypervisor 30 to selectively control access to the data stored within each page, for example, by setting read and write access permissions for the corresponding page. For example, such permissions can be set by modifying the entry for the corresponding page within the EPT or NPT. The hypervisor 30 can thus select which software objects can access the data stored at the address within each page and can indicate which operations are allowed on the corresponding data, such as reads, writes, etc. An attempt by a software object executing within a VM to perform an operation (e.g., read data from or write data to a page for which the object does not have the corresponding permissions) can trigger a virtual machine exit event (e.g., a VM exit event on an Intel platform). In some embodiments, the virtual machine exit event transfers control of the processor from the VM executing the corresponding software object to the hypervisor 30 or memory introspection engine 40, thereby allowing the hypervisor 30 and/or engine 40 to intercept and analyze unauthorized read/write attempts.

In some embodiments, OS 34 configures a virtual memory space (also referred to as a logical address space) and exposes the virtual memory space to applications, such as applications 42d through e and 44 in FIG 3. In such systems, OS 34 configures and maintains a mapping between the virtual memory space and the virtualized physical memory of VM 32, for example, using a page table mechanism. In some embodiments, the virtual memory space is further divided into pages, which represent the smallest unit of virtual memory that is individually mapped to virtualized physical memory by OS 34 (virtual-to-virtualized physical memory mapping is performed with the aid of a page granularity).

FIG6 illustrates an exemplary mapping (translation) of memory addresses according to the embodiment shown in FIG2 . A software object (e.g., an application or process executing within VM 32a) is assigned a virtual address space 214a by guest OS 34a. When the corresponding software object attempts to access an exemplary memory address 60a of space 214a, the virtualization processor of guest VM 32a translates address 60a into an address 60b within virtualized physical memory space 114a of virtual machine 32a according to a page table configured and controlled by guest OS 34a. Address 60b is also referred to in the art as a guest-physical address. Hypervisor 30 (which configures and controls virtualized physical memory 114a) maps address 60b to address 60c within physical memory 14 of host system 10, for example, using the EPT or NPT approach discussed above.

Similarly, virtual memory space 214b is established by guest OS 34b for applications (e.g., 42c) or other software objects executing on guest VM 32b. An exemplary virtual address 60d within space 214b is translated by the virtualization processor of guest VM 32b into address 60e within virtualized physical memory space 114b of guest VM 32b according to a page table configured and controlled by guest OS 34b. Address 60e is further mapped by hypervisor 30 to address 60f within physical memory 14.

In some embodiments, the hypervisor 30 establishes its own virtual memory space 214c (including a representation of physical memory 14) and uses a translation mechanism (e.g., a page table) to map addresses in space 214c to addresses in physical memory 14. In Figure 6, such an exemplary mapping translates address 60g to address 60h. Similarly, addresses in physical memory 14 (e.g., 60c and 60f) correspond to addresses 60k and 60m, respectively, within the hypervisor's 30 virtual memory space 214c. This translation allows the hypervisor 30 to manage (e.g., read, write, and control access to) memory pages belonging to software objects executing within the various VMs running on the host system 10.

FIG7 illustrates an exemplary execution flow of a set of processes 70a-b executed on VM 32 according to some embodiments of the present invention. The example of FIG7 shows the execution flow in a system running a version of OS; similar diagrams may be presented for other operating systems (e.g., Linux). Solid arrows represent the execution flow in the absence of an anti-malware system (e.g., security application 44). Dashed arrows represent modifications to the flow due to the presence of a process evaluator executed according to some embodiments of the present invention.

Process 70a includes multiple dynamic link libraries (DLLs) 72a through c; in the example of FIG. 7 , DLL 72c is injected into process 70a by (possibly malicious) process 70b. Code injection is a general term used in the art to refer to a family of methods for introducing a code sequence (e.g., a DLL) into the memory space of an existing process to alter the original functionality of the corresponding process. When process 70a executes an instruction requiring some system functionality (e.g., writing something to a disk file or editing a registry key), the corresponding instruction calls a user-mode API (e.g., KERNEL32.DLL or NTDLL.DLL). In the example of FIG. 7 , the corresponding user-mode API call is intercepted and analyzed by user-level behavior filter 50a. This interception can be achieved through methods such as DLL injection or hooking. Hooking is a general term used in the art for methods for intercepting function calls, messages, or events passed between software components. One exemplary hooking method involves changing the entry point of a target function by inserting instructions that redirect the execution of a second function. Following this hook, the second function may be executed instead of the target function, or before the target function. In the example of FIG7 , the anti-malware driver 36 may hook into certain functions in KERNEL32.DLL or NTDLL.DLL, thereby instructing the corresponding functions to redirect execution to the filter 50a. Thus, the filter 50a can detect that the process 70a is attempting to perform a specific behavior identified based on the function being redirected. When the filter 50a detects this behavior, the filter 50a may formulate a process evaluation indicator 52a ( FIG4 ) and transmit the indicator 52a to the process scoring module 38.

In a typical execution flow, user-mode API functions may request services from the operating system's kernel. In some embodiments, such operations are performed by issuing system calls (e.g., SYSCALL and SYSENTER on x86 platforms). In the example of FIG. 7 , such system calls are intercepted by a system call evaluator 50c. In some embodiments, this interception includes, for example, modifying a system call handler routine by changing values stored in mode-specific registers (MSRs) of the processor 12, effectively redirecting execution to the filter 50c. Such techniques are known in the art as MRS hooking and can allow the system call evaluator 50c to detect that an evaluated process is attempting to execute certain system calls. When such a system call is intercepted, the system call filter 50c may generate a process evaluation indicator 52c and transmit the indicator 52c to the process scoring module 38.

Following the system call, control of the processor is typically transferred to the kernel of the OS 34. In some embodiments, the kernel-level process evaluator 50b is configured to intercept certain operations of the OS kernel and, therefore, determine that the evaluated process is attempting to perform certain operations (which may be malicious). To intercept such operations, some embodiments may use a set of filtering mechanisms built into and disclosed by the OS 34. For example, in the Windows OS, FltRegisterFilter may be used to intercept operations such as creating a file, opening a file, writing a file, and deleting a file. In another example, the evaluator 50b may use ObRegisterCallback to intercept create or copy object disposal operations, or use PsSetCreateProcessNotifyRoutine to intercept the creation of a new process. In another embodiment, CmRegisterCallbackEx may be used to intercept Windows registry operations (e.g., creating and setting registry keys/values). Similar filtering mechanisms for other operating systems (e.g., ) are known in the art. When kernel mode process evaluator 50b intercepts such an operation, evaluator 50b may formulate a process evaluation indicator 52b and transmit indicator 52b to process scoring module 38 .

To transfer data (e.g., process evaluation indicators 52a-c) from evaluators 50a-c to scoring module 38, one skilled in the art may use any inter-process communication method. For example, to communicate between user-mode components and kernel-mode components, evaluators 50a-c and module 38 may be configured to use a shared section of memory.

FIG8 shows an exemplary sequence of steps performed by memory introspection engine 40 according to some embodiments of the present invention. In step 312, engine 40 may detect the launch of a process within VM 32 that requires protection from malware (hereinafter referred to as a protected process). In some embodiments, such protected processes include, among others, processes belonging to security application 44.

To detect the launch of a protected process, the engine 40 may use data structures and/or mechanisms native to the OS 34. For example, some versions of the OS manage processes using a list of active processes maintained by the kernel. Each time a process is created, an indicator for the corresponding process is inserted into the active process list; when the corresponding process terminates, the indicator is removed from the list. In some embodiments, the kernel of the OS 34 represents each process as a data structure (e.g., an executing process block (EPROCESS) in Windows) that includes, among other things, a handle for each of the corresponding process's threads and a unique process ID that allows the OS 34 to identify the corresponding process from multiple executing processes.

To detect the creation of a protected process (step 312 in FIG. 8 ), some embodiments use any hooking method known in the art to hook into the kernel function that manipulates the active process list. An example of this function in the Windows OS is PspInsertProcess, which adds a process to the active process list when launching the corresponding process for execution. Some embodiments of the AM driver 36 may apply a redirection patch to the corresponding kernel function, such as a VMCALL instruction or a JMP instruction. Other embodiments may modify the EPT entry for the corresponding kernel function to point to a new address. Such a patch and/or EPT hook serves to redirect the execution of the native OS function to a code snippet provided by the memory introspection engine 40. Following the hook, when the OS 34 attempts to launch the process for execution, the code snippet will be executed before or instead of the code for the corresponding kernel function, thereby notifying the memory introspection engine 40 that the corresponding process is executing. In some embodiments, the engine 40 may identify the corresponding process based on parameters passed to the kernel function when launching the corresponding process (e.g., an EPROCESS structure containing the unique process ID). Alternative embodiments may use a memory hook (eg, an EPT hook) to gain access to the address of a section of memory storing a list of active procedures, and from the contents of the corresponding memory section, further determine the address of an EPROCESS structure describing each currently executing procedure.

In step 314, the memory introspection engine 40 may notify the AM driver 36 that a protected process is executing. For example, the engine 40 may send an indicator (e.g., the process ID of the protected process) to the AM driver 36. Next, in step 316, the engine 40 may receive from the driver 36 an indicator of the memory page (e.g., the address of the page in virtual memory) that stores the code and/or data of the protected process. In some embodiments, the engine 40 uses steps 314-316 to bridge the semantic gap that arises because the engine 40 executes outside the VM 32 and the protected process executes within the VM 32. By executing in kernel mode within the VM 32, the AM driver 36 may have direct access to information (e.g., memory addresses used by the protected process, e.g., addresses of pages within the virtualized physical memory of the corresponding VM (see spaces 114a-b in FIG. 6 ) that store the code and/or data of the protected process). While hypervisor 30 can gain access to a list of active processes executing within a respective VM, parsing that list to determine all modules (e.g., DLLs) loaded by the respective process and, further, all addresses of memory pages storing such data/code from the hypervisor 30 level can require extensive computation. In some embodiments, another reason for the sequence of steps 314-316 is that data belonging to user-mode processes can be swapped between physical memory 14 and other computer-readable media (e.g., storage devices 20) by OS 34. A memory introspection engine 40, executing outside the respective VM, can detect when data is swapped in and out of physical memory, but because it does not reside in physical memory, it cannot access and/or protect such data. In contrast, AM driver 36 executing within VM 32 can easily access pages swapped out of physical memory by forcing OS 34 to load the corresponding pages. AM driver 36 can thus effectively list all modules used/loaded by protected processes and determine the size and location of such modules within VM 32's virtualized physical memory.

In an alternative embodiment, instead of actively detecting the launch of a protected process (step 312 above), memory introspection engine 40 may receive an indicator of the protected process from AM driver 36, where AM driver 36 may actually detect the launch of the protected process from within VM 32. In such an embodiment, step 314 as described above is no longer necessary. In another embodiment, in step 316, engine 40 may actually perform the necessary calculations to determine the address of the memory page of the protected process, rather than relying on AM driver 36 as described above.

In step 318, the memory introspection engine protects the target page from unwanted modifications (e.g., by malware attempting to compromise VM 32). Several such memory protection mechanisms are known in the art. Protection can be enforced by hypervisor 30 using a data structure (e.g., EPT or NPT) upon request by memory introspection engine 40. For example, hypervisor 30 can set the target memory page to read-only by modifying the EPT/NPT access permission bits for the corresponding page. In some embodiments, hypervisor 30 can intercept any attempt to write to a memory page allocated to the target object and redirect the corresponding attempt to memory introspection engine 40 for analysis. The operation of engine 40 in step 318 is described in further detail below with respect to FIG. 9.

To apply write protection to the target page, step 318 may include performing a translation of the memory address of the type illustrated in FIG6 : from the virtual memory space established by the OS 34 for the protected process all the way to the physical memory 14 of the host system 10, or from the virtualized physical memory space of the corresponding VM to the physical memory 14. Based on the indicator received from the AM driver 36 in step 316, the corresponding translation allows the memory introspection engine 40 to determine the address of the target page in the actual physical memory 14. Such translation may use the EPT/NPT mechanism, as described with respect to FIG6 .

In step 320, the engine 40 may detect the termination of the protected process. In some embodiments, step 320 may be performed in a manner similar to step 312 described above. For example, step 320 may include receiving a signal from a kernel function (which is configured to remove the process from the active process list of VM 32) and the AM driver 36 modifying the corresponding function by hooking (e.g., applying a patch (e.g., a VMCALL instruction) to the corresponding function, which is redirected to the execution of the engine 40). An exemplary Windows function that can be modified in this manner is PspDeleteProcess. When the engine 40 detects the termination of the protected process, step 322 removes protection from the corresponding target page, for example by instructing the hypervisor 30 to change the write permissions for the target page.

FIG9 illustrates the sequence of steps performed by memory introspection engine 40 to protect a target page (step 318 in FIG8 ). In step 332, engine 40 may intercept attempts to write to the target page; such attempts may indicate malicious intent and may be intercepted by hypervisor 30, as described above. In step 334, engine 40 may identify the process executing the attempt; the corresponding process will be referred to as the attacking process. In some embodiments, to perform step 334, engine 40 may use the contents of an instruction pointer register (e.g., the EIP and/or RIP registers on an x86 system) to identify the processor instruction (or its address) executing the attempt, and the contents of the CR3 register to identify the process to which the corresponding instruction belongs. Alternatively, engine 40 may use the contents of a fragment register (e.g., the FS and GS registers on an x86 processor) to identify the attacking process based on certain kernel data structures that are modified each time the OS 34 switches execution between processes.

In step 336, the engine 40 may formulate a process evaluation indicator 52d (see, e.g., FIG. 4 ) for the attack process and transmit the indicator 52d to the process scoring module 38. Exemplary indicators 52d may include an indicator of the attack process identified in step 334 (e.g., a process ID), and an indicator of the type of action attempted by the attack process and intercepted in step 332 (e.g., an attempt to write to a protected memory page).

Some of the methods and systems described above require communication (e.g., data exchange and/or messaging) between components executing within a VM 32 and between components executing outside of the respective VMs (e.g., data exchange and/or messaging). This communication may be performed using any method known in the art of virtualization. For example, to transfer data from a component executing in kernel mode (e.g., the AM driver 36) to the memory introspection engine 40 (see, for example, step 316 in FIG8 ), some embodiments use privileged instructions to transfer control of the processor 12 from the VM 32 to the hypervisor 30. An example of such a privileged instruction is VMCALL on Intel platforms, which can be used to signal to the engine 40 that some data is being transferred from within the VM 32. The actual data being transferred may be placed in a predetermined section of memory shared between the driver 36 and the engine 40. To transfer data from the memory introspection engine 40 to the AM driver 36 (see, for example, step 314 in FIG. 8 and step 336 in FIG. 9 ), some embodiments use an interrupt injection mechanism to signal to the driver 36 that data is being transferred from outside the corresponding VM. The actual data may be transferred, for example, through the shared memory segments described above.

In some embodiments, host system 10 may be configured to exchange security information, such as details regarding malware detection events, with a remote security server. FIG10 illustrates this exemplary configuration, in which multiple host systems 10a-c are connected to a security server 110 via a computer network 26. In the exemplary embodiment, host systems 10a-c are personal computers used by employees of a company, and security server 110 may comprise a computer system configured by a network administrator of the respective company to monitor malware threats or security events occurring on systems 10a-c. In another embodiment, such as in an Infrastructure as a Service (IaaS) system (in which each host system 10a-c is a server hosting tens or hundreds of virtual machines), security server 110 may comprise a computer system configured to manage anti-malware operations for all such VMs from a central location. In another embodiment, security server 110 may comprise a computer system configured by an anti-malware provider (e.g., a provider of security application 44, etc.) to receive statistical and/or behavioral data regarding malware detected on various systems surrounding network 26. Network 26 may comprise a wide area network (eg, the Internet), while portions of network 26 may comprise a local area network (LAN).

FIG11 illustrates an exemplary data exchange between the host system 10 and the security server 110 in the embodiment shown in FIG10 . The host system 10 may be configured to send a security report 80 to the server 110 and receive a set of security settings 82 from the server 110. In some embodiments, the security report 80 includes a process evaluation indicator and/or a score determined by a process evaluator executing on the host system 10, and/or a cumulative score determined by the process scoring module 38, among others. The security report 80 may also include data identifying the respective virtual machines and the evaluated processes (e.g., process ID, name, path, hash, version information, or other identifiers of the application and/or process), as well as indicators associating the process evaluation indicator/score with the VM and process for which the indicator was determined. In some embodiments, the report 80 may further include statistical and/or behavioral data regarding the processes and/or applications executing on the host system 10. The system 10 may be configured to send the report 80 upon detection of malware and/or according to a schedule (e.g., every few minutes, every hour, etc.).

In some embodiments, security settings 82 may include operating parameters of a process evaluator (e.g., parameters of filters 50a-c in FIG. 4 ), and/or parameters of process scoring module 38. An example of an operating parameter of module 38 is a threshold value used to determine whether an evaluated process is malicious (see step 308 in FIG. 5 and the associated description). An exemplary operating parameter of a process evaluator is a maliciousness score value assigned to an evaluated process when the evaluated process performs a particular action. An evaluated process may receive a maliciousness score of 0.1 when the corresponding process writes to a disk file, and may receive a maliciousness score of 0.7 when the evaluated process modifies a Windows registry value.

In some embodiments, server 110 runs an optimization algorithm to dynamically adjust such parameters to maximize malware detection performance, for example, to improve detection rates while minimizing false positives. The optimization algorithm can receive statistical and/or behavioral data about the various processes executed on multiple host systems 10a to c (including process evaluation indicators/scores reported to process scoring module 38 by various process evaluators) and determine the optimal values of the parameters. The values are then transmitted to the corresponding host systems via network 26. In some embodiments, to determine the optimal parameter values, server 110 can use a set of processes known to be clean (not affected by malware) to calibrate the operation of process scoring module 38 and/or process evaluators 50a to c. In an exemplary calibration scheme, security server 110 can instruct host system 10 to perform a set of calibration processes (known to be clean) and send back a set of process evaluation indicators/scores determined by server 110 for the calibration processes. Server 110 can then determine parameter values customized for corresponding virtual machines and/or host systems.

In another example, the security settings 82 include a set of weight values that are used by the process scoring module 38 to determine a cumulative maliciousness score for the evaluated process based on the individual process evaluation indicators received from the various process evaluators. In an embodiment, where the cumulative score is a weighted sum or weighted average of the individual scores, and where each score is calculated according to a different malware detection standard or method (e.g., where each score indicates whether the evaluated process performs a specific malware-indicative behavior), changing the weight of an individual score can effectively change the relevance of the corresponding standard or method compared to other standards/methods. Malware threats often occur in waves, where a large number of computer systems worldwide are affected by the same malware agent in a short time interval. By receiving security reports 80 from multiple host systems in real time, the security server 110 can stay updated with current malware threats and can quickly communicate optimal security settings 82 to the corresponding host systems, the settings 82 including, for example, a set of score weights optimized for detecting the current malware threat.

The exemplary systems and methods described above allow for protection of a host system (e.g., a computer system) from attacks by malware (e.g., viruses or rootkits). Conventional anti-malware systems typically execute at the processor privilege level of the operating system (e.g., kernel mode). Some malware (e.g., rootkits) can also operate at the OS level and can therefore paralyze conventional anti-malware systems and compromise the security of the computer system. In contrast, in some embodiments of the present invention, a hypervisor executes at the highest processor privilege level on the computer system, replacing the operating system with a virtual machine. Anti-malware systems operating according to some embodiments of the present invention include components that execute at the hypervisor level within the VM and components that execute outside the VM. Thus, some anti-malware operations can be performed at a higher processor privilege level than the operating system's processor privilege level, where malware executing within the VM cannot compromise them. In some embodiments, a single memory introspection engine executing at the hypervisor level can protect multiple virtual machines executing simultaneously on the corresponding computer system.

In some embodiments, the operation of the memory introspection engine includes selecting a set of critical software objects (e.g., certain drivers, libraries, registers, and page tables) and preventing malicious modification of such objects. In particular, some embodiments can thus protect anti-malware components executing within a VM from malicious attacks.

To protect such objects, some embodiments can prevent malicious modifications by intercepting attempts to write to the memory space allocated to the corresponding object, and block or redirect the attempts. Other embodiments can protect the target object by marking the memory space allocated to the corresponding object as read-only. In a typical hardware and software configuration, the memory is divided into individual blocks (called pages) with consecutive addresses. In a system that supports virtualization, page access permissions are controlled by the hypervisor (for example) using a dedicated data structure (for example, the Extended Page Table (EPT) on the Intel platform). Therefore, (for example) by instructing the hypervisor to mark the set of pages containing data belonging to the corresponding object as read-only through the memory introspection engine, the memory space of the target object can be protected.

In some embodiments, some anti-malware components execute within a protected virtual machine, collaborating with a memory introspection engine to detect malware. This configuration can substantially simplify malware detection by bridging the semantic gap created by virtualization. In a typical software configuration, malware detection components executing in user mode can obtain rich information about the behavior of the evaluated process, much of which is not readily available to components executing at the kernel level or outside the corresponding VM. For example, when an evaluated process attempts to download a file from the internet, a user-mode process evaluator (e.g., using methods known in the art (e.g., DLL injection)) can identify which process is performing the action, detect the file being downloaded from, and determine the IP address and disk location of the downloaded file. Meanwhile, a process evaluator executing at the hypervisor level may only detect the collection of network packets circulating in the host system's network adapter. While recovering information about the behavior of the evaluated process from the hypervisor level may in principle be possible, such a task can be impractical for malware detection because it can incur significant computational costs. By combining anti-malware components executing within a respective VM with a memory introspection engine executing outside the VM, some embodiments of the present invention may use the rich behavioral data available to internal VM components while protecting the integrity of such components from influences outside the respective VM.

In conventional anti-malware systems, a software component executing at a processor privilege level similar to that of the operating system detects when a process is launched and instructs other anti-malware components to monitor the behavior of the corresponding process. Some malware agents attempt to subvert such anti-malware systems by disabling the software component that detects process launch, thereby causing the anti-malware system to monitor only a subset of currently executing processes. In contrast, in some embodiments of the present invention, component detection process launch is moved outside the corresponding virtual machine, which launches at a higher processor privilege level than the operating system. This configuration prevents malware from evading anti-malware components.

In some embodiments, the process scoring module receives per-process evaluation indicators from a plurality of process evaluators executed within or outside the corresponding VM. A process evaluation indicator received from a component executing within the protected VM may indicate, for example, that the evaluated process has performed malware-indicative behavior (e.g., attempting to modify an OS registry value or attempting to delete a file). A process evaluation indicator determined outside the corresponding VM may indicate, for example, that the evaluated process is attempting to write to a protected memory segment. The process evaluation indicator may include a numerical score indicating the degree of maliciousness of the corresponding process. In some embodiments, the process scoring module determines a cumulative score based on the plurality of process evaluation indicators/scores received from the various process evaluators, and determines whether the evaluated process is malicious based on the cumulative score.

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 appended claims and their legal equivalents.

Claims (20)

1. A host system including at least one processor, configured to perform: The hypervisor is configured to expose the virtual machine; A process evaluator, which executes within the virtual machine; A memory introspection engine, which executes outside the virtual machine; and The process scoring module includes: The process evaluator is configured to: Determine whether the evaluated process, executed within the virtual machine, performs an action, and In response, when the process being evaluated performs the action, a first process evaluation indicator is transmitted to the process scoring module, wherein the first process evaluation indicator is determined for the process being evaluated; The memory introspection engine is configured to: Calls to operating system functions are intercepted to detect the startup of a protected process executing within the virtual machine, wherein the operating system functions are configured to add the protected process to a list of processes executing within the virtual machine. In response to the detection of the startup, Determine whether the evaluated process attempts to modify the memory pages of the protected process, and In response, when the evaluated process attempts to modify the memory page... The second process evaluation indicator is transmitted to the process scoring module; the second process evaluation indicator is determined for the process being evaluated. The process scoring module is configured to: Receives a first weight and a second weight from a security server configured to perform anti-malware transactions with multiple computer systems including the host system; Receive the first and second process evaluation indicators, and In response, it is determined whether the evaluated process is malicious based on the first and second process evaluation indicators, wherein determining whether the evaluated process is malicious includes determining a weighted sum of a first score and a second score, wherein the first weight is multiplied by the first score in the weighted sum, and the second weight is multiplied by the second score in the weighted sum, wherein the first score and the second score are determined based on the first process evaluation indicator and the second process evaluation indicator, respectively. 2. The system of claim 1, wherein the memory introspection engine is further configured to: In response to the detection of the start of the protected process, an indicator of the protected process is sent to the security application executing within the virtual machine, and In response, an indicator of the memory page is received from the security application. 3. The host system of claim 1, wherein the process evaluator includes a user-level process evaluator executed at the user level with processor privileges, the user-level process evaluator being configured to determine whether the process being evaluated performs the action. 4. The host system of claim 1, wherein the process evaluator includes a kernel-level process evaluator executed at the kernel level with processor privileges, the kernel-level process evaluator being configured to determine whether the process being evaluated performs the action. 5. The host system of claim 1, wherein the process evaluator includes a system call evaluator configured to intercept system calls executed by the process being evaluated. 6. The host system according to claim 1, wherein the process scoring module is executed within the virtual machine. 7. The host system according to claim 1, wherein the process scoring module is executed outside the virtual machine. 8. The host system of claim 1, wherein the protected process includes the process scoring module. 9. The host system of claim 1, wherein the protected process forms part of a security application including the process evaluator. 10. A non-transitory computer-readable medium encoding instructions that, when executed on a host system including at least one processor, cause the host system to be formed: The hypervisor is configured to expose the virtual machine; A process evaluator, which executes within the virtual machine; A memory introspection engine, which executes outside the virtual machine; and The process scoring module includes: The process evaluator is configured to: Determine whether the evaluated process, executed within the virtual machine, performs an action, and In response, when the process being evaluated performs the action, a first process evaluation indicator is transmitted to the process scoring module, wherein the first process evaluation indicator is determined for the process being evaluated; The memory introspection engine is configured to: Calls to operating system functions are intercepted to detect the startup of a protected process executing within the virtual machine, wherein the operating system functions execute within the virtual machine and are configured to add the protected process to a list of processes executing within the virtual machine. In response to the detection of the startup, Determine whether the evaluated process attempts to modify the memory pages of the protected process, and In response, when the evaluated process attempts to modify the memory page... The second process evaluation indicator is transmitted to the process scoring module; the second process evaluation indicator is determined for the process being evaluated. The process scoring module is configured to: Receives a first weight and a second weight from a security server configured to perform anti-malware transactions with multiple computer systems including the host system; Receive the first and second process evaluation indicators, and In response, it is determined whether the evaluated process is malicious based on the first and second process evaluation indicators, wherein determining whether the evaluated process is malicious includes determining a weighted sum of a first score and a second score, wherein the first weight is multiplied by the first score in the weighted sum, and the second weight is multiplied by the second score in the weighted sum, wherein the first score and the second score are determined based on the first process evaluation indicator and the second process evaluation indicator, respectively. 11. The non-transitory computer-readable medium of claim 10, wherein the memory introspection engine is further configured to: In response to the detection of the start of the protected process, an indicator of the protected process is sent to the security application executing within the virtual machine, and In response, an indicator of the memory page is received from the security application. 12. The non-transitory computer-readable medium of claim 10, wherein the process evaluator comprises a user-level process evaluator executed at the user level with processor privileges, the user-level process evaluator being configured to determine whether the process being evaluated performs the action. 13. The non-transitory computer-readable medium of claim 10, wherein the process evaluator comprises a kernel-level process evaluator executed at the kernel level with processor privileges, the kernel-level process evaluator being configured to determine whether the process being evaluated performs the action. 14. The non-transitory computer-readable medium of claim 10, wherein the process evaluator includes a system call evaluator configured to intercept system calls performed by the process being evaluated. 15. The non-transitory computer-readable medium of claim 10, wherein the process scoring module is executed within the virtual machine. 16. The non-transitory computer-readable medium of claim 10, wherein the process scoring module is executed outside the virtual machine. 17. The non-transitory computer-readable medium of claim 10, wherein the protected process includes the process scoring module. 18. The non-transitory computer-readable medium of claim 10, wherein the protected process forms part of a secure application configured to execute the process evaluator. 19. A method comprising: At least one processor of the host system is used to receive a first weight and a second weight from a security server, which is configured to perform anti-malware transactions with a plurality of computer systems including the host system. The at least one processor is used to receive a first process evaluation indicator determined for a process being evaluated, the process being evaluated being executed within a virtual machine exposed by a hypervisor executing on the host system, wherein determining the first process evaluation indicator includes using a process evaluator executing within the virtual machine to determine whether the process being evaluated performs a first action; The at least one processor is used to receive a second process evaluation indicator determined for the process being evaluated, wherein determining the second process evaluation indicator includes using a memory introspection engine executed outside the virtual machine to determine whether the process being evaluated performs a second action; and In response to receiving the first and second process evaluation indicators, the at least one processor is used to determine whether the evaluated process is malicious based on the first and second process evaluation indicators, wherein determining whether the evaluated process is malicious includes determining a weighted sum of a first score and a second score, wherein the first weight is multiplied by the first score in the weighted sum, and the second weight is multiplied by the second score in the weighted sum, wherein the first score and the second score are determined based on the first process evaluation indicator and the second process evaluation indicator, respectively. 20. A method comprising: At least one processor of the host system is used to receive a first weight and a second weight from a security server, which is configured to perform anti-malware transactions with a plurality of computer systems including the host system. The at least one processor is used to execute a memory introspection engine, which executes outside a virtual machine exposed by a hypervisor executing on the host system, wherein executing the memory introspection engine includes detecting the initiation of a process executing within the virtual machine; In response to the memory introspection engine detecting the initiation of the process, the at least one processor is used to determine first and second process evaluation indicators for the process; and In response to determining the first and second evaluation indicators, the at least one processor is used to determine whether the process is malicious based on the first and second process evaluation indicators, wherein determining whether the evaluated process is malicious includes determining a weighted sum of a first score and a second score, wherein the first weight is multiplied by the first score in the weighted sum, and the second weight is multiplied by the second score in the weighted sum, wherein the first score and the second score are determined based on the first process evaluation indicator and the second process evaluation indicator, respectively.