Patent Description:
Analysis of potential malware is commonly performed by analyzing behavior of software (e.g., executable files and other file types, links, applets, etc.) in a sandbox to facilitate identification of threats while isolating the software from the host machine. Sandboxes can be implemented using virtual machines. When using a virtual machine for sandboxing potential malware, the virtual machine is launched and the potential malware is loaded into the virtual machine for analysis of its behavior, such as based on monitoring execution or otherwise manipulating the software within the virtual machine. Multiple virtual machines may also be provisioned for malware analysis, such as by creating a virtual machine pool in advance or through implementing virtual machine cloning.

<CIT> discloses instantiating a first virtual machine instance and a second virtual machine instance to run concurrently with the first virtual machine instance. The first virtual machine instance provides a first virtual operating environment while the second virtual machine instance is adapted to share the resources allocated to the first virtual machine instance. The second virtual machine instance is further adapted to allocate additional resources upon conducting a Copy-On Write operation.

Embodiments of the disclosure may be better understood by referencing the accompanying drawings.

The description that follows includes example systems, methods, techniques, and program flows that embody aspects of the disclosure. However, it is understood that this disclosure may be practiced without these specific details. For instance, this disclosure refers to performing malware analysis of software samples detected by a firewall in illustrative examples. Aspects of this disclosure can be also applied to detection of software samples by other network devices which can monitor network traffic. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.

Using a single virtual machine for malware analysis of multiple software samples (e.g., program code detected or identified from network traffic) necessitates that the virtual machine boot and a preparation process be repeated for each sample, which is costly in terms of both time and resources. Additionally, the time required to boot the virtual machine, prepare the analysis environment, and complete the analysis for a sample creates a window of vulnerability to attack, possibly lasting several minutes. While existing techniques for sandbox analysis provide for the use of multiple virtual machines, these techniques also present shortcomings. Creating a virtual machine pool in advance can result in underprovisioning and overprovisioning of resources. If resources are underprovisioned, additional virtual machines must be created with the resource- and time-intensive process of booting and preparing a new virtual machine(s). If resources are overprovisioned, resources are wasted. Further, virtual machine cloning is a rigid approach that may require that the system architecture be adapted to the implementation.

To quickly provision virtual machines for malware analysis of incoming samples without the flaws of existing solutions, a technique for virtual machine forking has been developed. A process in which a virtual machine has been booted and its guest operating system installed is forked to create a child process. A "child virtual machine" which is a copy of the virtual machine booted in the parent process (or the "parent virtual machine") is then created in the child process. The resulting child virtual machine is already booted with the same guest operating system installed as the parent from which it was forked, thus substantially reducing the time conventionally required to boot a new virtual machine. Initially booting and preparing a set of virtual machines with different guest operating systems installed allows a child virtual machine with an appropriate guest operating system to be rapidly created from a corresponding one of the parent virtual machines. Because malicious code may be packaged for a specific operating system version, subsets of the virtual machines may have different versions of the same guest operating system installed to increase the accuracy with which threats are correctly detected and identified. Upon detection of a new sample to be analyzed, the virtual machine(s) running the appropriate guest operating system is "forked" to create a child virtual machine which is independent of the parent virtual machine and has the same guest operating system installed. The sample is then sandboxed in the child virtual machine for analysis of its behavior, and logs generated during the analysis can be evaluated to determine if the sample comprises malware.

The technique of forking a virtual machine to create a child virtual machine is based on issuing a fork system call from the process in which the parent virtual machine was booted during setup of the initial set of virtual machines, where the fork implements copy-on-write for improved performance. A "deep copy" of the virtual CPU registers of the parent virtual machine is created such that the virtual CPU register data is copied to the registers corresponding to the virtual CPU of the child virtual machine rather than references to the data alone. Copying of pages of memory and the virtual disk between the parent and child is handled by initially providing the child with a read-only copy of the memory and virtual disk of the parent and deferring copy operations until the first write attempt in the child process to further improve performance. The resulting child virtual machine that is forked from the parent virtual machine is a copy of the parent virtual machine yet exists in a separate process. This also maintains a "clean" base image of the parent virtual machine between virtual machine fork operations because the malware analysis is performed in the child virtual machine with the parent resources marked read-only.

