Selective virtualization for security threat detection

Abstract

Selective virtualization of resources is provided, where the resources may be intercepted and services or the resources may be intercepted and redirected. Virtualization logic monitors for one or more activities that are performed in connection with one or more resources and conducted during processing of an object within the virtual machine. The first virtualization logic further selectively virtualizes resources associated with the one or more activities that are initiated during the processing of the object within the virtual machine by at least redirecting a first request of a plurality of requests to a different resource than requesting by a monitored activity of the one or more activities.

Description

FIELD

Embodiments of the disclosure relate to the field of cyber security. More specifically, embodiments of the disclosure relate to a system and method for selectively virtualizing resources to control associations between resources and processes that are operating within a VM-based sandbox environment and are being monitored to detect a threat in the form of a malicious attack.

GENERAL BACKGROUND

Computers and other network devices deployed within an enterprise network rely on virtualization solutions for accessing system resources. For instance, applications, files or even registry values may be virtualized. However, such virtualization requires complete interception and redirection of user/application requests directed to a virtualized system resource, which can interfere with the detection of malicious behavior by the network device that is caused by an exploit or malware present in the device (generally referred to as a “security threat”).

Currently, there exist security appliances that operate within an enterprise network and utilize one or more virtual machines (hereinafter referred to as “VMs”) for analysis of network traffic for maliciousness. According to one deployment, each VM is configured to execute multiple processes concurrently (e.g., operating at least partially at the same time), where two or more of these processes support different versions of application software. Concurrent execution of multiple processes within a VM provides a more comprehensive threat detection solution than single process execution; however, it is extremely difficult to maintain and validate the accuracy of multiple installed applications, as well as to guarantee desired installed software configuration/plugins associations. In fact, installation of multiple versions of the same application may result in a software deployment that does not exist, and perhaps would have never existed on any end-user machine or backend server. Hence, the execution environment may not appear as a “real” machine to a security threat.

For instance, during installation of a new or updated version of application software, some older software components (e.g., dynamic-link library “dll”) may be overwritten with newer versions. As a result, certain malicious attacks may not be observed. For example, multiple versions of Microsoft® Office® may be installed within a system and supported by a VM, such as Office® 2007, Office® 2010 and Office® 2013. During installation, Office® 2007 installs a first dll to the system. During installation of Office® 2010, however, the first dll may be overwritten with a newer version. The removal of the first dll may configure the VM differently than its intended configuration for threat detection, which may cause some malicious attacks to go undetected. Hence, labor intensive reviews are required to ensure that, after undergoing any type of software configuration, a VM maintains an intended software configuration, which are costly and delay malware detection product releases.

More specifically, installing application versions 3.0 and 3.1 may result in an application runtime environment that is a combination of these application versions. If application version 3.0 loads a DLL (module), reads a registry key, or configuration file belonging to version 3.1, then the code path and memory layout result in a hybrid application version 3.0′, which is not equivalent to application version 3.0 or 3.1. If the area of logical change or memory layout change is the target of an exploit, the detection of the actual exploit may fail; however, such detection would have been successful, as the exploit may have run, on a real version 3.0 installation. These levels of runtime behavioral changes are difficult to validate during a quality assurance (QA) verification phase.

Additionally, each process may launch its corresponding application software with a selected software module that adds capabilities to existing application software, such as a unique version of an application plug-in. Hence, the VMs may have the same application software (e.g., Microsoft® Internet Explorer® version 9), but use different flash players (e.g., Adobe® Flash player 13 for one application version and Adobe® Flash player 16 for another application version).

The interchangeability between application software and plug-ins provides a multiplexed virtualization scheme where different versions of virtualized application software may be intentionally associated with different virtualized application plug-ins in order to increase the breadth of malware detection. However, due to the presence of time-out conditions, which require initialization of application plug-ins to be completed within a prescribed period of time after the application software has launched in the VM, it is contemplated that VMs within security appliances may not be configured with an intended application plug-in. Rather, in response to an occurrence of a time-out prior to completing initialization of an application plug-in, the virtualized application software may attempt an association with another application plug-in (e.g., a different version of application plug-in). Hence, again, the VM is now set with a configuration that is different than its intended configuration for threat detection. Without virtualization support it is very difficult to “correctly” simultaneously launch and utilize multiple plugins in multiple applications.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

FIG. 1 is an exemplary block diagram of a network deploying a threat detection platform (TDP) that conducts selective virtualization of resources.

FIG. 2 is an exemplary block diagram of a process with its threads, resources, and logic operating in accordance with one embodiment of the invention.

FIG. 3 is an exemplary embodiment of a logical representation of the first TDP of FIG. 1.

FIG. 4A is a first exemplary embodiment illustrating a logical representation of a first virtualization logic and a second virtualization logic that are configured to conduct selective virtualization of resources within a first virtual machine (VM) operating within the first TDP of FIG. 1.

FIG. 4B is an exemplary embodiment of a usage pattern for configuration of virtualization logic within the first VM of FIG. 4A and FIG. 6.

FIGS. 5A and 5B are logical representations that illustrate the functionality of the first virtualization logic and the second virtualization logic of FIG. 4A.

FIG. 6 is a second exemplary embodiment illustrating a logical representation of the first virtualization logic and the second virtualization logic that performs selective virtualization of resources within the first TDP of FIG. 1.

FIG. 7 is a third exemplary embodiment illustrating a logical representation of virtualization logic deployed within a hypervisor that is configured to conduct selective virtualization of one or more requested resources.

FIG. 8 is an exemplary embodiment of an illustrative platform that conducts selective virtualization of resources for malware detection.

FIG. 9 is fourth exemplary embodiment illustrating a logical representation of virtualization logic deployed within a light hypervisor that is deployed within a platform and configured to conduct selective virtualization of resources for malware detection.

DETAILED DESCRIPTION

Various embodiments of the disclosure relate to a platform configured with logic that conducts selective virtualization of resources or even entire applications to enhance malware detection. This selective virtualization may be adapted to control the association between processes and resources in order to provide a more comprehensive analysis for the presence of exploits and/or malicious code (hereinafter collectively referred to as “malware”) in an object under analysis.

According to one embodiment of the disclosure, the selective virtualization may be conducted to individual resources (e.g., files, registry key values, network ports, dynamic-link libraries, plug-in applications, etc.), which generally involves transparently modifying access to that resource and ensuring a reliable association between these resources and processes operating within a virtual machine (VM). Alternatively, the selective virtualization may be conducted in connection with a virtualized application (herein an “application package” described below). Both of these deployments may further utilize selective virtualization to obfuscate the presence of duplicated versions of resources (e.g., multiple versions of application software, dynamic-link libraries, etc.) that, if detected by malware that is present in an object under analysis, may allow the malware to evade detection by delaying activation.

According to a first embodiment of the disclosure, virtualization logic may be implemented as part of the user mode and/or the kernel mode of a virtual machine. The virtualization logic is configured to perform different virtualization operations based, at least in part, on the type of activity to be conducted to a resource in accordance with a monitored request. For instance, the virtualization logic may (i) intercept and redirect the request to a different portion of system code than originally targeted when the request is directed to a first subset of activities; and/or (ii) intercept and service the request when the request is directed to a second subset of activities.

Of course, it is contemplated that, for certain activities that are part of the first subset of activities, the data returned by the system code may be intercepted and manipulated by the virtualization logic prior to returning that data to the portion of the process that initiated the request. For instance, with respect to a Query Process request to list all active processes, the virtualization logic may intercept the returned data from the system code in order to obfuscate the presence of a certain process or processes so that it appears that a lesser number of processes are running on the platform.

More specifically, according to this embodiment of the disclosure, the virtualization logic comprises a first virtualization logic deployed in user mode of the virtual machine and a second virtualization logic deployed in kernel mode of the virtual machine. The first virtualization logic is configured to intercept and redirect a first type of request, which is associated with a particular activity that is independent of kernel involvement, to system code. Additionally, the first virtualization logic is configured to intercept a second type of request, which is associated with a particular activity that can be serviced by returning a value to a portion of the process that initiated that request.

Herein, the virtualization performed by the first virtualization logic is selective based, at least in part, on configuration data that may include a list of usage patterns provided from a source external to the VM. Each of the usage patterns comprises (1) one or more criterion that selectively control where a requested resource is subject to virtualization; and (2) the activities to be undertaken to perform such virtualization. As a result, the usage patterns provided to the first virtualization logic may differ from the usage patterns provided to the second virtualization logic. Alternatively, the configuration data, inclusive of the list of usage patterns, may be provided based on these patterns that are integrated into a VM (software) profile, implemented within a hypervisor (also referred to as a virtual machine monitor “VMM”), and/or implemented within a light hypervisor (VMM-LITE), as described below. The salient aspect is that the configuration data may be externally sourced, internally sourced, static, and/or updateable.

More specifically, the first virtualization logic may receive and store the provided usage patterns, which may be updated in a periodic or aperiodic manner. In response to detecting a request that is directed to a specific resource identified in one of the stored usage patterns, the first virtualization logic conducts one or more activities identified in that stored usage pattern. An example of such activities may involve redirecting the request by changing a file path associated with a Query Process Handle request and providing the modified Query Process Handle request to the system code. Another example may involve servicing a Query Window Handle request with a virtualized foreground window handle to account for keylogging malware that may have initiated the request.

Similarly, the second virtualization logic deployed within kernel mode may (i) intercept and redirect a third type of request, which is directed to a kernel-based activity, to the system code, and/or (ii) intercept a fourth type of request, which is directed to an activity that can be serviced by returning a value to a portion of the process that initiated the request. The first, second, third and fourth types of requests may be mutually exclusive.

The second virtualization logic receives and stores the usage patterns, which also may be updated in a periodic or aperiodic manner. In response to detecting a request that is directed to a particular system resource that matches a resource to undergo virtualization, the second virtualization logic conducts the activities identified in the stored usage pattern. An example of such activities may involve redirecting an Open File request by changing a file path to open a different file and providing the modified Open File request to the system code. Another example may involve servicing a Query Registry Value request by returning a value provided in a corresponding usage pattern.