<FIG> depicts a conceptual diagram of rapid context tailored sandbox generation for malware analysis. <FIG> depicts a virtual machine forking manager ("VM forking manager") <NUM> which executes on a host system <NUM>. The VM forking manager <NUM> facilitates creation of virtual machines through forking a process of a "parent" virtual machine to provide a controlled execution environment for malware analysis of software samples (hereinafter "samples"). The VM forking manager <NUM> can communicate with a hypervisor <NUM> installed on the host system <NUM> which manages creation of virtual machines and execution of guest operating systems. The VM forking manager <NUM> maintains one or more queues for samples indicated for malware analysis, where individual queues may correspond to individual sample types. In this example, the VM forking manager <NUM> maintains queues <NUM>, <NUM> for queueing portable executable (PE) files and command files, respectively, although additional queues for different types of samples may also be maintained. The VM forking manager <NUM> includes a results analyzer <NUM> which analyzes log data generated during analysis of the sample in one or more child virtual machines which have been "forked" from a respective parent virtual machine to provide a verdict as to whether the sample is malware. <FIG> also depicts a content analyzer <NUM> which analyzes incoming samples detected by a firewall <NUM> based on a set of heuristics to determine whether a sample is malware without analyzing behavior of the sample (e.g., through sandbox analysis). The content analyzer <NUM> may be a service which is separate from the firewall <NUM>, a software process which executes as part of the firewall <NUM>, etc..

<FIG> is annotated with a series of letters A-F. These letters represent stages of operations. Although these stages are ordered for this example, the stages illustrate one example to aid in understanding this disclosure and should not be used to limit the claims. Subject matter falling within the scope of the claims can vary with respect to the order and some of the operations.

At stage A, the VM forking manager <NUM> launches virtual machines <NUM>, <NUM>, <NUM> instantiated with different operating systems and/or operating system versions. The VM forking manager <NUM> maintains a configuration file <NUM> which indicates operating systems and a corresponding version(s) which should be installed on each of a set of virtual machines. In this example, the configuration file <NUM> indicates versions <NUM> and <NUM> of a first guest operating system and version <NUM> of a second guest operating system to be installed on respective virtual machines. The VM forking manager <NUM> instantiates the virtual machines <NUM>, <NUM>, <NUM> which each run respective one of the guest operating systems indicated in the configuration file <NUM>. For instance, the VM forking manager <NUM> can execute a script(s) to create each of the virtual machines <NUM>, <NUM>, <NUM> and, for each virtual machine, install an operating system on the virtual machine which is indicated in the configuration file <NUM> (e.g., based on a file path indicated in the configuration file <NUM>).

At stage B, the firewall <NUM> detects a file <NUM> and communicates the file <NUM> to the content analyzer <NUM>. The firewall <NUM> monitors and controls network traffic incoming from a network <NUM> (e.g., a public network). While monitoring incoming network traffic, the firewall <NUM> detects the file <NUM>, which is a PE file in this example. The firewall <NUM> passes the file <NUM> to the content analyzer <NUM> for an initial evaluation to determine if the file <NUM> is malware without analyzing behavior of the file <NUM> (i.e., in a virtual machine). The content analyzer <NUM> analyzes the file <NUM> based on a set of heuristics <NUM>. For instance, the content analyzer <NUM> can analyze the file <NUM> by generating a hash value of the file <NUM> and evaluating the hash value based on the heuristics <NUM>. If the initial analysis by the content analyzer <NUM> yields a verdict that the file <NUM> is benign or malicious, the firewall <NUM> can allow or block the file <NUM> accordingly. As depicted in this example, if the analysis by the content analyzer <NUM> does not yield a verdict for the file <NUM>, the firewall <NUM> forwards the file <NUM> to the VM forking manager <NUM> for further analysis. The file <NUM> is queued in the queue <NUM> for subsequent monitoring of its behavior in a virtual machine. The VM forking manager <NUM> may be configured to identify the type of an incoming sample to determine which of the queues <NUM>, <NUM> in which to queue the sample. For instance, the VM forking manager <NUM> may identify that the file <NUM> is a PE file and place an identifier (ID) of the file <NUM> in the queue <NUM>.

At stage C, the VM forking manager <NUM> issues an instruction to fork a child virtual machine <NUM> and a child virtual machine <NUM> from the virtual machine <NUM> and the virtual machine <NUM>, respectively. The VM forking manager <NUM> determines an operating system with which the file <NUM> is compatible and determines which of the virtual machines <NUM>, <NUM>, <NUM> has been instantiated with the compatible operating system. In determining which of the virtual machines <NUM>, <NUM>, <NUM> has been instantiated with the compatible operating system, the VM forking manager <NUM> may determine that multiple virtual machines of the set of virtual machines <NUM>, <NUM>, <NUM> have each been instantiated with the compatible operating system. In this example, the VM forking manager <NUM> determines that the file <NUM> is compatible with a first guest operating system (depicted as "guest OS <NUM>") and that the virtual machines <NUM>, <NUM> have installed different versions of the first guest operating system. The VM forking manager <NUM> may issue an instruction to quiesce or pause the virtual machines <NUM>, <NUM>, where the pausing or quiescing may be temporary. The VM forking manager <NUM> then issues a fork of each of the virtual machines <NUM>, <NUM> to create child processes in which respective child virtual machines <NUM>, <NUM> can be created. For instance, upon issuance of a fork by the VM forking manager <NUM>, a fork system call can be made by each of the processes of the virtual machines <NUM>, <NUM>. The fork system call which is issued is implemented with copy-on-write of physical memory pages so that rather than copying the physical memory pages of the parent processes (i.e., the processes of the virtual machines <NUM>, <NUM>) during creation of the child processes, virtual memory of the parent and child processes reference the same physical memory, and copying is deferred until the first write attempt made in the child processes. For instance, upon issuance of the fork system call by the processes of the virtual machines <NUM>, <NUM>, memory pages allocated to the parent processes can be marked as read-only (e.g., in the respective page table entries) and a count of references to each page of physical memory initialized. This can be considered to provide a snapshot of the memory state for each of the virtual machines <NUM>, <NUM> at the time of the fork which the corresponding child processes of the child virtual machines <NUM>, <NUM> can reference as read-only data.

After the processes are forked, the virtual CPU and virtual disk of each of the child virtual machines <NUM>, <NUM> are then respectively prepared based on those of the virtual machines <NUM>, <NUM> so the child virtual machines <NUM>, <NUM> can operate independently of their respective parent virtual machine. When creating the child virtual machines <NUM>, <NUM>, data accessible to a virtual central processing unit (CPU) of each of the virtual machines <NUM>, <NUM> (e.g., data stored in registers) is copied to a virtual CPU allocated to a respective one of the child virtual machines <NUM>, <NUM> through a "deep copy. " To perform a deep copy of a virtual CPU of a parent virtual machine such as one of the virtual machines <NUM>, <NUM>, copies of data stored in registers corresponding to the virtual CPU of the parent are created and stored in registers of the virtual CPU allocated to the child virtual machine. This is as opposed to copying references to the stored data alone (i.e., as analogous to creating a shallow copy in object copying). Accordingly, a deep copy is performed to copy data stored in registers of the virtual CPU of each of the virtual machines <NUM>, <NUM> into registers corresponding to the virtual CPU allocated to each of the child virtual machines <NUM>, <NUM>. A deep copy of hardware-assisted virtualization structures of the virtual machines <NUM>, <NUM> may similarly be performed for the child virtual machines <NUM>, <NUM> (e.g., deep copies of the virtual machine control structure data, pointer(s) for nested paging implementations, etc.). Copying of the virtual disk between each of the virtual machines <NUM>, <NUM> and the corresponding one of the child virtual machines <NUM>, <NUM> is also handled by providing the child process with a read-only version of the data stored on the virtual disks. During the fork of each of the virtual machines <NUM>, <NUM>, a snapshot of the virtual disk of each virtual machine can be created to provide a read-only copy of the data written to the virtual disk by the respective parent process for reference by each of the child virtual machines <NUM>, <NUM>. Delta disks may then be created for each of the child virtual machines <NUM>, <NUM> for use as a writable disk. Requested disk write operations made by the guest operating systems of each of the child virtual machines <NUM>, <NUM> can then be redirected to the respective delta disk on the first write attempt. The virtual machines <NUM>, <NUM> may be resumed following the fork of the child virtual machines <NUM>, <NUM>.

At stage D, the VM forking manager <NUM> loads the file <NUM> into each of the child virtual machines <NUM>, <NUM> for monitoring of its behavior. Behavior of a sample which has been loaded into a child virtual machine and executed or otherwise manipulated can be monitored and recorded to logs generated for the child virtual machine. For instance, a sample can be monitored based on executing one or more test cases that are determined based on the type of the sample. In this example, after the VM forking manager <NUM> loads the file <NUM> into each of the child virtual machines <NUM>, <NUM>, the file is opened using software 120A, 120B for viewing executable files, respectively. Behavior of the file <NUM> resulting from opening and/or manipulating the file <NUM> within the child virtual machines <NUM>, <NUM> is monitored and recorded to generate log data 118A, 118B, respectively (collectively the "log data 118A-B"). The log data 118A-B indicate behavior associated with the file <NUM> based on monitoring the file <NUM> within each of the child virtual machines <NUM>, <NUM>. While monitoring and recording behavior of the file <NUM>, the virtual disk and memory pages of the virtual machines <NUM>, <NUM> can be accessed as read-only data. Because copying of these components of the virtual machines <NUM>, <NUM> and their respective processes was implemented with copy-on-write as described in reference to stage C, first writes to the virtual disk can be redirected to the delta disk, and first writes to the read-only memory pages can be intercepted and new physical memory pages allocated for performing the write operation. This allows for maintaining a "clean" base image between virtual machine forking and sample monitoring operations.