It is contemplated that, instead of conducting virtualization of a particular resource (e.g., files, registry keys, etc.), which generally involves transparently modifying access to that resource, application software may be virtualized at the time of installation, thereby creating corresponding virtualized application packages. Each virtualized application package comprises registry data, file data, and other information that emulates the functionality of the virtualized application. This allows for virtualization of resources by fetching data within the virtualized application and/or obfuscation of different versions of applications running in the VM.

According to a second embodiment of the disclosure, instead of configuring the VM to conduct virtualization within the user mode and kernel mode, the virtualization logic may be deployed within a hypervisor. The hypervisor is configured to intercept and redirect requests associated with a first subset of activities as well as to intercept and service requests associated with a second subset of activities, as described below.

According to a third embodiment of the disclosure, instead of configuring the VM to conduct virtualization within the user mode and kernel mode as described in connection with the first embodiment, the virtualization logic may be deployed within a thin-hypervisor (sometimes referred to as an “light hypervisor”). In lieu of redirecting requests to system code, however, the light hypervisor is configured to route the redirected requests to the kernel mode and user mode of the platform for processing.

I. Terminology

In the following description, certain terminology is used to describe aspects of the invention. For example, in certain situations, both terms “logic” and “engine” are representative of hardware, firmware and/or software that is configured to perform one or more functions. As hardware, logic (or engine) may include circuitry having data processing or storage functionality. Examples of such processing or storage circuitry may include, but is not limited or restricted to a (hardware) processor; one or more processor cores; a programmable gate array; a microcontroller; an application specific integrated circuit; receiver, transmitter and/or transceiver circuitry; storage medium including semiconductor memory or a drive; or combinatorial logic, or combinations of one or more of the above components.

Logic (or engine) may be in the form of one or more software modules, such as executable code in the form of an executable application, an application programming interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, source code, object code, a shared library or dynamic-link library (dll), or one or more instructions. These software modules may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of a “non-transitory storage medium” may include, but are not limited or restricted to a programmable circuit; non-persistent storage such as volatile memory (e.g., any type of random access memory “RAM”); persistent storage such as non-volatile memory (e.g., read-only memory “ROM”, power-backed RAM, flash memory, phase-change memory, etc.), a solid-state drive, hard disk drive, an optical disc drive, or a portable memory device; and/or a semiconductor memory. As firmware, the executable code is stored in persistent storage.

The term “object” generally refers to a collection of data, whether in transit (e.g., over a network) or at rest (e.g., stored), often having a logical structure or organization that enables it to be classified for purposes of analysis. During analysis, for example, the object may exhibit a set of expected behaviors. The object may also exhibit a set of unexpected behaviors systematic of malicious activity that may provide evidence that the object may be classified as malicious.

In general, a “process” is an instance of software that is executed, sometimes in a virtual environment, for the processing of an object. It is contemplated that multiple processes may operate concurrently within a virtual machine or may operate successively with one process that is active (running) with any other processes being placed in an inactive (wait) state. A process may include multiple threads of execution (“threads”), where each thread is responsible for conducting different operations to the object and may operate successively or concurrently within the process. The processes and/or threads may share state information, memory and other resources.

A “platform” generally refers to an electronic device with connectivity to an external data source (e.g., network, other electronic device, etc.) that typically includes a housing that protects, and sometimes encases, circuitry with data processing and/or data storage. Examples of a platform may include a server or an endpoint device that may include, but is not limited or restricted to a stationary or portable computer including a desktop computer, laptop, electronic reader, netbook or tablet; a smartphone; a video-game console; or wearable technology (e.g., smart watch, etc.).

A “request” generally refers to information transmitted in a prescribed format that is requesting a particular activity to occur, normally in connection with various types of resources. Examples of these types of resources may include a file, a registry key, a socket (network) or other connector.

The term “transmission medium” is a physical or logical communication path with an endpoint device. For instance, the communication path may include wired and/or wireless segments. Examples of wired and/or wireless segments include electrical wiring, optical fiber, cable, bus trace, or a wireless channel using infrared, radio frequency (RF), or any other wired/wireless signaling mechanism.

The term “computerized” generally represents that any corresponding operations are conducted by hardware in combination with software and/or firmware.

Lastly, the terms “or” and “and/or” as used herein are to be interpreted as inclusive or meaning any one or any combination. Therefore, “A, B or C” or “A, B and/or C” mean “any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

As this invention is susceptible to embodiments of many different forms, it is intended that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

II. General Architecture

Referring to FIG. 1, an exemplary block diagram of a network 100 deploying a plurality of threat detection platforms (TDP) 110₁-110_N (N>1, where N=3 for this embodiment) communicatively coupled to a management system 120 via a network 125 is shown. In general, the management system 120 is adapted to manage each TDP 110₁-110₃. For instance, the management system 120 may be configured to perform content updates within a processing engine 135 operating as part of a communication interface, a static analysis engine 140, a dynamic analysis engine 160, a classification engine 180, and/or a reporting engine 190 with an optional user interface capability. For example, the content update may include rules changes (e.g., add/delete/modify rules or parameters that are utilized by the rules, etc.), which may be used by the static analysis engine 140 and/or the dynamic analysis engine 160 to detect malicious behavior. Another content update may include changes to usage patterns, which are utilized by virtualization logic within the dynamic analysis engine 160 to selectively determine whether or not to virtualize a particular resource (e.g., a requested service to a particular software component that is needed for functionality of an application) or even an entire application, as described below.

As shown in FIG. 1, a first threat detection platform (TDP) 110₁ is an electronic device that is adapted to analyze information associated with incoming data (e.g., network traffic propagating over a communication network 132, input data from another type of transmission medium including a dedicated transmission medium, etc.). As this illustrative embodiment, the first TDP 110₁ is communicatively coupled with the communication network 132 via an interface 136, where the communication network 132 may include a public network such as the Internet, a private network (e.g., a local area network “LAN”, wireless LAN, etc.), or a combination thereof. The interface 136 operates as a data capturing device that intercepts (or alternatively duplicates) at least a portion of incoming data and perhaps its corresponding metadata. Alternatively, although not shown, the interface 136 may be configured to receive files or other objects that are not provided over a network. For instance, as an example, the interface 136 may be a data capturing device that automatically (or on command), accessing data stored in a storage system or another type of interface, such as a port, for receiving objects manually provided via a suitable dedicated communication link or from storage media such as portable flash drives.

In some embodiments, although not shown, interface 136 may be contained within the first TDP 110₁. In other embodiments, the interface 136 can be integrated into an intermediary device in the communication path (e.g., a firewall, router, switch or other networked electronic device) or can be a standalone component, such as an appropriate commercially available network tap.

For this illustrative embodiment, however, the interface 136 may be configured to capture data that includes at least one object for analysis, and perhaps its corresponding metadata (or generate metadata based on the captured data). The metadata may be used, at least in part, to determine protocols, application types and other information that may be used by logic (e.g., scheduler 150 or virtual machine monitor) within the first TDP 110₁ to determine particular software profile(s) used for virtual machine (VM) configuration and/or VM operation scheduling. For instance, the software profile(s) may be used for selecting and/or configuring one or more virtual machines (VMs) 163₁-163_M (M≥1) within a virtual analysis environment 162 of the dynamic analysis engine 160. These software profile(s) may be directed to different software or different versions of the same software application extracted from software image(s) fetched from a storage device 155.

As further shown in FIG. 1, the first TDP 110₁ includes processing engine 135, static analysis engine 140, scheduler 150, storage device 155, dynamic analysis engine 160, classification engine 180, and/or reporting engine 190. Herein, the processing engine 135 receives an object and converts that object into a format, as need or appropriate, on which deep scanning by the static analysis engine 140 if implemented in the first TDP 110. This conversion and scanning may involve decompression of the object, decompilation of the object, extraction of specific data associated with the object, and/or emulation of the extracted data (like Javascript).

The static analysis engine 140 may include processing circuitry that is responsible for extracting and/or generating metadata contained within and/or associated with incoming data from the processing engine 135 (e.g., network traffic, downloaded data). This metadata may be subsequently used for configuring one or more VMs 163₁-163_M within the virtual analysis environment 162 for conducting a dynamic analysis of the object associated with that metadata.

Referring still to FIG. 1, the static analysis engine 140 analyzes features for one or more incoming objects 145, which may be a portion of network traffic (or downloaded data) according to this embodiment of the disclosure. Such analysis may involve the performance of one or more checks on the object 145 without its execution. Examples of the checks may include signature matching to conduct (a) exploit signature checks, which may be adapted to compare at least a portion of the object under analysis with one or more pre-stored exploit signatures (pre-configured and predetermined attack patterns) from signature database (not shown), and/or (b) vulnerability signature checks that may be adapted to uncover deviations in messaging practices (e.g., non-compliance in communication protocols, message formats or ordering, and/or payload parameters including size). Other examples of these checks may include (i) heuristics, which is based on rules or policies as applied to the object and may determine whether one or more portions of the object under analysis is associated with an anomalous or suspicious characteristic (e.g., a particular URL associated with known exploits, or a particular source or destination address etc.) associated with known exploits; or (ii) determinative rule-based analysis that may include blacklist or whitelist checking.

Upon static analysis of the features of the object 145, the static analysis engine 140 determines whether this object is “suspicious,” namely the object 145 has features that suggest it is associated with a malicious attack. As a result, the static analysis engine 140 may pass this suspicious object 148 to the dynamic analysis engine 160 for more in-depth analysis in a VM-based operating environment.

More specifically, after analysis of the features of the object 145 has been completed, the static analysis engine 140 may provide some or all of the object 145 as the suspicious object 148 to the dynamic analysis engine 160 for in-depth dynamic analysis by one or more VMs 163₁-163_M of the virtual analysis environment 162. For instance, according to one embodiment of the disclosure, a first VM 163₁ may be adapted to execute one or more processes (e.g., process 164) for processing the suspicious object 148 and conduct selective virtualization during such processing.