At stage E, the results analyzer <NUM> collects the log data 118A-B, and the child virtual machines <NUM>, <NUM> are terminated. The results analyzer <NUM> collects the log data 118A-B for evaluation to determine whether the file <NUM> is malware (e.g., via agents loaded on the child virtual machines <NUM>, <NUM>). The child virtual machines <NUM>, <NUM> are then terminated such as by terminating the child processes forked from the processes of the virtual machines <NUM>, <NUM>. Upon termination of the child virtual machines <NUM>, <NUM>, delta disks created for the child virtual machines <NUM>, <NUM> may be deleted and the physical memory pages written to by the respective child processes via copy-on-write indicated as available (e.g., based on decrementing the reference count to zero).

At stage F, the results analyzer <NUM> determines if the file <NUM> comprises malware based on analysis of the log data 118A-B. The results analyzer <NUM> analyzes the log data 118A-B to determine if the execution behavior associated with the file <NUM> indicates that the file <NUM> is malware. For instance, the results analyzer <NUM> can evaluate behavior patterns indicated in the log data 118A-B against behavior patterns indicated in rules or other criteria for malware identification to determine whether behavior patterns of the file <NUM> observed in at least a first of the child virtual machines <NUM>, <NUM> satisfy a first of the rules or criteria. Because malware may be packaged for a specific version(s) of an operating system, a determination that the log data recorded for at least one of the child virtual machines <NUM>, <NUM> is indicative of malicious behavior can trigger a determination by the results analyzer <NUM> that the file <NUM> is malware. For example, a determination that the behavior recorded in the log data 118A of the child virtual machine <NUM> is indicative of malicious activity but the behavior recorded in the log data 118B of the child virtual machine <NUM> is not indicative of malicious activity may still trigger an indication by the results analyzer <NUM> that the file <NUM> is malware. In this example, the results analyzer <NUM> determines that the behavior patterns of the file <NUM> reflected in the log data 118A-B are indicative of malicious behavior and thus provides a verdict that the file <NUM> is malware.

<FIG> depicts a conceptual diagram of high-level management of data shared between parent and child processes corresponding to parent and child virtual machines while monitoring behavior of a software sample loaded into the child virtual machine. <FIG> depicts the virtual machine <NUM> and child virtual machine <NUM> which have installed a guest operating system with which the file <NUM> is compatible as described in reference to <FIG>. The virtual machine <NUM> and child virtual machine <NUM> run in a parent process and a child process, respectively. The parent process corresponding to the virtual machine <NUM> has been allocated a virtual disk <NUM> and virtual memory which maps to physical pages 201A-D (i.e., page frames) of memory <NUM>. <FIG> depicts the state of the memory <NUM> and virtual disk <NUM> at the time of the fork of the child process from the parent process (i.e., at the time which operations described in reference to stage C in <FIG> commence). The memory <NUM> includes the physical pages 201A-D to which the memory pages written by the parent process map. The virtual disk <NUM> includes data blocks 202A-B to which the parent process has written.

Following the fork issued from the process of the virtual machine <NUM>, because the issued fork is implemented with copy-on-write, physical pages 201A-D of the memory <NUM> are marked as read-only in the page table. A reference count can then be initialized for the physical pages 201A-D which is maintained to indicate the number of references to the physical pages 201A-D. Copying of the virtual disk <NUM> is also handled so that the virtual disk <NUM> of the parent process will remain unmodified by the child process. A snapshot of the virtual disk <NUM> is generated to provide the child process with a read-only copy of the data written to the virtual disk by the parent process (i.e., the data blocks 202A-B), and a delta disk <NUM> is created for the child process. The delta disk <NUM> provides a writable disk for the child process for write requests indicating the read-only data blocks of the virtual disk <NUM>.

The file <NUM> is then loaded into the child virtual machine <NUM> for monitoring and recording of its execution behavior as described at stage D of <FIG>. At this stage, the child process can access the physical pages 201A-D to which pages of virtual memory map and data blocks 202A-B as read-only data. For example, the child process may read data stored in a virtual page which maps to the physical page 201D from memory and the data block 202A as a result of read requests made while monitoring execution behavior of the file <NUM> and recording indications of its behavior as log data 118A. Upon the first write attempt to a virtual page which maps to the physical page 201B by the child process, the write attempt is intercepted (e.g., by the kernel of the host operating system), a new physical page 201E is allocated and initialized with the data stored in the physical page 201B, and the reference count maintained for the physical page 201B is decremented. The data to write for the child process can then be written to the physical page 201E, with subsequent read and write operations made by the child process to the corresponding virtual page completed with the physical page 201E. Memory <NUM>, which includes the physical page 201E, indicates the physical memory allocated to the child process as a result of copy-on-write operations. Similarly, upon the first write attempt to the data bock 202B, the write request is redirected to the delta disk <NUM> and written to a data block 204A. The child process can subsequently read and write to the data block 204A of the delta disk.