Herein, according to one embodiment, the first VM 163₁ executes process 164, which processes suspicious object 148 and the behaviors during such processing are captured by a first monitoring logic 165 and a second monitoring logic 167. Operating in conjunction or closely with the process 164, the first monitoring logic 165 comprises first virtualization logic 166, which is configured to intercept requests initiated (by process 164) during processing of the suspicious object 148. In response to detecting requests associated with a first subset of activities that are handled by the first VM 163₁ in user mode (e.g., actions or inactions associated with a time query, a process handle query, etc.), the first virtualization logic 166 determines whether a resource associated with the request is to be virtualized. Such virtualization ensures an association between process 164 executing in the first VM 163₁ and specific resources in an effort to improve threat detection and/or obfuscate the presence of duplicated versions of an application and/or resource that may identify to malware that it is executing within a sandbox environment.

For instance, in response to a request for a handle for a particular application plug-in utilized by application software associated with the process 164, the first virtualization logic 166 accesses stored configuration data, perhaps including usage patterns or an application package, to determine whether the application plug-in is to be virtualized. If, according to the configuration data, the application plug-in identified in the request is to be virtualized to another version (or type) of application plug-in, the first virtualization logic 166 may redirect the request by altering a pointer contained in the request to a different application plug-in. As a result, the handle for the different application plug-in is returned to the portion of the process 164 that initiated the request.

Another virtualization operation may involve the first virtualization logic 166 receiving a time-of-day request, where the process 164 may be configured to focus its analysis on whether the suspicious object 148 includes time-bomb malware. Hence, the process 164 accesses stored configuration data to detect whether the resource (e.g., time-of-day value) is to be virtualized, and in response, the first virtualization logic 166 may service the request by altering the time-of-day to a time value different than the actual time in order to better detect time-bomb malware.

Additionally, in response to detecting requests associated with a second subset of activities that are handled by the first VM 163₁ in kernel mode (e.g., opening file, changing a registry key value, and/or establishing a network connection), the second virtualization logic 168 determines whether a system resource associated with the request is to be virtualized. This may be accomplished by the second virtualization logic 168 accessing stored configuration data, perhaps including usage patterns or the application package to determine whether the system resource associated with the request is to be virtualized. If so, the second virtualization logic 168 alters the system resource (e.g., pointer to a first file) to a virtualized resource (e.g., pointer to a second file that is different than the first file). As a result, for this example, the second (virtual) file is opened in lieu of the first file.

Referring still to FIG. 1, the scheduler 150 may be adapted to configure one or more VMs 163₁-163_M based on metadata associated with the suspicious object 148 in order to process the suspicious object 148 at a desired time, for a desired period of time and/or in a desired order. For instance, the first VM 163₁ may be configured to run multiple processes, each configured with a different software profile corresponding to software images stored within storage device 155. As an alternative embodiment, the first VM 163₁ may be configured to run multiple processes, each configured according to a software configuration that may be used by an electronic device connected to a particular enterprise network (e.g., endpoint device(s) 130) or a prevalent type of software configuration (e.g., a particular version of Windows® OS and/or a particular version of a web browser with a particular application plug-in). The processes run in the first VM 163₁ may be performed concurrently or sequentially. Of course, it is contemplated that the VM configuration described above may be handled by logic other than the scheduler 150.

According to one embodiment of the disclosure, the dynamic analysis engine 160 may be adapted to execute one or more VMs 163₁-163_M that simulate processing of the suspicious object 148 within a run-time environment. For instance, dynamic analysis engine 160 may include processing logic 161 to provide anticipated signaling to the VM(s) 163₁, . . . , and/or 163_M during virtual processing, and as such, emulate a source of and/or destination for communications with the suspicious object 148. As an example, the processing logic 161 may be adapted to operate in combination with process 164 to provide simulated key inputs from a keyboard, keypad or touch screen, as requested by the suspicious object 148.

More specifically, as shown in FIG. 2 as an illustrative embodiment, the process 164 comprises one or more threads 200₁-200_I (e.g., I≥1) that may operate concurrently and/or sequentially with each other in order to perform various operations with respect to the suspicious object 148. One of these threads 200₁-200_I (e.g., first thread 200₁) may be directed to opening a browser application that is handled by the second monitoring logic 167 while another thread (e.g., second thread 200₂) may be directed to an operation of fetching the window handle (name) or an actual time of processing, which is handled by the first monitoring logic 165.

Applications may have a single thread 200₁ of execution or I-number of threads, 200₁-200_I. The cases discussing multiple threads of interactions may degenerate to the single thread cases. Not all processes have multiple threads.

The processing of the first thread 200₁ may cause certain activities to occur such as opening the browser application, where other threads (not shown) may cause other activities to occur (e.g., establishing I/O connections, detecting keystrokes, and/or displaying data). These activities (sometimes also referred to as “events”) are monitored by second monitoring logic 168. In contrast, the processing of the second thread 200₂ may cause certain events to occur such as accessing a real-time clock, where if the event is to be virtualized, may service a different time than provided by the real-time clock.

As still shown in FIG. 2, the process 164 comprises an instance of executable software which may include (1) multiple threads of execution 200₁-200₁ that may execute instructions concurrently and (2) software components 210 for the process 164. For instance, as shown, the process 164 includes descriptors 220 for resources that are allocated to the process 164 (e.g., process handles, etc.) and a memory 230 (e.g., a region of virtual memory). The memory 230 may be adapted to store a call stack 240 that keeps track of active subroutines and/or other events, a heap 250 to hold intermediate computation data generated during run time, and/or state information 260 (context) such as the content of registers, physical memory addressing or the like during thread execution. The first monitoring logic 165 operations in conjunction with the process 164, and may be injected as part of the process 164 or separate from the process 164.

Referring to both FIG. 1 and FIG. 2, depending on the type of activity associated with a request initiated by the process 164 (or threat 200₁), the first virtualization logic 166 or the second virtualization logic 168 is configured to intercept the request. In response to determining that resources pertaining to the request are to be virtualized in accordance with the usage patterns associated with user-mode based activities, the first virtualization logic 166 either (i) performs redirection operations on the request before passing the request to the system code or (ii) services the request by providing data back to the portion of the process 164 (or thread 200₁) initiating the request. Similarly, in response to determining that resources pertaining to the request are to be virtualized in accordance with the usage patterns associated with kernel-mode based activities, the second virtualization logic 168 either (i) performs redirection operations on the request before passing the request to the system code or (ii) services the request by returning data to the portion of the process 164 that initiated the request. Both the first monitoring logic 165 and the second monitoring logic 167 communicate information associated with the events and their corresponding event metadata into an event log 169, where the logged events may include all of the events or a subset of the monitored events such as anomalous events as described above. It is contemplated that the event log 169 may be located as storage for the first VM 163₁ or may be storage residing in the hypervisor (VMM) of FIG. 7, the light hypervisor of FIG. 9, or host software layers.

Referring to FIG. 1, the dynamic analysis engine 160 provides VM-based results 175 to the classification engine 180. According to one embodiment of the invention, the VM-based results 175 include information associated with the detected events for a particular process. According to one embodiment of the disclosure, the classification engine 180 includes logic that is configured to receive the VM-based result 175. Based at least partially on the VM-based results 175 that includes information associated with the monitored events associated with each process (and/or results 172 from static analysis engine 140), the classification engine 180 evaluates the events to determine whether the suspicious object 148 should be classified as “malicious,” where the object 148 is now considered to be associated with a malicious attack.

As shown in FIG. 1, the reporting engine 190 is configured to receive information from the object classification engine 180 and generate alerts 192, especially in response to the suspicious object 148 being now classified as malicious. The alerts may include various types of messages, which may include text messages and/or email messages, video or audio stream, or other types of information over a wired or wireless communication path. The reporting engine 190 features an optional user interface 194 (e.g., touch pad, keyed inputs, etc.) for customization as to the reporting configuration.

Referring now to FIG. 3, an exemplary embodiment of a logical representation of the first TDP 110₁ is shown. The first TDP 110₁ includes a housing 305, which is made entirely or partially of a hardened material (e.g., hardened plastic, metal, glass, composite or any combination thereof) that protect circuitry within the housing 305, namely one or more processors 300 that are coupled to communication interface logic 310 via a first transmission medium 320. Communication interface logic 310 enables communications with other TDP 110₂-110₃ and management system 120 of FIG. 1. According to one embodiment of the disclosure, communication interface logic 310 may be implemented as a physical interface including one or more ports for wired connectors. Additionally, or in the alternative, communication interface logic 310 may be implemented with one or more radio units for supporting wireless communications with other electronic devices.

Processor(s) 300 is further coupled to persistent storage 340 via a second transmission medium 330. According to one embodiment of the disclosure, persistent storage 340 may include (a) processing engine 135; (b) static analysis engine 140; (c) the dynamic analysis engine 160 that includes the processing logic 161 and the virtual analysis environment 162 that includes VM(s) 163₁-163_M with at least some of which including virtualization logic 166/168; (d) classification engine 180; (e) reporting engine 190; and/or (f) one or more data stores 350 that are utilized by processing engine 135, static analysis engine 140, dynamic analysis engine 160, classification engine 180, and/or reporting engine 190. Of course, when implemented as hardware, one or more of these engines (or logic units) could be implemented externally from the first TDP 110₁.

Collective logic within the dynamic analysis engine 160 may be configured to monitor and virtualize certain resources in order to enhance malware detection by (1) ensuring that certain resources are associated with certain processes so that desired virtual environments are maintained for testing; (2) obfuscating duplicative resources to provide an appearance of a normal operating environment to objects under analysis; and/or (3) alter the operating environment to customize to a particular environment that may be subject to a higher frequency of attack (e.g., content of a network device maintained by a high-ranking government employee, officer of a company, etc.).

III. VM-Based Selective Virtualization

Referring to FIG. 4A, a first representation of virtualization logic within the first VM 163₁ is shown, where this logic is configured to conduct selective virtualization of requested resources. At the time of configuration, the first VM 163₁ may be installed with the first virtualization logic 166 (which may be part of the first monitoring logic 165), the second virtualization logic 168 (which may be part of the second monitoring logic 167), and virtualization management logic 410. As shown, the virtualization management logic 410 may be located in the User mode 400 of the Guest VM 163₁ for illustrative purposes. Of course, it is contemplated that the virtualization management logic 410 may be located in the Kernel mode 460 of the Guest VM 163₁, in the hypervisor (VMM) 700 of FIG. 7, or the light hypervisor (VMM-LITE) 800 of FIG. 9. Similarly, the virtualization management logic 410 may be distributed in more than one layer. For example, the virtualization management logic 410 may split between Kernel mode 460 and VMM/UV layers.

The virtualization management logic 410 is responsible for configuring the user-mode configuration data 422 and 602 in FIG. 4A and FIG. 6, respectively. The virtualization management logic 410 is also responsible for configuring the kernel-mode configuration data 424 and 604 in FIG. 4A and FIG. 6, respectively. Of course, according to one embodiment of the disclosure, the first virtualization logic 166 and second virtualization logic 168 may directly implement hard-coded configuration data with minimal management overhead required, where updated configuration data may or may not be available via the virtualization management logic 410. Other embodiments envisioned may support varying degrees of configurability and remoteness of the source configuration data.

According to one embodiment of the disclosure, the first virtualization logic 166 is initially configured with access to virtualization configuration data 422 (hereinafter “configuration data”), which includes interception points 430 (e.g., hooks, breakpoints, filter drivers, etc.) that are used to identify selected requests for a resource or multiple resources that are to be virtualized.

For some embodiments, as shown for resource-specific virtualization in FIG. 4A, the configuration data 422 may further include a plurality of usage patterns 420₁-420_X (X≥1), where each usage pattern 420₁, . . . , or 420_X may be associated with one or more interception points 430. An usage pattern 420₁, . . . , or 420_X specifies a particular resource or resources to virtualize and the activities conducted for such virtualization. Of course, it is contemplated that, in lieu of usage patterns 420₁-420_X that are resource specific, another embodiment of the configuration data 422 may include a complete set of resources associated with a particular application, namely an application package that comprises registry data, file data, or other information that emulates the functionality of this virtualized application, which is represented as part of configuration data 602 illustrated in FIG. 6.

Additionally, the configuration data 422 may optionally include obfuscation data 440 that is used by the first virtualization logic 166 to obfuscate the presence of a resource or an entire set of resources (e.g., application package in FIG. 6) to avoid detection of such resource(s). For instance, handles may be substituted, data obtained from a Query request may be removed or added, error messages may be created, or the like. Illustrative examples of obfuscation that is controlled through use of the obfuscation data 422 by the first virtualization logic 166 may include, but are not limited or restricted to the following: (1) preventing display of certain information directed to a particular resource; (2) altering certain information associated with the resource so that it appears to be present in a platform represented by the first VM 163₁, and/or (3) renaming the resource.

It is contemplated that the configuration data 424, which is accessible to the second virtualization logic 168, may be identical or substantially identical to the configuration data 422 (e.g., identical usage patterns but different interception points), as shown. For instance, the interception points 430 accessible to the first virtualization logic 166 may differ from the interception points 432 accessible to the second virtualization logic 168. Alternatively, it is contemplated that the configuration data 422 may differ from the configuration data 424, as the usage patterns that are part of the configuration data 422 may differ from the usage patterns that are part of the configuration data 424 and/or the obfuscation data 440 that is part of the configuration data 422 may differ from the obfuscation data 442 that is part of the configuration data 424.

In general, each of the plurality of usage patterns 420₁-420_X may include criteria to selectively control which resources are subject to virtualization. Also, each of the plurality of usage patterns 420₁-420_X identifies the activities to be undertaken to perform such virtualization. According to one embodiment of the disclosure, as shown in FIG. 4B as an illustrative example, each of the plurality of usage patterns 420₁-420_X (e.g., usage pattern 420₁) may include a plurality of parameters 465, where each of these parameters represents a criterion in determining whether or not to perform virtualization in generating a virtualized resource in a response to a request for that resource. These parameters 465 are mutually exclusive, namely any combination of parameters 465 may be used in determination whether virtualization is conducted.

As an illustrative example, with respect to usage pattern 420₁, a first parameter 470, a second parameter 472 and/or a third parameter 474 may represent factors that are used to selectively determine whether to conduct a virtualization of one or more requested resources. These factors may be used to restrict the virtualization activities associated with the usage pattern 420₁ based on the particular type of object under analysis, the particular type of platform on which the object is being processed, or other metadata that further characterize the object and/or platform type.

For instance, as shown in FIG. 4B, the first parameter 470 may identify a particular type of object (or types of objects) that are subject to virtualization in accordance with the usage pattern 420₁. Examples of object types may include executables (exe), dynamic-linked library (dll), or portable document format (pdf). Similarly, the second parameter 472 may identify the particular type of platform (e.g., email server, web server, forensic appliance, endpoint device, etc.) that is subject to virtualization in accordance with the usage pattern 420₁. The third parameter 474 may identify further restrictions on the object or platform type (e.g., assigned a certain Internet Protocol “IP” address, a manufacture code, MAC address range, etc.) that is subject to virtualization in accordance with the usage pattern 420₁. These factors are provided, as it is foreseeable that different virtualization schemes may be conducted depending on the particular object and/or platform that is conducting the virtual analysis of the object.

As further shown in FIG. 4B, usage patterns 420₁ may further include other parameters that provide additional factors used to selectively control the virtualization of resources. For instance, a fourth parameter 476 is configured to include information that identifies one or more processes subject to this particular usage pattern 420₁ (hereinafter “process identifier”). For instance, virtualization may be restricted to a particular type of browser applications (e.g., FireFox®) or multiple types of browser applications (e.g., FireFox®, Chrome®, etc.).

As further shown in FIG. 4B, a fifth parameter 478 is configured to include information that identifies one or more threads subject to this particular usage pattern 420₁ (hereinafter “thread identifier”) where virtualization at a thread-level is conducted. A sixth parameter 480 may identify the type of resource to which this particular usage pattern 420₁ is directed, such as a handle, a file, or a registry key for example. A seventh parameter 482 may identify the particular virtualization scheme associated with the usage pattern 420₁. One virtualization scheme involves intercepting and servicing a request while another virtualization scheme involves intercepting and redirecting access to a different resource than identified in the request.

Additionally, an eighth parameter 484 may include an identifier of the particular resource that is to undergo virtualization (e.g., a particular handle, a path for accessing data such as a file path, a particular registry key value, etc.), and a ninth parameter 486 may include virtualized data for use in conducting the virtualization operation (e.g., an alternative handle, an alternative path, etc.).

As an optional feature, usage patterns directed to the redirection virtualization scheme (e.g., usage pattern 420₁) may further include a tenth parameter 488 that represents a virtualization flag to identify when virtualization occurs for an “intercept and redirect” virtualization scheme. Herein, the virtualization flag 488 may represent with a tri-state value; namely (1) “Enable” for virtualization of pre-operation data (prior to conducting operations associated with the request), (2) “Enable” for virtualization of post-operation data (data after conducting operations associated with the request), and (3) “Enable” for various output operations (Pre-operation and Post-operation).

According to one illustrative embodiment, the actual implementation may involve a multi-bit flag. As an illustrative example, the operations of the virtualization flag may comprise the following: (1) setting a first bit causes virtualization to occur at the input (pre-operation); (2) setting of a second bit causes virtualization to occur at the output (post-operation), in connection with the information returned from the system code; (3) setting of a third bit causes a first type of virtualization scheme to be conducted (e.g., intercept and service); and (4) setting of a fourth bit causes a second type of virtualization scheme (e.g., intercept and redirect) to be conducted. Of course, alternatively, another detection scheme besides use of a virtualization flag, such as a parameterized algorithm for example, may be used.

Referring back to FIG. 4A, during run time, within the user mode 400, the first VM 163₁ executes one or more processes 450₁-450_P (P≥1, where a first process 450₁ is equivalent to process 164). Herein, the first process 450₁ is initiated to process the suspicious object 148 of FIG. 1, and some or all of the events detected during processing of the suspicious object 148 are monitored by the first monitoring logic 165 and reported to the event log 169.

The virtualization management logic 410 includes the event log 169, event reporting logic 412 and configuration monitoring logic 414. According to one embodiment of the disclosure, the event reporting logic 412 is responsible for generating data 416 associated with the monitored events, which may be uploaded into the data store 170 and subsequently included as part of the VM-based results 175 provided to the classification engine 180 as illustrated in FIG. 1.

The configuration monitoring logic 414 is configured to detect an update 426 to the configuration data 422 and/or 424, which may be downloaded from management system 120, cloud services 138 and/or another TDP (e.g., TDP 110₂ or 110₃) of FIG. 1. These updates 426 may include, but are not limited or restricted to any or all of the following: (i) an additional interception point 434 to be added to interception points 430 and/or 432 (as shown); (ii) an additional usage pattern 420_X+1 to be added to configuration data 422 and/or 424 (as shown); (iii) additional obfuscation data 444 to be added to obfuscation data 440 and/or 442 (as shown); (iv) a modification to an existing interception point that is part of interception points 430 and/or 432; (v) a modification to an existing usage pattern that is part of usage patterns 420₁-420_X; (vi) a modification to existing obfuscation data that is part of obfuscation data 440 and/or 442; (vii) a deletion of an existing interception point that is part of interception points 430 and/or 432; (viii) a deletion of an existing usage pattern that is part of usage patterns 420₁-420_X; and/or (ix) a deletion of existing obfuscation data that is part of obfuscation data 440 and/or 442 within configuration data 422 and/or 424.