Once execution behavior of the file <NUM> in the child virtual machine <NUM> has been monitored and recorded as log data 118A, the child virtual machine <NUM> can be terminated and the log data 118A collected for analysis as described at stage E of <FIG>. When the child virtual machine <NUM> is terminated (e.g., based on killing the child process), physical pages of the memory <NUM> can be indicated as free or available and the delta disk <NUM> discarded without impacting the parent process and the virtual machine <NUM>. This allows for the physical pages 201A-D to which virtual memory of the parent process maps and virtual disk <NUM> corresponding to the parent process to remain unmodified by the child process throughout the monitoring of the file <NUM> in the child virtual machine <NUM> and between subsequent malware analysis instances of different software samples loaded in child virtual machines forked from the virtual machine <NUM>.

<FIG> depicts a flowchart of example operations for performing malware analysis of a software sample based on context tailored sandbox generation. The example operations are described with reference to a virtual machine forking manager (hereinafter the "VM forking manager") for consistency with the earlier figures.

At block <NUM>, based on indication of a software sample for malware analysis, the VM forking manager identifies a first virtual machine having installed a first guest operating system compatible with the software sample. The VM forking manager can determine a guest operating system which is compatible with the software sample based on a type of the software sample. The software sample may be indicated for malware analysis based on having been inserted into a queue accessible to the VM forking manager for queuing software samples having the same type as the software sample.

At block <NUM>, the VM forking manager forks a process of the first virtual machine to create a child process with a second child virtual machine based, at least in part, on the first virtual machine. The VM forking manager can issue an instruction or command to fork a child process from the process corresponding to the first virtual machine in which the second virtual machine can be created. For instance, a fork system call can be made from the process corresponding to the first virtual machine, where the fork system call may be implemented to use copy-on-write for copying of memory to the child process. The second virtual machine created in the child process will also have installed the first guest operating system with which the software sample is compatible.

At block <NUM>, the VM forking manager loads the software sample into the second virtual machine. The VM forking manager can load the software sample into the second virtual machine which is created based on the fork from the process of the first virtual machine for a sandbox analysis of the software sample. Once loaded into the second virtual machine, behavior of the software sample can be monitored and recorded by the child virtual machine (e.g., to a log file of the child virtual machine).

At block <NUM>, based on analysis of behavior of the software sample in the second virtual machine, the VM forking manager indicates whether the software sample is malware. The VM forking manger can collect log data from the second virtual machine which was generated from monitoring and recording behavior of the software sample in the second virtual machine. The VM forking manager then analyzes the log data to determine whether the log data indicates malicious behavior by the software sample, such as whether behavior patterns indicated in the log data correspond to malicious activity. If the log data indicates malicious behavior by the software sample, the VM forking manager indicates that the software sample is malware.

<FIG> depicts a flowchart of example operations for instantiating a set of virtual machines for subsequent creation of child virtual machines. The example operations are described with reference to a virtual machine forking manager (hereinafter the "VM forking manager") for consistency with the earlier figures.

At block <NUM>, the VM forking manager accesses indications of operating systems and operating system versions to install as guest operating systems on a set of virtual machines. For example, the VM forking manager can maintain or have access to a configuration file which indicates one or more operating systems to install as a guest operating system on a respective virtual machine. The configuration file may indicate the operating systems, version(s) of each operating system, and virtual machine configuration information.

At block <NUM>, the VM forking manager begins instantiating virtual machines for each indicated operating system. The VM forking manager instantiates different virtual machines with different guest operating systems installed so that a controlled execution environment can be provided for malware analysis of software samples of varying types (e.g., PE files, Portable Document Format (PDF) files, document files, archive files, etc.).

At block <NUM>, the VM forking manager begins instantiating virtual machines for each version of the indicated operating system. In some cases, malicious code of a software sample may be triggered based on utilizing features of a specific version(s) of an operating system rather than any version of the operating system. The VM forking manager may thus instantiate multiple virtual machines with different versions of the same guest operating system so that malware specific to a certain version of the guest operating system will not go undetected.

At block <NUM>, the VM forking manager creates a virtual machine and installs a guest operating system corresponding to the indicated operating system and version on the virtual machine. The VM forking manager may create the virtual machine based on a virtual machine configuration indicated in the configuration file accessed to determine the operating systems and versions to install as guest operating systems. The resulting virtual machine that is launched will be running the indicated operating system and operating system version.