Additionally or in the alternative, in lieu of simply uploading and subsequent using the update configuration data 426 without modification, the content within one or more of the update usage patterns 426_X+1 may be altered prior to passing them to (i) the first virtualization logic 166 to update the configuration data 422 and/or (ii) the second virtualization logic 168 to update the configuration data 424. Modification in the content of one or more of the usage patterns, interception points and/or obfuscation data within configuration data 422/424 may be conducted by configuration monitoring logic 414 based on signaling 418 from an external source. The signaling 418 allows for customization of usage patterns, interception points and/or obfuscation data by a network administrator, which provides selective virtualization on a per customer basis.

As an illustrative example, when flash dlls are switched between multiple versions of a browser application, the flash-version/browser-version association may be dynamic in nature. Based on an external input, a first version of a browser application may be selected to operate with a particular flash version on a flash dll list. Subsequently, a different version of the browser application may be selected, but based on external input, the same particular flash version may get associated with this version of the browser application. In general terms, associations between resources and/or processes can be selectively controlled by the customer.

Referring still to FIG. 4A, the first virtualization logic 166 is responsible for selectively virtualizing resources requested by the first process 450₁ (or thread 200₁) operating within the first VM 163₁ in user mode 400. The requested resources may include process handle queries, window handle queries (e.g., query for handle of the foreground window), time-of-day queries, or the like. The second virtualization logic 168 is responsible for selectively virtualizing resources requested by the first process 450₁ that are normally handled in the kernel mode 460. These requested resources may include operations directed to file management (e.g., opening file, closing file, etc.), registry key management (e.g., obtaining registry key values), and/or network management (e.g., establish network connection, etc.) for example.

Referring now to FIG. 5A, the logical representation of the first virtualization logic 166 and the second virtualization logic 168 of FIG. 4A is shown. Herein, the first virtualization logic 166 features intercept logic 500, redirect logic 520 and servicing logic 540. In response to a request 505 being initiated by an active process (e.g., process 450₁) and identified (e.g., hooked) by one of the interception points 430, the intercept logic 500 intercepts the request 505.

Thereafter, the contents of the request 505 are analyzed to determine whether a resource associated with the request 505 is to be virtualized. The virtualization is selectively based, at least in part, on a number of mutually exclusive factors as identified in FIG. 4B, such as the type of object under analysis (e.g., exe, dll, pdf, etc.) and/or platform type (Web analysis, Email address, etc.). Such analysis may involve a comparison of content within the request 505 and/or metadata associated with the object 148 of FIG. 1 to content within one or more stored usage patterns 420₁-420_X that are associated with one of the interception points 430 that identified the request 505 (referred to herein as the “identifying intercept point 430”).

As an alternative, it is contemplated that, upon receipt of the request 505, the intercept logic 500 may be configured to determine the active process (or thread) that initiated the request 505 in lieu of reliance on correspondence between a particular interception point and one or more usage patterns. Thereafter, the intercept logic 500 may access some of the usage patterns 420₁-420y that are applicable to this process (or thread). It is noted that, for clarity sake, selective virtualization at a process-level is described, although selective virtualization at a thread-level may be conducted.

Upon detecting that the resource is to be virtualized, depending on the type of virtualization scheme to be utilized, the request 505 is provided to either the redirect logic 520 or the servicing logic 540 along with information to complete the request 505.

More specifically, as an illustrative example, upon receipt of the request 505, such as an API call that constitutes a foreground window handle query (hereinafter “Query Foreground Window Handle request”) from the first process 450₁ (and/or the particular thread of the first process 450₁), the intercept logic 500 may determine whether any of the usage patterns 420₁-420_X are associated with the identifying intercept point 430.

In response to identifying a subset of the usage patterns 420₁-420_X (e.g., usage patterns 420₁-420_Y, where 1≤Y≤X) that are associated with the identifying intercept point 430, the intercept logic 500 determines whether any of these usage patterns 420₁-420_Y correspond to a foreground window handle query and whether selected criterion within the usage patterns 420₁-420_Y (e.g., object type, or platform type, etc.) are satisfied by metadata associated with the object and/or information associated with the request 505. If so, the intercept logic 500 determines the virtualization scheme to be undertaken (e.g., intercept and service), and in response, may provide the request 505 and virtualized data 510 for servicing the request 505 via signaling (RTN_1). This virtualized data 510 may include a particular window handle (e.g., the handle for a particular browser type such as Internet Explorer®, FireFox®) and/or an address pointer or other type of identifier for the servicing logic 540 to procure the particular window handle. The particular window handle is returned by the servicing logic 540 to the portion of the first process 450₁ that initiated the request 505 in order to complete the request 505.

Of course, prior to servicing the request 505, it is contemplated that the intercept logic 500 may conduct further modifications to the virtualized data 510 in accordance with obfuscation data 440, such as removing one or more variables or other sensitive information associated with the virtualized data 510 or substituting the virtualized data 510 with data that causes the servicing logic 540 to return an error code. Thereafter, the virtualized data 510 would be passed to the servicing logic 540 to complete the request 505.

As another illustrative example, upon intercepting the request 505, such as an API call that constitutes a process handle query (hereinafter “Query Process Handle request”) from the first process 450₁, similar to the discussion above, the intercept logic 500 may determine whether any of the usage patterns 420₁-420_X correspond to the identifying intercept point 430.

In response to identifying a subset of the usage patterns 420₁-420_X (e.g., usage patterns 420₁-420_Y) that are applicable to identifying intercept point 430, the intercept logic 500 determines whether any of these usage patterns 420₁-420_Y correspond to a Query Process Handle request and whether selected criterion within usage patterns 420₁-420_Y (e.g., object type, or platform type, etc.) is satisfied by metadata associated with the object under analysis and/or information associated with the request 505. If so, according to one embodiment of the disclosure, the intercept logic 500 determines the virtualization scheme to be undertaken (e.g., intercept and redirect).

Responsive to the virtualization flag associated with that usage pattern being set to denote virtualization of input data, the intercept logic 500 provides the request 505 and the virtualized data 515 to the redirect logic 520. Examples of the virtualized data 515 may include an alternative path (C:\Program Files\ Common Files\Microsoft Shared\Backup\process_xyz.dll), which differs from the path (C: \Program Files\Common Files\Microsoft Shared\process_xyz.dll) normally associated with the Query Process Handle request for the first process 450₁.

Thereafter, the redirect logic 520 modifies the request 505 and forwards a modified Query Process Handle request 525 to the system code (not shown), which accesses resources targeted by the alternative path. The process handle associated with the alternative path (hereinafter referred to as the “virtualized process handle 530”) is returned to the redirect logic 520 and subsequently passed to the intercept logic 500. The intercept logic 500 provides the virtualized process handle 530 (and/or information associated with request 505) to the servicing logic 540 to complete the request 505.

It is contemplated that, prior to passing the virtualized process handle 530 to the servicing logic 540, the intercept logic 500 may conduct further modifications to the virtualized process handle 530 in accordance with obfuscation data 440, such as removing one or more variables associated with the virtualized process handle 530 so that only a subset of the returned variables are enumerated or substituting the virtualized process handle 530 with data that may cause the servicing logic 540 to return an error code. Thereafter, the modified, virtualized process handle 535 is passed to the servicing logic 540 to complete the request 505. Hence, obfuscation may be conducted after virtualization or, as described in FIG. 6 below, may be conducted concurrently or prior to virtualization.

Alternatively, as shown in FIG. 5B, upon determining the virtualization scheme to be undertaken (e.g., intercept and redirect) and the virtualization flag associated with that usage pattern is set to denote virtualization of returned data (output), the intercept logic 500 provides the request 505 with a path 524, normally associated with the Query Process Handle request for the first process 450₁, to the redirect logic 520. In response to requesting and receiving the process handle 532 from the system code (not shown), the redirect logic 520 passes the process handle 532 to the intercept logic 500, which now alters the process handle 532 and provides the modified process handle 537 (or information to procure the modified process handle 537) and/or the request 505 to the servicing logic 540. The servicing logic 540 returns the modified process handle 537 via signaling (RTN_1) to the portion of the process 450₁ that initiated the request 505 in order to complete the request 505.

It is contemplated that the intercept logic 500 may conduct further modifications to the modified process handle 537 in accordance with obfuscation data 440 in order to add and/or remove certain information before passing the handle 537 (or perhaps data associated with an error code) to the servicing logic 540 to complete the request 505.

Referring back to FIG. 5A, the second virtualization logic 168 features intercept logic 550, redirect logic 570 and servicing logic 590, which collectively operate in a manner similar to the intercept logic 500, redirect logic 520 and servicing logic 540 of the first virtualization logic 166. However, in contrast to the intercept logic 500 operating, at least in part, as an API hook, the intercept logic 550 of the second virtualization logic 168 is configured as a driver framework that provides callbacks in response to different types of requests that originated from an active process (e.g., process 4501) in user mode 400. Examples of these different types of requests include, but are not limited or restricted to requests involving file management (e.g., opening file, closing file, etc.); requests involving registry key management (e.g., obtaining registry key values); requests involving network management (e.g., establish network connection, etc.); and/or any other system call.

More specifically, the second virtualization logic 168 features intercept logic 550, redirect logic 570 and servicing logic 590. As described above, the request 505 may be intercepted by the intercept logic 550 and analyzed to determine whether a resource associated with the request 505 is to be virtualized. Such analysis may involve (i) determining which of the usage patterns (e.g., usage patterns 4201-420Z) are associated with a particular interception point that identified (e.g., hooked) the request 505 (referred to herein as the “identifying intercept point 432”) and (ii) comparing content within the request 505 and/or metadata associated with the object 148 of FIG. 1 that is being analyzed to selected criterion within the usage patterns 4201-420Z in order to determine whether virtualization is to be conducted for the resource identified in the request 505.

Upon detecting that the resource is to be virtualized, depending on the type of virtualization scheme to be utilized, the request 505 is provided to either the redirect logic 570 or the servicing logic 590 along with virtualized data to complete the request 505.

More specifically, as an illustrative example, upon receipt of the request 505 (e.g., a Query Registry Value request) from the first process 4501, the intercept logic 550 may determine whether any of the usage patterns 4201-420X are associated with the identifying intercept point 432. In response to identifying a subset of the usage patterns 4201-420X (e.g., usage patterns 4201-420Z) that are applicable to identifying intercept point 432, the intercept logic 550 determines whether any of these usage patterns 4201-420Y correspond to a Query Registry Value request and whether selected criterion within usage patterns 4201-420Z (e.g., object type, platform type, or the like in FIG. 4B) are satisfied by metadata associated with the object under analysis and/or information associated with the request 505.

If so, the intercept logic 550 determines the virtualization scheme to be undertaken (e.g., intercept and service), and in response, provides the request 505 and virtualized data 555 for servicing the request 505. This virtualized data 555 may include a particular registry key value and/or an address pointer or other type of identifier for the servicing logic 590 to procure the particular registry key value. The particular registry key value is returned by the servicing logic 590 via signaling (RTN_2) to the portion of the first process 4501 that initiated the request 505 in order to complete the request 505.

As another illustrative example, upon receipt of the request 505 (e.g., an Open File request) from the first process 4501, the intercept logic 550 may determine whether any of the usage patterns 4201-420X are applicable to the identifying intercept point 432. In response to identifying a subset of the usage patterns 4201-420X (e.g., usage patterns 4201-420Z) that are applicable to identifying intercept point 432, the intercept logic 550 determines whether any of these usage patterns 4201-420Z correspond to an Open File request and whether selected criterion within usage patterns 4201-420Z (e.g., object type, or platform type, etc.) are satisfied by metadata associated with the object under analysis and/or information associated with the request 505.