At block <NUM>, the VM forking manager determines whether an additional version of the operating system is indicated. If an additional version of the operating system is indicated, operations continue at block <NUM>. If no additional versions of the operating system are indicated, operations continue at block <NUM>.

At block <NUM>, the VM forking manager determines whether an additional operating system is indicated. If an additional operating system is indicated, operations continue at block <NUM>. If no additional operating systems are indicated, operations are complete. The set of virtual machines which are created can remain running and available for forking to quickly create a child virtual machine based on the virtual machine that is "forked" in which a software sample can be loaded and its execution behavior monitored and recorded.

<FIG> depicts a flowchart of example operations for creating a child virtual machine and performing malware analysis of a software sample based on loading the software sample into the child virtual machine. The example operations are described with reference to a virtual machine forking manager (hereinafter the "VM forking manager") for consistency with the earlier figures.

At block <NUM>, the VM forking manager detects a software sample indicated for malware analysis. The software sample may be indicated for malware analysis based on having been inserted into a queue maintained by or accessible to the VM forking manager upon detection by a firewall or other network component which monitors network traffic. The VM forking manager can detect the software sample based on determining that the software sample has been queued for malware analysis.

At block <NUM>, the VM forking manager identifies one or more virtual machines running a guest operating system which is compatible with the software sample. The VM forking manager identifies one or more virtual machines which were previously instantiated with a guest operating system with which the software sample is compatible. For instance, the identified virtual machine(s) may be running different versions of a first operating system. The VM forking manager can determine a guest operating system which is compatible with the software sample based on a type of the software sample, such as a sample type to which the queue in which the software sample was inserted corresponds.

At block <NUM>, the VM forking manager begins preparing virtual machines that are "forked" from the identified virtual machines for malware analysis of the software sample. As described above, forking of a virtual machine refers to forking from a process of the virtual machine and creating a child virtual machine that is a copy of the virtual machine in the resulting child process. The VM forking manager creates child virtual machines based on each of the virtual machines identified as running a guest operating system compatible with the software sample.

At block <NUM>, the VM forking manager forks the virtual machine to create a child virtual machine. The VM forking manager can pause the virtual machine and subsequently issue a fork of the virtual machine. For instance, the VM forking manager can communicate an instruction or command to issue a fork from the process in which the virtual machine was instantiated to create a child process for the child virtual machine (e.g., via a fork() system call issued from the process). The call to fork which is issued is a copy-on-write implemented fork so that virtual memory pages of the child process will refer to pages of physical memory of the parent process until a write request to read-only memory is made by the child process, after which physical memory is newly allocated to the child process. User mode-accessible resources of the parent process will be copied to the child process as a result of the fork operation. The remaining system resources are then copied to the child process through either "deep copying" as described above or by creating new instances for the child process so that the child virtual machine can run independently of its parent. For instance, for the virtual CPU, a deep copy of register data corresponding to the virtual CPU of the parent process is made for the virtual CPU allocated to the child process. A snapshot of the virtual disk corresponding to the parent process and a delta disk are also generated for the child process to provide the child process with a read-only copy of data written to the virtual disk and a writable disk, respectively. Forking of a virtual machine to create a child virtual machine is described in additional detail in reference to <FIG>.

At block <NUM>, the VM forking manager loads the software sample into the child virtual machine for monitoring and recording of behavior. The child virtual machine provides a controlled execution environment for the software sample in which its behavior can be monitored and recorded to facilitate a determination of whether the software sample comprises malware. Monitoring and recording of execution behavior of the software sample can commence upon its load into the child virtual machine. For instance, execution behavior of the software sample can be monitored as a result of opening, executing, and/or otherwise manipulating the software sample (e.g., by using a series of test cases determined based on a type of the software sample). Execution behavior may be recorded to a log file of the child virtual machine. During monitoring of the software sample, write operations made by the child process to memory and disk storage will be made to memory allocated to the child process at the first write attempt through copy-on-write and to the delta disk, respectively, so that the virtual memory and virtual disk of the parent process will be unaffected as a result of the monitoring of the software sample.

At block <NUM>, the VM forking manager determines if additional child virtual machines should be created. The VM forking manager can determine if each of the virtual machine(s) identified at block <NUM> have been "forked" to create a respective child virtual machine for malware analysis of the software sample. If one or more additional child virtual machines should be created, operations continue at block <NUM>. If no additional child virtual machines should be created, operations continue at block <NUM>.

At block <NUM>, the VM forking manager collects log data from the child virtual machine(s) which indicate execution behavior of the software sample. For cases in which more than one child virtual machine was created for malware analysis of the software sample, because monitoring of the software sample in each child virtual machine may complete at different times, the VM forking manager can collect the log data from each child virtual machine as the monitoring of the software sample in the virtual machine is completed. The child virtual machine may be configured to report log data to the VM forking manager (e.g., via an agent with which the VM forking manager can communicate).

At block <NUM>, the VM forking manager terminates the child virtual machine(s). A child virtual machine may be terminated after the monitoring has completed and the log data has been collected by the VM forking manger. The VM forking manager can issue an instruction or command to terminate the child virtual machine(s) based on terminating the respective child process(es), such as by issuing a kill() system call for each child process which indicates the respective process ID. Because each of the child virtual machines were created in a separate process from that of the virtual machine from which it was forked, killing the process of the child virtual machine will not affect the parent process, so the virtual machine of the parent process will continue to run and will be available for subsequent forking upon identification of additional software samples indicated for malware analysis. Termination of the child virtual machine will also result in discarding the delta disk created for the child virtual machine and indicating the memory written to by the child process as available without affecting the virtual disk and memory of the parent process.

At block <NUM>, the VM forking manger analyzes log data to determine if malicious behavior is indicated. The log data indicates behavior patterns of the software sample based on monitoring the software sample in each of the child virtual machines. The VM forking manager analyzes log data collected from each of the child virtual machines against one or more criteria, rules, etc. for malware detection. For instance, the VM forking manager may maintain rules or criteria which indicate behavior patterns corresponding to malicious activity. Malicious behavior can thus be determined to be indicated in the log data if one or more behavior patterns indicated in the log data satisfy a first of the rules or criteria.

At block <NUM>, the VM forking manager determines if indications of malicious behavior can be identified. The VM forking manger determines that indications of malicious behavior can be identified if the log data collected from at least one child virtual machine indicates malicious behavior of the software sample based on the analysis at block <NUM>. If indications of malicious behavior can be identified, operations continue at block <NUM>. If indications of malicious behavior cannot be identified, operations are complete.

At block <NUM>, the VM forking manager indicates that the software sample is malicious. For instance, the VM forking manager may generate a notification, alert, etc. which indicates that the software sample is malicious. Alternatively or in addition, the VM forking manager may notify a network component at which the software sample was detected (e.g., a firewall) that subsequent network traffic which includes the software sample should be blocked.

<FIG> depicts a flowchart of example operations for creating a copy of a virtual machine in a child process that is forked from a process corresponding to the virtual machine. The example operations are described with reference to a virtual machine forking manager (hereinafter the "VM forking manager") for consistency with the earlier figures.

At block <NUM>, the VM forking manager pauses a virtual machine to be forked. The VM forking manager alters the state of the virtual machine from active to paused to temporarily suspend read/write operations in the process while creating the child virtual machine that is based on the virtual machine. For instance, the VM forking manager can issue a command to quiesce or suspend the virtual machine.

At block <NUM>, the VM forking manager forks a process of the virtual machine with a copy-on-write implemented fork. The VM forking manager may make or communicate an instruction to the process of the virtual machine to make a system call to fork() from the process of the virtual machine. The fork() which is called is a copy-on-write implemented fork to provide improved performance when creating the child virtual machine in the child process. For instance, rather than copying all physical memory corresponding to virtual memory of the parent process at the time of the fork, pages of physical memory to which virtual pages of the parent process map can be marked read-only (e.g., in the respective entries in the page table) and reference counts for each physical page initialized at the time of the process fork. Pages of the virtual memory of the child process will then initially reference the same physical memory as the pages of the virtual memory of the parent process. Copying and allocation of new physical memory for the child process will be deferred until first attempted write to memory marked as read-only.

At block <NUM>, the VM forking manager initiates a copy of register data associated with a virtual CPU of the virtual machine to registers associated with a virtual CPU allocated to the child virtual machine through a "deep copy. " As described in reference to <FIG>, copying of the register data associated with the virtual CPU of the parent process is handled through a deep copy so that copies of register data themselves are made for the child process rather than copying references to the register data alone. Register data for which a deep copy is performed include data stored in general-purpose registers, control register, debug register, model-specific register(s), etc. In some implementations, hardware-assisted virtualization may be enabled. In addition to the deep copy of the virtual CPUs, a deep copy can also be performed for structures associated with the implementation of hardware-assisted virtualization (e.g., deep copies of virtual machine control structure data, pointer(s) for nested paging implementations, etc.).