If so, according to one embodiment of the disclosure where the virtualization flag associated with that usage pattern being set to denote virtualization of input data, the intercept logic 550 determines the virtualization scheme to be undertaken (e.g., intercept and redirect), and in response, provides the request 505 and virtualized data 560, which may include an alternative file path (C://Program Files/Backup/file.pdf) that differs from the path (C://Program Files/Current/file.pdf) normally associated with the particular requested file, to the redirect logic 570.

Thereafter, the redirect logic 570 passes a modified Open File request 575 to the system code (not shown), which accesses a file referenced by the alternative file path. The file handle associated with the alternative file path (hereinafter referred to as the “virtualized file handle 580”) is returned to the redirect logic 570. The virtualized file handle 580 may be subsequently passed via the intercept logic 550 to the servicing logic 590 to complete the request 505. Of course, it is contemplated that the intercept logic 550 may conduct further modification to the virtualized file handle 580 in accordance with the obfuscation data 442, such as removing one or more variables associated with the virtualized file handle 580 or substituting the virtualized file handle 580 with data that causes the servicing logic 590 to return an error code. Thereafter, a modified, virtualized file handle 585 is returned by the servicing logic 590 to complete the request 505.

Alternatively, as shown in FIG. 5B, upon determining the virtualization scheme to be undertaken (e.g., intercept and redirect) and the virtualization flag associated with the usage pattern is set to denote virtualization of returned data (output), the intercept logic 550 provides the request 505 with a file path 562, which is normally associated with the Open File request for the requested file, to the redirect logic 570. In response to requesting and receiving a file handle 582 from the system code (not shown), the redirect logic 570 passes the file handle 582 to the intercept logic 550, which now alters the file handle 582 and provides the request 505 and/or a modified file handle 587 (or information to procure the modified file handle 587) to the servicing logic 590. The servicing logic 590 returns at least the modified file handle 587 via signaling (RTN_2) to the portion of the process 4501 that initiated the request 505 in order to complete the request 505.

It is contemplated that the intercept logic 550 may conduct further modifications to the modified file handle 587 in accordance with obfuscation data 442 in order to add and/or remove certain information before passing the handle 587 to the servicing logic 590 to complete the request 505.

Referring to FIG. 6, a second exemplary embodiment of the operability of logic within the user mode 400 and the kernel mode 460 of the first VM 1631 is shown. According to this embodiment, the configuration data 602 comprises application obfuscation data 612, interception points 622 and one or more application packages 632 (hereinafter “application package(s)”).

Herein, the obfuscation data 612 includes data that is configured to obfuscate the presence of application software. Illustrative examples of manners of obfuscation that are controlled through use of the obfuscation data 612 by the first virtualization logic 166 may include, but are not limited or restricted to the following: (1) preventing display of certain information associated with a particular application software; (2) altering display of certain information associated with the particular application software so that it appears to be present in the system; and/or (3) renaming the particular application software.

As further shown in FIG. 6, the interception points 622 (e.g., hooks, breakpoints, filter drivers, etc.) are used to identify selected requests for resources that are to be virtualized. Also, each of the application package(s) 632 includes registry data, file path data, and other information that emulates the functionality for that particular virtualized application. The servicing logic (not shown) within the first virtualization logic 166 may utilize the application package(s) 632 to obtain virtualized resources in order to service incoming requests.

At the time of configuration of the first VM 1631, the first virtualization logic 166, the second virtualization logic 168, and the virtualization management logic 410 are installed. The first virtualization logic 166 and the second virtualization logic 168 are initially configured with access to configuration data 602/604, which includes application obfuscation data 612/614, interception points 622/624 that are used to identify selected requests for resources that are virtualized, and/or application package(s) 632/634 that includes virtualized software components for one or more virtualized applications.

Herein, it is contemplated that application obfuscation data, namely obfuscation data 612 which is accessible to the first virtualization logic 166, may be identical to obfuscation data 614 that is accessible to the second virtualization logic 168. Alternatively, it is contemplated that the obfuscation data 612 may differ from the obfuscation data 614, as requests handled in user mode 400 differ from requests that are handled in kernel mode 460. The interception points 622/624 and/or the application package(s) 632/634 may be identical or may differ from each other as well.

In general, obfuscation data 612/614 identifies which virtualized resources or applications are to be obfuscated. The obfuscation data 612/614 may comprise an application type identifier, a handle (or name) of the application, and a tag that, when set, identifies that the application is to be obfuscated. When an application is obfuscated, the first virtualization logic 166 and/or the second virtualization logic 168 operate to preclude normal servicing of a request, which would identify the presence of an obfuscated application (e.g., particular Query Directory request, Query Application Handle request, etc.). For instance, upon detecting a directory request that would identify the presence of an application tagged for obfuscation, even though the application is running in the first VM 1631, the first virtualization logic 166 or the second virtualization logic 168 that is servicing the request returns an error code or a displayable statement, which is normally generated when the application is actually absent from the platform.

Referring still to FIG. 6, during run time, within the user mode 400, the first VM 1631 executes one or more processes 4501-450P. As previously stated, the first process 4501 may initiate processing of the suspicious object 148 of FIG. 1, and some or all of the events detected during processing of the suspicious object 148 are monitored by the first monitoring logic 165 and reported to the event log 169.

The virtualization management logic 410 includes the configuration monitoring logic 414, which is configured to detect an update to the configuration data 602 and/or 604, where the update configuration data 620 is downloaded from management system 120, cloud services 138 and/or another TDP (e.g., TDP 1102 or 1103) of FIG. 1. These updates 620 may be directed to adding an additional interception point 626, application-specific obfuscation data 616, and/or application package 636 within the configuration data 612 and/or 614; modifying an existing interception point 622/624, application-specific obfuscation data 612/614 and/or a particular application package that is part of the application package(s) 632/634 within configuration data 602/604; and/or deleting an existing interception point 622/624, application-specific obfuscation data 612/614 and/or a particular application package that is part of the application package(s) 632/634 within configuration data 602/604.

Referring still to FIG. 6, the first virtualization logic 166 is responsible for selectively virtualizing resources requested by the first process 4501 operating within the first VM 1631 in user mode 400. The requested resources may include directory queries, application or process queries, or the like. The second virtualization logic 168 is responsible for virtualizing resources requested by the first process 4501 that are normally handled in kernel mode 460. These requested resources may include operations directed to file management (e.g., opening file, closing file, etc.) and/or registry key management (e.g., obtaining registry key values), for example. Selective virtualization is accomplished by accessing information within stored application package(s) 632 and 634.

More specifically, upon receipt of the Query Directory request 630 (e.g., a Query for retrieval of stored applications, documents and other content) from a calling routine within the process 4501, the first virtualization logic 166 determines which of the interception points 622 identified (e.g., hooked) the Query Directory request 630 (hereinafter referred to as “identifying intercept point 622”).

Thereafter, the contents of the request 505 are analyzed to determine whether a resource associated with the request 630 is to be virtualized. The virtualization is selectively based, at least in part, on the presence of one of the application package(s) 632 that features the requested, virtualized resource. If so, the first virtualization logic 166 determines the virtualization scheme to be undertaken (e.g., intercept and service).

In response to determining that the virtualization scheme for the handling of a Query Directory request 630 is an “intercept and service” virtualization scheme, before servicing the request 505, the first virtualization logic 166 may access the obfuscation data 614 to identify those applications and/or resources that are selected to be hidden. Hence, the first virtualization logic 166 may return handles associated with applications, folders, documents and other items to the first process 4501, but would exclude handles associated with resources that are unique to any of the application package(s) 632 that are identified for obfuscation.

As another illustrative example, upon receipt of the request 640 (e.g., Open File request that is hooked during transmission from user mode 400 to kernel mode 460 by one of the interception points 624), the second virtualization logic 168 may determine which of the application package(s) 634 (e.g., a first application package 634) corresponds to the identifying intercept point 624 that hooked the request 640. According to one embodiment of the disclosure, before servicing the request 640 by fetching a file path from the first application package 634 to complete the Open File request 640, the second virtualization logic 168 may access the obfuscation data 614 to identify the first application package 634 or certain resources within the first application package 634 are subject to obfuscation.

In the event that the requested file is associated with the first application package 634, according to one embodiment of the disclosure, the second virtualization logic 168 generates a modified Open File request having an alternative file path (C://Program Files/error/msg1.txt). The alternative file path obfuscates the presence of the requested file which, in turn, may denote the presence of application software represented by the first application package. This obfuscation is conducted to reduce the possibility of malware evading detection by determining that the object is being processed in a sandbox environment (e.g., on the first VM 1631).

Thereafter, although not shown, the second virtualization logic 168 forwards a modified Open File request to the system code (not shown), which accesses the error message (msg1.txt) referenced by the alternative file path (C://Program Files/error/msg1.txt). The error message may be returned to the second virtualization logic 168 and subsequently serviced to complete the Open File request 640.

As yet another illustrative example, upon receipt of the request 640 (e.g., the Open File request), the second virtualization logic 168 may determine which of the application package(s) 634 (e.g., a first application package 634) correspond to the identifying intercept point 624 that hooked the request 640. In the event that the requested file is associated with the first application package 634, according to one embodiment of the disclosure, the second virtualization logic 168 determines what virtualization scheme is to be undertaken (e.g., intercept and redirect), and in response, the second virtualization logic 168 generates a modified Open File request having an alternative file path to a virtualized file that is part of the first application package 634.

Thereafter, although not shown, the second virtualization logic 168 forwards a modified Open File request to the system code (not shown), which returns information to the second virtualization logic 168 for opening the requested file. Prior to servicing the request 640, the first virtualization logic 166 may access the obfuscation data 614 to identify when applications and/or resources that are selected to be hidden. In response to detecting that the requested file is part of the obfuscated, first application package 634, the first virtualization logic 166 may return and error message (msg1.txt) to complete the Open File request 640.

It is contemplated that a hybrid selective virtualization scheme may be formulated by a combination of the operations described in FIGS. 5A-5B and 6, where a portion of the application that are present in multiple versions may be virtualized as the application package described in FIG. 6, while incompatible software components for these applications are virtualized as resources in accordance with FIGS. 5A-5B.

IV. VMM-Based Selective Virtualization

Referring now to FIG. 7, according to a second embodiment of the disclosure, instead of configuring a virtual machine to conduct virtualization within the user mode 400 and kernel mode 460 as shown in FIG. 1, virtualization logic 710 may be deployed within a hypervisor 700. Herein, the virtualization logic 710 is configured to virtualize resources by (i) intercepting and redirecting requests associated with a first subset of activities and (ii) intercepting and servicing requests associated with a second subset of activities, as described below. These requests may include a system call for a particular service such as hardware-related services (e.g., access to a storage device such as a hard disk drive), or process management (e.g., creation, termination, scheduling of a process). In a virtual analysis environment, a system call may be initiated from one or more processes 725 running in user mode 400 of a virtual machine (VM).

As shown, the hypervisor 700, also referred to as a virtual machine monitor (VMM), manages operability of one or more virtual machines (VM) 720₁-720_J (J≥1), including processing of the guest OS, and is configured to detect and control the handling of requests, including system calls. The hypervisor 700 may be a “Type 1” hypervisor that runs directly on hardware or a “Type 2” hypervisor that runs on a host operating system (Host OS). Herein, the hypervisor 700 runs on a Host 730, which may be hardware associated with the TDP 110₁ or its Host OS.

More specifically, according to one embodiment of the disclosure, one or more processes (not shown) may be running in user mode of a first VM 720₁. Each process may be assigned a unique process identifier (PID) at start time, or perhaps prior to or subsequent to execution by the first VM 720₁.

In communication with the first VM 720₁, the hypervisor 700 comprises VMM management logic 735 in communication with intercept logic 750, servicing logic 760 and redirect logic 770. In response to a request 740 (e.g., a system call) generated by process 725 during virtual processing of the suspicious object, the VMM management logic 735 temporarily halts execution the first VM 720₁. By halting execution, an instruction pointer is maintained at the virtual memory address associated with the request 740. Thereafter, the VMM management logic 735 invokes and passes operation control to the intercept logic 750.

The intercept logic 750 determines whether the request 740 is directed to a virtualized resource by determining an association between the interception point 753 that identified (e.g., hooked) the request 740 and one or more of the usage patterns 754₁-754_X. If the request 740 is directed to a virtualized resource, the intercept logic 750 determines what virtualization scheme is to be conducted in connection with the resource (e.g., Intercept & Service; Intercept & Redirect). Additionally, for selective virtualization involving intercepting and redirecting requests, the intercept logic 750 may further determine when the virtualization scheme is to be conducted (e.g., at input and/or output) through the tri-state virtualization flag described above.

For a first type of virtualization scheme (Intercept & Service), the intercept logic 750 invokes servicing logic 760, which analyzes state information associated with the first VM 720₁ to determine a memory location for placement of data returned in response to the request 740. Thereafter, the virtualized data is inserted into the memory location, the instruction pointer is changed to reference an end of a function associated with the system call 740, and the first VM 720₁ resumes. As a result, the first VM 720₁ continues as if the system call 740 has been completed.

For a second type of virtualization scheme (Intercept & Request), the intercept logic 750 invokes redirect logic 770 and provides the virtualized data 755 (e.g., an alternative path, alternative handle, etc.) to the redirect logic 770. Thereafter, the redirect logic 770 modifies the system call 740, returns the modified system call 745 to the first VM 720₁ to resume. As an optional feature, the process may be further altered by setting an interception point (e.g., breakpoint, call, etc.) at the end of the system call, which causes the hypervisor 700 to stop the process again and invoke the intercept logic 750. At this point, based on the configuration data, the redirect logic 770 may conduct further changes.

Alternatively, upon determining the virtualization scheme to be undertaken (e.g., intercept and redirect) and the virtualization flag is not set, the intercept logic 750 invokes the redirect logic 770, which inserts an interception point (e.g., breakpoint, API call, etc.) at the end of the system call 740, and causes the first VM 720₁ to resume. Upon completion of the system call, a call is initiated that prompts the hypervisor 700 to temporarily halt execution of the first VM 720₁ again and invoke the intercept logic 750. At this point, based on the configuration data 751, the redirect logic 770 may alter data associated with the requested resource.

More specifically, as an illustrative example, upon receipt of the request 740 (e.g., a Query Registry Value request) from a calling routine within a process, the hypervisor 700 temporarily halts operations of the first VM 720₁ and invokes the intercept logic 750. Initially, the intercept logic 750 accesses the configuration data 751 to determine whether the request 740 is associated with a prescribed interception point 753 (e.g., a particular hook, breakpoint, or API call). If so, the intercept logic 750 further accesses some or all of the usage patterns 754₁-754_X to determine criteria for conducting virtualization of a requested resource in accordance with the usage patterns 754₁-754_X, the type of request (“Query”) and the particular resource associated with the request 740 (registry_key_1).

In the event that the request 740 is directed to a virtualized resource (e.g., sufficient compliance with the criteria in at least one of the usage patterns such as usage pattern 754₁), the intercept logic 750 determines what virtualization scheme is to be conducted to the resource (e.g., Intercept & Service). The intercept logic 750 invokes and provides the request 740 and virtualized data 755 acquired from the usage pattern 754₁ to the servicing logic 760. The servicing logic 760 analyzes state information associated with the first VM 720₁ to determine a memory location for placement of the virtualized data to be returned for the value of registry_key_1 in response to the Query Registry Key request 740 and a targeted location for the instruction pointer upon resumption in VM processing. Thereafter, the virtualized data is inserted into the memory location, the instruction pointer is positioned at the end of the Query Registry key function and the first VM 720₁ resumes. As a result, the first VM 720₁ continues with the virtualized data as the returned registry value.

As another illustrative example, upon detecting the request 740 (e.g., “Open” system call to open a particular file transitioning from a calling routine within the user mode to driver logic within the kernel mode), the hypervisor 700 temporarily halts operations of the first VM 720₁ and invokes the intercept logic 750. Initially, the intercept logic 750 accesses the configuration data 751 to determine whether the request 740 is associated with a prescribed interception point 753 (e.g., a particular system call, request between software drivers, etc.). If so, the intercept logic 750 further accesses some or all of the usage patterns 754₁-754_X to determine whether any of the usage patterns 754₁-754_X is associated with the prescribed interception point 753 and criteria set forth in the particular usage pattern, which may include object type, platform type, the type of request (“Open”), the particular resource associated with the request 740 (C:\Program Files\Test Files\xyz.pdf), and/or other criterion identified in FIG. 4B.

In the event that the request 740 is directed to a virtualized resource based on identifying an applicable usage pattern (e.g., usage pattern 754₁) that is associated with the interception point 753, the intercept logic 750 may determine what virtualization scheme is to be conducted to the resource (e.g., Intercept & Redirect). In the event that virtualization flag is set to identify that virtualization is to be conducted to input data, the intercept logic 750 invokes the redirect logic 770 and provides the request 740 and the virtualized data 760, namely the alternative file path (C:\Program Files\Test Files\xyz.pdf) acquired from the usage pattern 754₁, to the redirect logic 770. The redirect logic 770 modifies the Open File request 740 with the alternative file path, and returns the modified Open File request 747 to the kernel mode 460 and the first VM 720₁ resumes. As an optional feature, an interception point (e.g., system call, etc.) may be inserted at the end of the Open File request 740, which causes the hypervisor 700 to stop the first VM 720₁ upon completion of the Open File function and invoke the intercept logic 750. At this point, based on the configuration data 751, the redirect logic 770 may alter stored data associated with the request 740.

Alternatively, upon determining the virtualization scheme to be undertaken (e.g., intercept and redirect) and the virtualization flag is set to identify that virtualization is to be conducted to returned data, the intercept logic 750 invokes the redirect logic 770, which inserts an interception point (e.g., API call, syscall, etc.) at the end of the Open File call 740 and causes the first VM 720₁ to resume. Upon completion of the Open File call 740, a request is initiated that prompts the hypervisor 700 to temporarily halt execution of the first VM 720₁ and invoke the intercept logic 750. At this point, based on the configuration data, the redirect logic 770 analyzes state information associated with the first VM 720₁ to determine a virtual memory location in which the file path for the targeted file is stored. Thereafter, the redirect logic 770 substitutes the stored file path with the alternate file path and causes the first VM 720₁ to resume.

V. Light Hypervisor-Based Selective Virtualization

Referring now to FIG. 8, according to a third embodiment of the disclosure, instead of VM-based virtualization (FIG. 6) and VMM-based virtualization (FIG. 7), the virtualization logic may be deployed within a light-weight, type 1 hypervisor (referred to herein as an “light hypervisor 800”). In lieu of managing operability of one or more VMs as performed by the hypervisor, the light hypervisor 800 is adapted to trap, at certain points of interest, host-based operations in the kernel mode and user mode.

While it is contemplated that the invention may be deployed in any device type (e.g., server, network appliance, network appliance), an illustrative embodiment of platform 805 in a smartphone form factor and deploying light hypervisor-based virtualization functionality is shown. Herein, the light hypervisor 800 is stored within a memory 810 encased within a housing 820 of the smartphone 805 having a display 830. Operating during normal run-time at which time an application 840 and/or an operating system (OS) 845 are being executed by processor 825, the light hypervisor 800 is configured to trap requests to the OS 845 (in kernel mode), even requests originating from application 840. Thereafter, if the requests are directed to selected resources that are virtualized, the intercept logic 850, the servicing logic 860 and the redirect logic 870 collectively operate to perform visualization of selected resources in a manner similar to the operations conducted by the hypervisor 700 of FIG. 7. The monitoring logic 880 is configured to monitor behaviors, most notably anomalous behaviors of the application 840 and the OS 845 during execution.

Referring to FIG. 9, a logical representation of the platform 805 with a light hypervisor 800 that controls selective virtualization of resources within user mode 910 and kernel mode 920 is shown. Herein, the light hypervisor 800 is communicatively coupled to hardware 900 of the platform 805 as well as software components within the user mode 910 (e.g., applications) and software components that are part of the kernel mode 920 (e.g. an operating system “OS”) of the platform 805.

Herein, as an illustrative example, the light hypervisor 800 may be disposed or layered beneath the operating system kernel 920 of the platform 805 (and/or directly on native hardware 900) to thereby virtualize the hardware and control privileges (e.g., access control permissions) to hardware 900 of the platform 805 that are typically controlled by the operating system kernel. Illustratively, the hardware 900 may include (physical) processor(s), memory, network interface(s), and/or other devices. The light hypervisor 800 may be configured to control access to one or more resources of the hardware 900 in response to a request to OS functionality in the kernel mode 920.

The light hypervisor 800 may provide a virtualization layer having less functionality than a typical hypervisor. Accordingly, the light hypervisor 800 may cooperate with a hypervisor (VMM) (not shown) to provide additional virtualization functionality in an operationally and resource efficient manner.

The light hypervisor 800 comprises virtualization logic 930 that is configured to virtualize resources by intercepting requests and either (i) redirecting the intercepted requests associated with a first subset of activities or (ii) servicing the intercepted requests associated with a second subset of activities, as described below. These requests may include an API call, a system call for a particular service such as hardware-related services (e.g., access to a storage device such as a hard disk drive), file management (e.g., open, close, etc.) and network connectivity management (e.g., create network connection, terminate network connection, etc.).

More specifically, according to one embodiment of the disclosure, an application running in user mode 910 may initiate a request 940 (e.g., a system call to a software driver within the kernel mode 920), where this type of request may be monitored by the light hypervisor 800. In response to detecting the request 940, the light hypervisor temporarily halts software component functionality in the user mode 910 and kernel mode 920.

Consistent with the above-described operations of the virtualization logic 710 within the hypervisor 700, the virtualization logic 930 of the light hypervisor 800 is invoked to determine whether the request 940 is directed to a virtualized resource, and if so, determines what virtualization scheme is to be conducted to the resource (e.g., Intercept & Service; Intercept & Redirect). Additionally, for selective virtualization involving intercepting and redirecting requests, intercept logic 950 may further determine when the virtualization scheme is to be conducted (e.g., to input information or output information).

For a first type of virtualization scheme (Intercept & Service), the intercept logic 950 invokes servicing logic 960, which analyzes state information of the platform 805 to determine a memory location for placement of data returned in response to the request 940. Thereafter, the virtualized data, which is obtained from an applicable usage pattern 954₁ within the configuration data 952, may be inserted into the memory location, the instruction pointer is positioned at the end of the function associated with the request 940, and the application within the user mode resumes.

For a second type of virtualization scheme (Intercept & Request), the intercept logic 950 invokes redirect logic 970 and provides the virtualized data (e.g., an alternative path, alternative handle, etc.) to the redirect logic 970. Thereafter, the redirect logic 970 modifies content of the request 940, returns the modified request 945 to the user mode. The same operations apply to requests 942, which are detected in transition from user mode to kernel mode or detected during inter-communication between software drivers and modified by the redirect logic 970 and returned as modified requests 947 to the kernel mode 920.

In the foregoing description, the invention is described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims.

Claims

1. A platform comprising: one or more hardware processors; anda memory coupled to the one or more processors, the memory comprises one or more virtual machines that are configured to process of an object under analysis and a virtual machine monitor that manages operability of the one or more virtual machines and is configured to detect and control handling of requests initiated by the one or more virtual machines,wherein the virtual machine monitor comprises a first logic configured to (i) temporarily halt execution of a first virtual machine of the one or more virtual machines in response to detecting a request from the first virtual machine and (ii) maintain an instruction pointer at a first virtual memory address associated with the request,a second logic configured to (i) determine whether the request is associated with a virtualized resource and (ii) select a virtualization scheme for producing virtualized data, wherein the virtualization scheme being selected from (a) intercepting and redirecting the request to a different portion of system code than originally targeted when the request is directed to a first subset of activities and (b) intercepting and servicing the request when the request is directed to a second subset of activities, anda third logic in communication with the second logic, the third logic to determine a memory location within the memory for placement of the virtualized data and to subsequently modify the instruction pointer to a second virtual memory address so that, when the first virtual machine resumes execution, the request has been serviced.

2. The platform of claim 1, wherein the virtual machine monitor corresponds to a type 1 hypervisor that runs directly on a hardware of the platform including the one or more hardware processors.

3. The platform of claim 1, wherein the virtual machine monitor corresponds to a type 2 hypervisor that runs directly on a host operating system of the platform.

4. The platform of claim 1, wherein the first logic includes virtual machine monitor (VMM) management logic.

5. The platform of claim 4, wherein the VMM management logic invokes and passes operation control to the second logic operating as intercept logic.

6. The platform of claim 1, wherein the second logic operating as an intercept logic accesses data to determine whether the request is associated with a prescribed interception point.

7. The platform of claim 6, wherein the prescribed interception point is a hook or a break point.

8. The platform of claim 6, wherein the prescribed interception point is an Application Programming Interface (API) call.

9. The platform of claim 6, wherein responsive to the request being associated with the prescribed interception point, the intercept logic is configured to access one or more usage patterns to determine criteria for conducting virtualization of a requested resource.

10. The platform of claim 1, wherein the second logic servicing the request by at least returning virtualized data to a process or a thread operating within the virtual machine that initiated the request.

11. The platform of claim 1, wherein the second logic redirecting the request by at least generating a modified request operating as the request by changing a resource associated with the request and subsequently passing the request to system code for processing.

12. A computerized method comprising: processing of an object under analysis by one or more virtual machines;managing operability of the one or more virtual machines by a virtual machine monitor to detect and control handling of requests initiated by the one or more virtual machines;temporarily halting execution of a first virtual machine of the one or more virtual machines in response to detecting a request from the first virtual machine;maintaining an instruction pointer at a first virtual memory address associated with the request;determining whether the request is associated with a virtualized resource;selecting a virtualization scheme for producing virtualized data when the request is associated with a virtualization resource, wherein the virtualization scheme being selected from (a) intercepting and redirecting the request to a different portion of system code than originally targeted when the request is directed to a first subset of activities and (b) intercepting and servicing the request when the request is directed to a second subset of activities; anddetermining a memory location within a virtual memory for placement of the virtualized data and to subsequently modify the instruction pointer to a second virtual memory address so that, when the first virtual machine resumes execution, the request has been serviced.

13. The computerized method of claim 12, wherein the temporarily halting of the execution of the first virtual machine, the maintaining of the instruction pointer, the determining whether the request is associated with the virtualized resource, the selecting of the virtualization scheme, and the determining of the memory location is conducted by a virtual machine monitor corresponds to a type 1 hypervisor that runs directly on hardware.

14. The computerized method of claim 12, wherein the temporarily halting of the execution of the first virtual machine, the maintaining of the instruction pointer, the determining whether the request is associated with the virtualized resource, the selecting of the virtualization scheme, and the determining of the memory location is conducted by a virtual machine monitor corresponds to a type 2 hypervisor that runs directly on a host operating system.

15. The computerized method of claim 12, wherein the temporarily halting of the execution of the first virtual machine and the maintaining of the instruction pointer is conducted by management logic of a virtual machine monitor (VMM).

16. The computerized method of claim 15, wherein the VMM management logic invokes and passes operation control to intercept logic of the VMM, the intercept logic being configured to determine whether the request is associated with the virtualized resource and select of the virtualization scheme.

17. The computerized method of claim 16, wherein the intercept logic accesses data to determine whether the request is associated with a prescribed interception point.

18. The computerized method of claim 17, wherein the prescribed interception point is a hook or a break point.

19. The computerized method of claim 16, wherein the prescribed interception point is an Application Programming Interface (API) call.

20. The computerized method of claim 12, wherein the servicing of the request includes at least returning virtualized data to a process or a thread operating within the virtual machine that initiated the request.

21. The computerized method of claim 12, wherein the redirecting of the request includes at least generating a modified request operating as the request by changing a resource associated with the request and subsequently passing the request to system code for processing.