At block <NUM>, the VM forking manager creates a snapshot of the virtual disk of the virtual machine and a delta disk for the child process. The snapshot of the virtual disk which is created provides a read-only copy of the data written to the virtual disk by the parent process for access by the child process. The delta disk is created for the child process to use as a writable disk. The creation of a delta disk for disk write operations by the child process allows for disk writes to data blocks of the virtual disk marked read-only to be redirected to the delta disk on the first write attempt. The delta disk will thus provide disk storage which is unique to the child process and can be modified or discarded without affecting the virtual disk of the parent process.

At block <NUM>, the VM forking manager updates resources allocated to the child process to use the kernel-mode accessible system resources which were prepared based on the virtual machine. Once system resources have been prepared, resources of the child process are updated to allow the child virtual machine to run such that the kernel mode-accessible system resources prepared for the child process will be used rather than those of the parent. For instance, the VM forking manager may update a virtual machine control structure created and maintained for the child virtual machine, a pointer(s) maintained for a page table or nested page table which tracks physical memory allocated for the child process in which the child virtual machine runs, a program counter corresponding to the virtual CPU, etc..

The flowcharts are provided to aid in understanding the illustrations and are not to be used to limit scope of the claims. The flowcharts depict example operations that can vary within the scope of the claims. Additional operations may be performed; fewer operations may be performed; the operations may be performed in parallel; and the operations may be performed in a different order. For example, the operations depicted in blocks <NUM> and <NUM> can be performed in parallel or concurrently. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by program code. The program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable machine or apparatus.

As will be appreciated, aspects of the disclosure may be embodied as a system, method or program code/instructions stored in one or more machine-readable media. Accordingly, aspects may take the form of hardware, software (including firmware, resident software, micro-code, etc.), or a combination of software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system. " The functionality presented as individual modules/units in the example illustrations can be organized differently in accordance with any one of platform (operating system and/or hardware), application ecosystem, interfaces, programmer preferences, programming language, administrator preferences, etc..

Any combination of one or more machine readable medium(s) may be utilized. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable storage medium may be, for example, but not limited to, a system, apparatus, or device, that employs any one of or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technology to store program code. More specific examples (a non-exhaustive list) of the machine readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine readable storage medium is not a machine readable signal medium.

A machine readable signal medium may include a propagated data signal with machine readable program code embodied therein, for example, in baseband or as part of a carrier wave. A machine readable signal medium may be any machine readable medium that is not a machine readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a machine readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The program code/instructions may also be stored in a machine readable medium that can direct a machine to function in a particular manner, such that the instructions stored in the machine readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

<FIG> depicts an example computer system with a virtual machine forking manager. The computer system includes a processor <NUM> (possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The computer system includes memory <NUM>. The memory <NUM> may be system memory or any one or more of the above already described possible realizations of machine-readable media. The computer system also includes a bus <NUM> and a network interface <NUM>. The system also includes virtual machine forking manager <NUM>. The virtual machine forking manager <NUM> manages forking of a child process(es) from a process(es) of a virtual machine(s) having installed a guest operating system with which a software sample indicated for malware analysis is compatible to create a child virtual machine(s) and indicates if the software sample is malware based on monitoring execution behavior of the software sample in the child virtual machine(s). Any one of the previously described functionalities may be partially (or entirely) implemented in hardware and/or on the processor <NUM>. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor <NUM>, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated in <FIG> (e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor <NUM> and the network interface <NUM> are coupled to the bus <NUM>. Although illustrated as being coupled to the bus <NUM>, the memory <NUM> may be coupled to the processor <NUM>.

While the aspects of the disclosure are described with reference to various implementations and exploitations, it will be understood that these aspects are illustrative and that the scope of the claims is not limited to them. In general, techniques for malware analysis of software samples based on virtual machine forking as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.

Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the disclosure. In general, structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure.

Claim 1:
A method, comprising:
based on indication of a first software sample for malware analysis, identifying (<NUM>; <NUM>) a first virtual machine of a plurality of virtual machines (<NUM>, <NUM>, <NUM>) having installed a first guest operating system compatible with the first software sample;
forking (<NUM>; <NUM>) a first process of the first virtual machine to create a first child process with a second virtual machine (<NUM>; <NUM>) based, at least in part, on the first virtual machine, wherein forking the first process comprises:
performing a deep copy of data stored in registers corresponding to a virtual central processing unit, 'CPU', of the first virtual machine into registers corresponding to a virtual CPU allocated to the second virtual machine;
marking physical memory pages (201A, 201B, 201C, 201D), to which virtual memory pages written by the first process map, as read-only; and
generating a read-only version of a virtual disk of the first process and generating a delta disk for the first child process for use as a writable disk;
loading (<NUM>; <NUM>) the first software sample into the second virtual machine; and
based on analysis of behavior of the first software sample in the second virtual machine, indicating (<NUM>; <NUM>) whether the first software sample is malware.