Software Technology for “Hypervisor hosted virtual machine forensics.”

Microsoft – Jerry Cochran, Microsoft Technology Licensing LLC

Abstract for “Hypervisor hosted virtual machine forensics.”

“A computer system obtains forensics data by running virtual machines within a hypervisor-hosted virtualization setting. A forensics partition is added to the root or child virtual machine partitions of the computer system. The forensics partition contains a forensics application programming interface that can target one or more virtual computers and obtain forensics data from the targeted virtual machine running within a specific child virtual machine partition. The forensics program interface can communicate with one or more inter-partition communication channels, such as an interpartition communication bus, hypercall interface or forensics switch, which are all implemented in the hypervisor-hosted virtualization environments. As part of a cloud-based service, the forensics application programming interface may be exposed to a tool.

Background for “Hypervisor hosted virtual machine forensics.”

“As traditional enterprises adopt datacenter solutions that are primarily virtual machine-based incident responders, both information technology environments and cloud service providers will have great difficulties in conducting forensics analysis and acquisition at scale.”

“Traditional forensic tools operate at the host level, sometimes in user mode to obtain artifacts out of the filesystem and/or memory via user-mode technologies and application programming interfaces. In some cases, kernel drivers or shims are used. These traditional solutions don’t scale well in large datacenter environments, and can be compromised or thwarted using more sophisticated malware employing anti-forensics capabilities.

For forensic analysis and security investigation in small enterprises, it is possible to analyze each host individually using tools for forensic acquisition. Forensic analysis of cloud services can involve collecting data from hundreds of hosts. It is not possible to go to each host individually for forensic analysis or acquisition in these environments.

“Conventional tools can load an agent on each host and use a central controller to reach out and retrieve forensics data or artifacts. But, loading an agent onto every host is not scalable.

“Furthermore forensic analysis and acquisition of stored data doesn’t provide live memory or current status of a virtual machine.”

The following summary presents a few concepts in simplified form. They are then described in detail in the detailed description. This summary does not identify the key features or essential features in the claimed subject matter. It also is not meant to limit the scope and application of the claimed matter.

“A computer system obtains forensics data by running virtual machines within a hypervisor-hosted virtualization setting. A forensics partition is added to the root or child virtual machine partitions of the computer system. The forensics partition contains a forensics application programming interface that can target one or more virtual computers and obtain forensics data from the targeted virtual machine running within a specific child virtual machine partition. The forensics program interface can communicate with one or more inter-partition communication channels, such as an interpartition communication bus, hypercall interface or forensics switch, which are all implemented in the hypervisor-hosted virtualization environments. As part of a cloud-based service, the forensics application programming interface may be exposed to a tool.

These and other advantages can be seen by reviewing the detailed description and the attached drawings. The following summary, detailed description, and appended drawings should be understood. They are only intended to provide information and not limit the claims of any aspect.

“The following detailed description is provided in connection with the attached drawings. It is intended to be a description for examples only and does not represent all possible forms in which the examples can be constructed or used. This description outlines the functions and the steps required to construct and operate the examples. Different examples may achieve the same functions or similar sequences.

“References To?one Embodiment” ?an embodiment,? ?an example embodiment,? ?one implementation,? ?an implementation,? ?one example,? ?an example? The like indicate that an embodiment, implementation, or example may include a particular feature or structure, but not every implementation or example. These phrases do not necessarily refer to the same implementation, embodiment or example. It is important to note that a feature, structure, or characteristic described in connection with an example, embodiment, or other example may also be used in conjunction with other implementations, examples, or embodiments.

“Numerous details are provided to give a complete understanding of one or more of the discussed subject matter. However, it is important to understand that these aspects can be done without requiring any specific details. Although certain components are illustrated in block diagrams to show one or more aspects of their functionality, it should be understood that functionality performed solely by one component can be done by multiple components. A single component can also be configured to perform functionality that is described as being performed in multiple components.

“Various aspects of this subject disclosure will now be described in greater detail using the drawings. Like numerals refer to like elements or corresponding elements throughout. Drawings and detailed descriptions are not meant to limit the claimed subject matter beyond the one described. Instead, the intent is to include all modifications, equivalents, and alternative claims that fall within the scope and spirit of the claimed subject matter.

“FIG. “FIG. Virtualization framework 100 or any portion thereof can be implemented using a variety of computing devices. These can include software, hardware or firmware, as well as a combination of both.

“Implementations for virtualization framework 100” are described in the context a computing device or a computer system that is configured to perform different steps, methods and/or functionality according to aspects of the subject matter. A computer system may be implemented by more than one computing device. The ‘computer-executable instruction’ concept describes the implementation of virtualization framework 100. That are executed in order to execute various steps, methods and/or functionality according to aspects of the subject matter.

A computing device or computer system may include one or more processors and storage (e.g. memory and disk drives), as well as input devices, output devices and communication interfaces. A combination of hardware or software can be included in a computing device and/or computer systems. You will be able to recognize that there are many types of computer-readable storage media that can be included in a computer device or computer system. The terms “computer-readable storage media” and “computer-readable storage medium” are used herein. Computer-readable storage media? These terms do not necessarily exclude a propagated signal or a modulated data signals, nor any other type transitory computer-readable media. A computing device or computer system may include a processor that executes computer-executable instruction and a computer readable storage medium (e.g. memory and/or additional storage) that stores computer-executable instruction to perform different steps, methods and/or functionality according to aspects of the subject matter.

Computer-executable instructions may be implemented in a variety of ways, including a client program and/or a server program, a program module, routines, APIs, functions, methods and the like. Computer-executable instruction can be stored on one of many computer-readable storage media. They can be executed by one, two, or more processors, computing devices, or computer systems to execute particular tasks or implement certain data types according to aspects of the subject matter.

“Virtualization framework 100” can be used to run multiple virtual server instances concurrently on one physical host computer. It is isolated execution environments that allow for isolation of the virtual server instances. Each virtual server can be run as though it were the only one on a shared physical server.

“Virtualization framework 100” can be used to simultaneously run multiple virtual network infrastructures on a single physical network. Each virtual network can be operated as though it were the only one running on the same physical network fabric.

“Virtualization framework 100 is compatible with cloud computing environments. Virtualization framework 100 is supported on server computers that support x64 architecture. One server computer can host hundreds of virtual machines and be deployed in a cluster with a few thousand virtual machines. A server computer with virtualization framework 100 implemented can be deployed in a cluster hosted at a cloud computing datacenter. This datacenter manages computing and storage resources for server computers and provides resources to applications that are running in a cloud computing environment.

“Virtualization framework 100 contains a hypervisor 110, as shown. Hypervisor 110 is able to be installed on a computing device (e.g. server computer) or computer systems and configured to manage the underlying hardware (e.g. one or more processors or memory, disks, NICs etc.). Hypervisor 110 can be installed on a computing device (e.g., server computer) or computer system to manage underlying hardware (e.g., one or more processors, memory and disks etc.). Hypervisor 110 can be run in highly privileged mode (e.g. Ring -1). Hypervisor 110 is able to control and arbitrate access the underlying hardware.

Hypervisor 110 is capable of managing a subset core hardware facilities, such as logical processors and local Advanced Programmable Interrupt Controllers. (APICs), system counters. System physical address space (e.g. RAM and device memory), I/O, model specific register (MSR), space, etc. To provide isolated execution environments. Hypervisor 110 is capable of providing, supporting, and managing isolated execution environments, also known as partitions. Each partition can be used as an abstract container, or logical unit, for managing hypervisor 110’s memory and processor resources. Each partition can be assigned a number of hardware resources (CPUs, memory and devices), as well as virtual resources. Partitions can share or own hardware resources. Partitions may have policies regarding device access.

“A root partition or parent partition can be used to create one or more child parts. A child guest operating system can be installed on each child partition. A child guest operating systems can be either a fully-featured system or a kernel for special purposes. The underlying hardware, such as processor, memory, disk, and NICs, is not accessible to a child partition. You can also handle processor interrupts. A child partition can be run in a private virtual memory address area. A child partition can have a virtual view on hardware resources. Requests to virtual devices can then be directed to the root partition.

Hypervisor 110 can create virtual machines. Hypervisor 110 can create and/or manage virtual machines. A child partition is possible. Virtual machines can be used to emulate physical computers or computer systems. One or more virtual processors can be included in a virtual machine. A virtual machine can be used to provide a platform for running a fully-featured operating program. A partition can use a virtualization stack to access emulated devices. A partition can be mapped to a logical system, and virtual devices within that partition can be mapped to logical systems.”

Hypervisor 110 can expose a hypercalls API 111 to partitions. Hypercalls are calls from partitions to hypervisor 110. Each hypercall can be configured to define a number of input and/or output parameters. Hypercalls can be configured to perform one or multiple actions.

Hypercalls can be sent by either a parent or child partition to hypervisor 110. Hypercalls can be sent by a partition to hypervisor 110 to request action or query for information (e.g. output parameters, statistics and registers). Hypercall 110 can be sent by a root or parent partition to create a child partition. Hypercalls API 111 allows you to implement a calling path between a partition and hypervisor 110, as well as a return path between hypervisor 110 and the calling partition.

“Hypervisor 110 provides and supports various messaging capabilities. Hypervisor 110 can send messages to a partition. Messages can also be sent between partitions. Every message can include a message type and source partition. Hypervisor 110 supports inter-partition communication in the form of messages and/or events. Hypervisor 110 can route messages or events from one partition to another.

Hypervisor can have an interrupt controller 112 that controls and prioritizes processor interrupts. Hypervisor 110 can use an interrupt controller 112 to redirect interrupts from a partition and handle interrupts to the processor. An APIC or another suitable interrupt controller could be used to implement the interrupt controller.

Hypervisor 110 can be configured to include a partition manager 113, which allows you to create, manage, and delete partitions. Hypervisor 110 can use the partition manager 113 to create and initialize child partitions in response to hypercalls from root or parent partitions. Each partition created can be given a partition identifier. It can then be allocated memory or virtual resources.

Hypervisor 110 can also include memory manager114 to manage memory and partition access. Memory manager 114 can also be implemented by memory service routines or another suitable memory manager.

“Hypervisor 110 may include an address manager 115, which allows for management of virtual network addresses assigned to each guest operating systems. Hypervisor 110 can use address manager 115 to perform address translation to map physical memory addresses to virtual address space used by partitions.

Hypervisor 110 can be configured to run a scheduler, 116 which schedules the running of virtual CPUs on physical processors. Scheduler 116 is able to schedule based on policies set by a parent or root partition.

“Hypervisor-Hosted Virtualization Environment”

Hypervisor 110 can be configured so that it provides a hypervisor-hosted virtualization area 120. Hypervisor-hosted virtualization environments 120 can be configured to implement one or more virtualized parts in a variety of ways.

“Hypervisor hosted virtualization environment 120” can contain a root virtual machine(VM) partition 130, root VM, hypervisor-aware children VM partition 140, enlightened parent VM and non-hypervisor child VM part 150.

“Root VM Partition 130 can contain a virtual machine bus 132. VMBus 132 is a channel that allows inter-partition communication between root VM Part 130 and other hypervisor aware or enlightened hypervisor-hosted partitions. VMBus 132 can run in kernel mode.”

“Child VM Partition 140 can contain a VMBus 142 to communicate with root VM Partition 130 and other hypervisor aware or enlightened parts of hypervisor-hosted environment. VMBus 142 can run in kernel mode. It should be noted that hypervisor-hosted virtualization environments 120 can contain many enlightened children partitions. The child VM partition 140 is an example of such enlightened child parts.

“Child VM Partition 150 can be used as a child partition that is not hypervisor-aware. Hypervisor 110 can be connected to child VM partition 150 by a device emulation part 151. The device emulation part 151 can be run in kernel mode. It should be noted that hypervisor-hosted virtualization environments 120 can contain many unenlightened children partitions. The child VM partition 150 is an example of such child partitions.

“Root VM Partition 130 can contain a virtualization service provider (VSP/IS/133). VSP/IS133 can process requests from hypervisor aware child partitions. A child VM partition 140 may include a virtualization client and/or integration service (VSC/IS 143). VSP/IS 133 provides virtualization services for VSC/IS 143. This is in addition to VMBus 132. VSP/IS 142 can support child VM Part 140. VSC/IS143 can use virtualization services provided by VSP/IS/133. VCS/IS 143 may include integration components that allow child VM partition 140 and root VM part 130 to communicate with hypervisor 110, hypervisor 130, or other hypervisor-aware parts via VMBus 142. VCS/IS/IS 143, VSP/IS/IS 133, and VCS/IS/IS 143 can be operated in client-provider mode and can communicate with Windows Management Instrumentation calls. VCS/IS/IS 143 can be run in kernel mode.

“Root VM Partition 130 can contain a virtual machine management (VMMS) component 135 that manages the state of virtual machines within child partitions 140,150. VMMS 135 may expose APIs that can be used, such as WMI-based APIs 136, to manage and control virtual machines. Root VM partition 130 may include a virtual machine worker (VMWP), component 137 which provides a separate worker process to each virtual machine. From Root VM partition 130, worker processes can provide virtual machine administration services. They can also operate in child guest operating system 144, 154, and 150. A worker process can be created for each virtual machine. It runs in root VM part 130 and implements code to save state, access emulated devices, and control the machine. In user mode, VMMS 135, WMI136 and VMWP component137 can be run.

“Root VM Partition 130” can contain various drivers, such as a virtualization driver (VID), which provides partition management services, or independent hardware vendor (IHV), drivers that manage interactions with the host system hardware.

“Child VM Partition 140 can implement different hosted applications 145 that run on guest operating system 144. Child VM partition 150 is capable of implementing various hosted applications 155 which are run using guest OS 154.

“Forensics Root VM”

“As shown at FIG. Hypervisor-hosted virtualization environment 120 contains a hypervisor hosted forensics root VMware partition 160 and forensics root Virtual Machine VM. Hypervisor 110 can create and launch a forensics root VM partition 160. Hypervisor 110 can create a Forensics root VMware Partition 160 to implement a dedicated forensics root Virtual Machine (VM) for analysis and acquisition.

“Forensics root VM part 160 can be used as a privileged VM section, which is similar to root VM part 130. Forensics root VMware partition 160 could be an additional root partition with some degree of specialness and enhanced privilege in relation to child VM parts 140, 150. For example, forensicsroot VM partition 160 could implement a virtualization stack that gives direct access to the underlying hardware (e.g. memory) of the computer system that implements virtualization frame 100. While root VM part 160 may have the same qualities as root partition 130, it will not be able to operate as root partition 130 or rootVM. Forensics root VM part 160 may be more privileged that a child VM partition, but less privileged as root VM portion 130.

“Forensics root VM Partition 160 can create a privileged VM which is allowed access to hosted VMs directly via VMBus 162 or hypercalls API 111. Forensics root VM Partition 160 can send and receive messages and/or events through hypervisor 110 to a destination part.

“Forensics root VM 160 can contain a forensics API 163, which can be invoked via a forensics program 170. One implementation allows forensics tool 170 to be used outside of hypervisor-hosted virtualization environment 120. Other implementations allow forensics tool 170 to be installed and implemented within forensics root VM 160. An application or automated script (e.g. PowerShell script), that collects data via forensics API 163, can implement forensics tool 170.

“Forensics API 163 can be exposed by forensics tool 170. It can contain functionality to request, receive, or expose forensics data from hypervisor-hosted VMs that use various inter-partition communication methods. For example, forensics API 163 may include functionality to request, receive, and/or expose forensics data via VMBus 162. Calls can be routed via VMBus 162 and 142 from forensics root VM Part 160 to targeted enlightened VMs via VMBus 162. VMBus 162 can expose and receive forensics data from VMs.

VMBus 162 allows you to expose forensics service API 163 to run enlightened VMs, such as child VM partition 140. Enlightened VMs may call forensics API 163 in some cases to provide forensics data as a response to a request, message and/or event.

“Forensics API 163 allows you to request, receive, and/or expose forensics data by running enlightened VMs. (e.g. child VM partition 140). This can be done using VSCs or integration services. Integration services can be installed to enable enlightened partitions to provide I/O and hypervisor aware kernels. As such, forensics API 173 can request and receive forensics data using VSCs or integration services from enlightened VMs. API 163 allows you to request, receive, or expose forensics data through communication with running VMs via WMI calls.

“Forensics API 163 allows you to request, receive, and/or expose forensics data by running VMs via hypercalls to hypervisor110 via HCIF 16.1. Hypervisor 110 can be called and forensics data can be obtained from hypervisor 110. API 163 for Forensics Service can be used to request, receive, or expose forensics data running VMs via messages and/or events through hypervisor 110.

“In some cases, calls and replies can be made in different ways. One mechanism can be used to make a call for forensics data, while another method can receive forensics information. One interface can send a call, while another interface collects forensics data. An interface that is used to call can be one type (e.g. network interface), while a receiving interface can expose itself as another type (e.g. network attached storage interface, PowerShell remote interface etc

“Root VM partition 130 is highly privileged. Root VM partition 130 is used to support the infrastructure for making calls. However, forensics tool 170 cannot access root VM Part 130 directly. Some implementations allow requests for forensics data, such as hypercalls (e.g. WinHv calls and/or VMBus call from forensics root VM 160), to be routed through root VM part 130.

“Forensics Tool 170” or investigators can log on to or be directed at forensics root VM Part 160. They can also present forensics service API 163 which can be called by forensics tools 170. Hypervisors can arbitrate calls from forensics tool 170. The forensic root VM 160 receives the forensics data from the target host. To obtain the registry hive of a host, call forensics root VM 160. This will get the data from that host and provide it to forensic tool 170.

“Forensics API 163 allows forensics tool 170 the ability to target one or several running hosted VMs, and to select different types of forensics data to acquire and/or analyze. The following forensic artifacts can be requested by and/or analyzed by Forensics Tool 170: host/VM filesystem and network artifacts; host/VM memory artifacts; and host/VM event logs.

Forensic analysis can be performed on one or more targeted hosts/VMs. This type of analysis requires information from the host/VM’s filesystem. This can be done via the VM interface or as actual data. Non-limiting examples of acquiring and analyzing host/VM filesystem artifacts include: acquisition of Master File Table (MFT) activity and detection of anomalous MFT activity, acquisition of file times and detection of suspicious file time anomalies, acquisition and validation of file hashes, acquisition and analysis of Autostart Extensibility Points (ASEPs) and autoruns, acquisition and analysis of file download-open-creation-deletion information, acquisition and analysis of program execution and usage information, packing/entropy analysis, and stack rank/frequency analysis of artifacts.”

“Network analysis at host/VM level may include acquiring and analysing host/VM network artifacts, including but not limited to: acquisition and analyse of Address Resolution Protocol (ARP), Domain Name System (DNS), cache data, analysis and acquisition of network connection data, capture and analysis packet data.”

“Host/VM Memory Analysis allows an investigator to obtain and analyze information about operating systems and running processes. This can include acquiring memory data to be analysed by forensics tools 170 and direct analysis through exposure of forensics interfacing 163 to forensicstool 170. Examples of acquiring and analyzing host/VM memories artifacts are: analysis and acquisition of process information, identification of suspicious processes, analysis and handling of dynamic link library processes, analysis and acquisition of code injection behavior, analysis and acquisition of kernel hooking (e.g. rootkit behavior), analysis and acquisition of process memory dumping, and mapping.”

“Host logs are an important tool for forensic analysis to identify various activities on a host/VM. You can acquire and analyze event log sources from either a host/VM, or an entire host/VM population. Examples of how to acquire and analyze host/VM log artifacts are: acquisition of scheduled tasks logs; acquisition and analyses of logon activities; acquisition and analyses of account activities; acquisition and changes to system policies; acquisition and detections of suspicious programs and services, and acquisition and analysis event timeline data.

In order to protect user privacy and information security, both users and providers of user-related user data can use a variety of methods. These mechanisms include, but are not limited to, requiring authorization to monitor or collect data; allowing users to opt-in and out of data monitoring and collection; using privacy rules to prevent certain data being monitored, captured, or reported; providing functionality to anonymize, truncate, or obfuscate sensitive data that is allowed to be monitored or reported; using data retention policies to protect and purge data; and/or any other suitable mechanisms to protect user privacy.

“Hypervisor-Hosted forensics Switch?

“As shown at FIG. 2. Hypervisor-hosted virtualization environments 120 include a hypervisor hosted forensics children VM partition 180 and forensics kid VM. Hypervisor 110 can create and launch forensics child VM partition 180. Forensics child partition 180 can be used to implement a forensics child virtual machine as a dedicated VM that is capable of performing forensics acquisitions and analysis. It has minimal impact on hypervisor 110 or root partition 130.

“Forensics Child VM Partition 180 can create a VM that has access to hosted VMs directly via VMBus 182 or hypercalls API 111. Forensics child VM 180 can send and receive messages and/or events through hypervisor 110 to a destination part. The forensics child VM has access to WMI and window APIs.

“Forensics child VM Partition 180 can contain a forensics API 183 that can then be invoked using a forensics tools 185. Forensics child VM partition 180 can run forensic tool 185 in one implementation. An investigator could spin up forensics children VM partition 180 and then install forensics tools 185. Forensics tool 185 may be used in conjunction with forensics child VM 180. An application or automated script (e.g. PowerShell script), that collects data via forensics API 183 can implement forensics tool 185.

“The root VM partition 130 has high privileges. One implementation allows access to forensics switch 130 in root VM partition 130 to be restricted to forensics tools 185 in forensics children VM partition 180. Root VM partition 130 can route requests for forensics data, such as hypercalls (e.g. WinHv calls and/or VMBus call from forensics children VM partition 180), to forensics tool 185. However, in some cases, forensics switch138 can be exposed via root VM partition 130 to a forensics software (e.g., WinHv calls) that is not hosted on hypervisor-hosted virtualization environments 120.

“Forensics API 183 can be exposed by forensics tool 185. It can contain functionality to request, receive, or expose forensics data from hypervisor-hosted VMs that use various inter-partition communication methods. For example, forensics API 183 may include functionality to request, receive, and/or expose forensics data via VMBus 18. The VMBus 182, 142 allows calls to be routed from forensics children VM partition 180 to targeted enlightened VMs. VMBus 182 can expose and receive forensics data from VMs.

“Forensics API 183 can also be used to run enlightened virtual machines (e.g. child VM partition 140) using VMBus 18.2. Enlightened VMs may call forensics API 183 in some cases to provide forensics data as a response to a request, message and/or event.

“Forensics API 183” can be used to request, receive, and/or expose forensics data by running enlightened VMs. (e.g. child VM partition 140). This can be done using VSCs or integration services. Integration services can be installed to enable enlightened partitions to provide I/O and hypervisor aware kernels. These integration services may include one or more VSCs using the VMBus. As such, forensics API 183 can request and receive forensics data from enlightened VMs via VSCs or integration services. API 183 allows you to request, receive, or expose forensics data through communication with running VMs via WMI calls.

“Forensics API 183” can be used to request, receive, and/or expose forensics data by running VMs via hypercalls to hypervisor110 via HCIF 18.1. Hypervisor 110 can be called and forensics data can be obtained from hypervisor 110. API 183 for Forensics Service can be used to request, receive, or expose forensics data running VMs via messages and/or events through hypervisor 110.

“As you can see, a forensics toggle 138 is installed within root VM partition 130. Forensics switch 138 can be accessed by forensics child VM division 180. It is able access VMs in child VM parts 140, 150. Forensics tool185, or another service can interface to forensics switch138 and request acquisition or return of certain types forensic artifacts. These VMs are used for analysis or storage. Forensics Switch 138 is a robust implementation that allows access to unenlightened parent partitions, which do not support VMBus functionality.

“Forensics Switch 138 can be added to root VM Partition 130 as a separate construct or shim in the root VM Partition 130. Forensics service API 183 exposes the Forensics Switch 138. Mechanism to forensics child VM180 can be exposed by Forensics Switch 138 via an agent API or other mechanism (disks, network mechanisms, etc.). That forensics tool can use. Forensics API 183 can be interfaced with forensics switch 138. For example, forensics switch 138 can route calls to forensics API 183 to target VMs. It will also provide forensics data back at forensic child VM 180 for analysis.

“In different implementations, a forensics interface or switch can be dynamically added to each child VM/partition. This allows access to the required system, memory and network resources of the child VM to perform forensic analysis and acquisition. This mechanism supports hypervisor hot-plug? capability.”

“As seen, child VM partitions 140 and 150 are instrumented using forensics interfaces 148 and 158, respectively. Forensic switch 138 is loaded. It includes acquisition targets that map directly to running VMs. An investigator can access acquisition targets via the forensics service API 183. The forensics tool 185 can be used to target a host and obtain forensics data using forensics service API 183 and forensics interfaces, 148 and 158. You can call forensics switch138 via forensics interfaces148 and 158 to get a response. Forensics switch138 can respond to a request by collecting forensics information from a host/VM and sending it back to forensics tool185.

“Forensics switch 138 may work with VMBus 18.2 in some cases. VMBus 182 or 132 can be used to request forensics data. Forensics switch 138 can route a call to an enlightened VM that is running in child VM division 140. This can be done over VMBus 132 or 142. An enlightened VM running under child VM partition can be used to route forensics data to forensics switches 148, 138, 132.

“In some cases, calls and replies can be made in different ways. One mechanism can be used to make a call for forensics data, while another method can receive forensics information. One interface can send a call, while another interface collects forensics data. An interface that is used to call can be one type (e.g. network interface), while a receiving interface can expose itself as another type (e.g. network attached storage interface, PowerShell remote interface, etc.). An enlightened VM running under child VM partition 148 may be able to receive a call from forensics switching 138. It can then respond by exposing or providing forensics data using VMBus 142, 182, or using a hypercall (e.g. message, event, etc.). Hypervisor 110, without routing the forensics information back through forensics switch 38.”

“Forensics Tool 185” or an investigator can log in or be directed at forensics childVM partition 180. They can also present forensics API 183 which can be used to call forensics tool 180. Hypervisors can arbitrate calls from forensicstool 185. The forensics data are obtained from the target host and presented to the forensic child VM 180.

“Hypervisor-Hosted Artifact Acquisition and Forensic Analysis”

“There are many implementations available for hypervisor-hosted analysis. One implementation offers a dedicated forensics root VM / partition 160. A hypervisor-hosted forensics switch 138 is another option that provides root VM access to child partitions. This allows the user to acquire and analyze host artifacts from one host/VM up to thousands. You should be aware that certain features, structures and characteristics described in relation to one implementation may be used in conjunction with other implementations.

“Hypervisor-based analysis and acquisition of forensic artifacts can leverage and/or expand capabilities for the current hypervisor architecture. It also makes use of APIs and methods for communication between hypervisor and VM/child parts. VMBus and similar technologies enable interfacing with running VM host hosts to acquire or analyze data while they are running. Thousands can be examined for a specific characteristic. On the basis of observed characteristics, frequency analysis can be performed. These mechanisms can be used for host and network forensic analysis and acquisition activities against a partition/VM/partition, or a population of VMs/partitions.

“Incident responders as well security analysts require a scalable acquisition/analysis solution that can tap into host/VM information and artifacts on the hypervisor level from virtual machine. This allows for greater scale acquisition and analysis, while also mitigating sophisticated malware anti forensics and hiding techniques.

“Forensics root VM Partition 160 and/or forensics Switch 138 can be used for data acquisition and forensics analysis at hypervisor level. This can eliminate the need to load agents and load tools on each host. The benefits of Forensics Switch 138 include dynamic additions to VMs with forensics capabilities and support for unenlightened child partitions.

As a service, you can order forensic analysis of VMs. To obtain forensics data, a service that runs at the hypervisor can connect to hundreds of hosts. An analysis of scale can show that hundreds of VMs could be investigated for suspicious connections. To request their network connections list, hundreds of VMs could be called. To identify unusual connections, a frequency analysis can be done across hosts. A call can also be made for registry contents, and frequency cluster analysis can be done on files to identify potential candidates for investigation.

Cloud service providers can use this functionality to perform large-scale forensics acquisitions that can speed up their security incident investigations. These features also allow customers to choose forensics-as-a-service (FaaS). A cloud service can offer forensics data analysis and acquisition. As an add-on or separate service, a cloud service provider may offer forensics services.

Customers can use a forensics service to perform forensic analysis and acquisition on any hosted VMs they have in the cloud. Cloud computing environment providers can offer forensics services so customers can perform their own forensic analysis of their own VMs. Cloud service providers can provide scalable forensics acquisitions and analysis as a service through the creation of tenant/customer interfaces. Customers can have permission to access a centralized hypervisor supported forensics switch. FaaS customers can also have a customized forensics switch that is only accessible to the VMs belonging to them.

Summary for “Hypervisor hosted virtual machine forensics.”

“As traditional enterprises adopt datacenter solutions that are primarily virtual machine-based incident responders, both information technology environments and cloud service providers will have great difficulties in conducting forensics analysis and acquisition at scale.”

“Traditional forensic tools operate at the host level, sometimes in user mode to obtain artifacts out of the filesystem and/or memory via user-mode technologies and application programming interfaces. In some cases, kernel drivers or shims are used. These traditional solutions don’t scale well in large datacenter environments, and can be compromised or thwarted using more sophisticated malware employing anti-forensics capabilities.

For forensic analysis and security investigation in small enterprises, it is possible to analyze each host individually using tools for forensic acquisition. Forensic analysis of cloud services can involve collecting data from hundreds of hosts. It is not possible to go to each host individually for forensic analysis or acquisition in these environments.

“Conventional tools can load an agent on each host and use a central controller to reach out and retrieve forensics data or artifacts. But, loading an agent onto every host is not scalable.

“Furthermore forensic analysis and acquisition of stored data doesn’t provide live memory or current status of a virtual machine.”

The following summary presents a few concepts in simplified form. They are then described in detail in the detailed description. This summary does not identify the key features or essential features in the claimed subject matter. It also is not meant to limit the scope and application of the claimed matter.

“A computer system obtains forensics data by running virtual machines within a hypervisor-hosted virtualization setting. A forensics partition is added to the root or child virtual machine partitions of the computer system. The forensics partition contains a forensics application programming interface that can target one or more virtual computers and obtain forensics data from the targeted virtual machine running within a specific child virtual machine partition. The forensics program interface can communicate with one or more inter-partition communication channels, such as an interpartition communication bus, hypercall interface or forensics switch, which are all implemented in the hypervisor-hosted virtualization environments. As part of a cloud-based service, the forensics application programming interface may be exposed to a tool.

These and other advantages can be seen by reviewing the detailed description and the attached drawings. The following summary, detailed description, and appended drawings should be understood. They are only intended to provide information and not limit the claims of any aspect.

“The following detailed description is provided in connection with the attached drawings. It is intended to be a description for examples only and does not represent all possible forms in which the examples can be constructed or used. This description outlines the functions and the steps required to construct and operate the examples. Different examples may achieve the same functions or similar sequences.

“References To?one Embodiment” ?an embodiment,? ?an example embodiment,? ?one implementation,? ?an implementation,? ?one example,? ?an example? The like indicate that an embodiment, implementation, or example may include a particular feature or structure, but not every implementation or example. These phrases do not necessarily refer to the same implementation, embodiment or example. It is important to note that a feature, structure, or characteristic described in connection with an example, embodiment, or other example may also be used in conjunction with other implementations, examples, or embodiments.

“Numerous details are provided to give a complete understanding of one or more of the discussed subject matter. However, it is important to understand that these aspects can be done without requiring any specific details. Although certain components are illustrated in block diagrams to show one or more aspects of their functionality, it should be understood that functionality performed solely by one component can be done by multiple components. A single component can also be configured to perform functionality that is described as being performed in multiple components.

“Various aspects of this subject disclosure will now be described in greater detail using the drawings. Like numerals refer to like elements or corresponding elements throughout. Drawings and detailed descriptions are not meant to limit the claimed subject matter beyond the one described. Instead, the intent is to include all modifications, equivalents, and alternative claims that fall within the scope and spirit of the claimed subject matter.

“FIG. “FIG. Virtualization framework 100 or any portion thereof can be implemented using a variety of computing devices. These can include software, hardware or firmware, as well as a combination of both.

“Implementations for virtualization framework 100” are described in the context a computing device or a computer system that is configured to perform different steps, methods and/or functionality according to aspects of the subject matter. A computer system may be implemented by more than one computing device. The ‘computer-executable instruction’ concept describes the implementation of virtualization framework 100. That are executed in order to execute various steps, methods and/or functionality according to aspects of the subject matter.

A computing device or computer system may include one or more processors and storage (e.g. memory and disk drives), as well as input devices, output devices and communication interfaces. A combination of hardware or software can be included in a computing device and/or computer systems. You will be able to recognize that there are many types of computer-readable storage media that can be included in a computer device or computer system. The terms “computer-readable storage media” and “computer-readable storage medium” are used herein. Computer-readable storage media? These terms do not necessarily exclude a propagated signal or a modulated data signals, nor any other type transitory computer-readable media. A computing device or computer system may include a processor that executes computer-executable instruction and a computer readable storage medium (e.g. memory and/or additional storage) that stores computer-executable instruction to perform different steps, methods and/or functionality according to aspects of the subject matter.

Computer-executable instructions may be implemented in a variety of ways, including a client program and/or a server program, a program module, routines, APIs, functions, methods and the like. Computer-executable instruction can be stored on one of many computer-readable storage media. They can be executed by one, two, or more processors, computing devices, or computer systems to execute particular tasks or implement certain data types according to aspects of the subject matter.

“Virtualization framework 100” can be used to run multiple virtual server instances concurrently on one physical host computer. It is isolated execution environments that allow for isolation of the virtual server instances. Each virtual server can be run as though it were the only one on a shared physical server.

“Virtualization framework 100” can be used to simultaneously run multiple virtual network infrastructures on a single physical network. Each virtual network can be operated as though it were the only one running on the same physical network fabric.

“Virtualization framework 100 is compatible with cloud computing environments. Virtualization framework 100 is supported on server computers that support x64 architecture. One server computer can host hundreds of virtual machines and be deployed in a cluster with a few thousand virtual machines. A server computer with virtualization framework 100 implemented can be deployed in a cluster hosted at a cloud computing datacenter. This datacenter manages computing and storage resources for server computers and provides resources to applications that are running in a cloud computing environment.

“Virtualization framework 100 contains a hypervisor 110, as shown. Hypervisor 110 is able to be installed on a computing device (e.g. server computer) or computer systems and configured to manage the underlying hardware (e.g. one or more processors or memory, disks, NICs etc.). Hypervisor 110 can be installed on a computing device (e.g., server computer) or computer system to manage underlying hardware (e.g., one or more processors, memory and disks etc.). Hypervisor 110 can be run in highly privileged mode (e.g. Ring -1). Hypervisor 110 is able to control and arbitrate access the underlying hardware.

Hypervisor 110 is capable of managing a subset core hardware facilities, such as logical processors and local Advanced Programmable Interrupt Controllers. (APICs), system counters. System physical address space (e.g. RAM and device memory), I/O, model specific register (MSR), space, etc. To provide isolated execution environments. Hypervisor 110 is capable of providing, supporting, and managing isolated execution environments, also known as partitions. Each partition can be used as an abstract container, or logical unit, for managing hypervisor 110’s memory and processor resources. Each partition can be assigned a number of hardware resources (CPUs, memory and devices), as well as virtual resources. Partitions can share or own hardware resources. Partitions may have policies regarding device access.

“A root partition or parent partition can be used to create one or more child parts. A child guest operating system can be installed on each child partition. A child guest operating systems can be either a fully-featured system or a kernel for special purposes. The underlying hardware, such as processor, memory, disk, and NICs, is not accessible to a child partition. You can also handle processor interrupts. A child partition can be run in a private virtual memory address area. A child partition can have a virtual view on hardware resources. Requests to virtual devices can then be directed to the root partition.

Hypervisor 110 can create virtual machines. Hypervisor 110 can create and/or manage virtual machines. A child partition is possible. Virtual machines can be used to emulate physical computers or computer systems. One or more virtual processors can be included in a virtual machine. A virtual machine can be used to provide a platform for running a fully-featured operating program. A partition can use a virtualization stack to access emulated devices. A partition can be mapped to a logical system, and virtual devices within that partition can be mapped to logical systems.”

Hypervisor 110 can expose a hypercalls API 111 to partitions. Hypercalls are calls from partitions to hypervisor 110. Each hypercall can be configured to define a number of input and/or output parameters. Hypercalls can be configured to perform one or multiple actions.

Hypercalls can be sent by either a parent or child partition to hypervisor 110. Hypercalls can be sent by a partition to hypervisor 110 to request action or query for information (e.g. output parameters, statistics and registers). Hypercall 110 can be sent by a root or parent partition to create a child partition. Hypercalls API 111 allows you to implement a calling path between a partition and hypervisor 110, as well as a return path between hypervisor 110 and the calling partition.

“Hypervisor 110 provides and supports various messaging capabilities. Hypervisor 110 can send messages to a partition. Messages can also be sent between partitions. Every message can include a message type and source partition. Hypervisor 110 supports inter-partition communication in the form of messages and/or events. Hypervisor 110 can route messages or events from one partition to another.

Hypervisor can have an interrupt controller 112 that controls and prioritizes processor interrupts. Hypervisor 110 can use an interrupt controller 112 to redirect interrupts from a partition and handle interrupts to the processor. An APIC or another suitable interrupt controller could be used to implement the interrupt controller.

Hypervisor 110 can be configured to include a partition manager 113, which allows you to create, manage, and delete partitions. Hypervisor 110 can use the partition manager 113 to create and initialize child partitions in response to hypercalls from root or parent partitions. Each partition created can be given a partition identifier. It can then be allocated memory or virtual resources.

Hypervisor 110 can also include memory manager114 to manage memory and partition access. Memory manager 114 can also be implemented by memory service routines or another suitable memory manager.

“Hypervisor 110 may include an address manager 115, which allows for management of virtual network addresses assigned to each guest operating systems. Hypervisor 110 can use address manager 115 to perform address translation to map physical memory addresses to virtual address space used by partitions.

Hypervisor 110 can be configured to run a scheduler, 116 which schedules the running of virtual CPUs on physical processors. Scheduler 116 is able to schedule based on policies set by a parent or root partition.

“Hypervisor-Hosted Virtualization Environment”

Hypervisor 110 can be configured so that it provides a hypervisor-hosted virtualization area 120. Hypervisor-hosted virtualization environments 120 can be configured to implement one or more virtualized parts in a variety of ways.

“Hypervisor hosted virtualization environment 120” can contain a root virtual machine(VM) partition 130, root VM, hypervisor-aware children VM partition 140, enlightened parent VM and non-hypervisor child VM part 150.

“Root VM Partition 130 can contain a virtual machine bus 132. VMBus 132 is a channel that allows inter-partition communication between root VM Part 130 and other hypervisor aware or enlightened hypervisor-hosted partitions. VMBus 132 can run in kernel mode.”

“Child VM Partition 140 can contain a VMBus 142 to communicate with root VM Partition 130 and other hypervisor aware or enlightened parts of hypervisor-hosted environment. VMBus 142 can run in kernel mode. It should be noted that hypervisor-hosted virtualization environments 120 can contain many enlightened children partitions. The child VM partition 140 is an example of such enlightened child parts.

“Child VM Partition 150 can be used as a child partition that is not hypervisor-aware. Hypervisor 110 can be connected to child VM partition 150 by a device emulation part 151. The device emulation part 151 can be run in kernel mode. It should be noted that hypervisor-hosted virtualization environments 120 can contain many unenlightened children partitions. The child VM partition 150 is an example of such child partitions.

“Root VM Partition 130 can contain a virtualization service provider (VSP/IS/133). VSP/IS133 can process requests from hypervisor aware child partitions. A child VM partition 140 may include a virtualization client and/or integration service (VSC/IS 143). VSP/IS 133 provides virtualization services for VSC/IS 143. This is in addition to VMBus 132. VSP/IS 142 can support child VM Part 140. VSC/IS143 can use virtualization services provided by VSP/IS/133. VCS/IS 143 may include integration components that allow child VM partition 140 and root VM part 130 to communicate with hypervisor 110, hypervisor 130, or other hypervisor-aware parts via VMBus 142. VCS/IS/IS 143, VSP/IS/IS 133, and VCS/IS/IS 143 can be operated in client-provider mode and can communicate with Windows Management Instrumentation calls. VCS/IS/IS 143 can be run in kernel mode.

“Root VM Partition 130 can contain a virtual machine management (VMMS) component 135 that manages the state of virtual machines within child partitions 140,150. VMMS 135 may expose APIs that can be used, such as WMI-based APIs 136, to manage and control virtual machines. Root VM partition 130 may include a virtual machine worker (VMWP), component 137 which provides a separate worker process to each virtual machine. From Root VM partition 130, worker processes can provide virtual machine administration services. They can also operate in child guest operating system 144, 154, and 150. A worker process can be created for each virtual machine. It runs in root VM part 130 and implements code to save state, access emulated devices, and control the machine. In user mode, VMMS 135, WMI136 and VMWP component137 can be run.

“Root VM Partition 130” can contain various drivers, such as a virtualization driver (VID), which provides partition management services, or independent hardware vendor (IHV), drivers that manage interactions with the host system hardware.

“Child VM Partition 140 can implement different hosted applications 145 that run on guest operating system 144. Child VM partition 150 is capable of implementing various hosted applications 155 which are run using guest OS 154.

“Forensics Root VM”

“As shown at FIG. Hypervisor-hosted virtualization environment 120 contains a hypervisor hosted forensics root VMware partition 160 and forensics root Virtual Machine VM. Hypervisor 110 can create and launch a forensics root VM partition 160. Hypervisor 110 can create a Forensics root VMware Partition 160 to implement a dedicated forensics root Virtual Machine (VM) for analysis and acquisition.

“Forensics root VM part 160 can be used as a privileged VM section, which is similar to root VM part 130. Forensics root VMware partition 160 could be an additional root partition with some degree of specialness and enhanced privilege in relation to child VM parts 140, 150. For example, forensicsroot VM partition 160 could implement a virtualization stack that gives direct access to the underlying hardware (e.g. memory) of the computer system that implements virtualization frame 100. While root VM part 160 may have the same qualities as root partition 130, it will not be able to operate as root partition 130 or rootVM. Forensics root VM part 160 may be more privileged that a child VM partition, but less privileged as root VM portion 130.

“Forensics root VM Partition 160 can create a privileged VM which is allowed access to hosted VMs directly via VMBus 162 or hypercalls API 111. Forensics root VM Partition 160 can send and receive messages and/or events through hypervisor 110 to a destination part.

“Forensics root VM 160 can contain a forensics API 163, which can be invoked via a forensics program 170. One implementation allows forensics tool 170 to be used outside of hypervisor-hosted virtualization environment 120. Other implementations allow forensics tool 170 to be installed and implemented within forensics root VM 160. An application or automated script (e.g. PowerShell script), that collects data via forensics API 163, can implement forensics tool 170.

“Forensics API 163 can be exposed by forensics tool 170. It can contain functionality to request, receive, or expose forensics data from hypervisor-hosted VMs that use various inter-partition communication methods. For example, forensics API 163 may include functionality to request, receive, and/or expose forensics data via VMBus 162. Calls can be routed via VMBus 162 and 142 from forensics root VM Part 160 to targeted enlightened VMs via VMBus 162. VMBus 162 can expose and receive forensics data from VMs.

VMBus 162 allows you to expose forensics service API 163 to run enlightened VMs, such as child VM partition 140. Enlightened VMs may call forensics API 163 in some cases to provide forensics data as a response to a request, message and/or event.

“Forensics API 163 allows you to request, receive, and/or expose forensics data by running enlightened VMs. (e.g. child VM partition 140). This can be done using VSCs or integration services. Integration services can be installed to enable enlightened partitions to provide I/O and hypervisor aware kernels. As such, forensics API 173 can request and receive forensics data using VSCs or integration services from enlightened VMs. API 163 allows you to request, receive, or expose forensics data through communication with running VMs via WMI calls.

“Forensics API 163 allows you to request, receive, and/or expose forensics data by running VMs via hypercalls to hypervisor110 via HCIF 16.1. Hypervisor 110 can be called and forensics data can be obtained from hypervisor 110. API 163 for Forensics Service can be used to request, receive, or expose forensics data running VMs via messages and/or events through hypervisor 110.

“In some cases, calls and replies can be made in different ways. One mechanism can be used to make a call for forensics data, while another method can receive forensics information. One interface can send a call, while another interface collects forensics data. An interface that is used to call can be one type (e.g. network interface), while a receiving interface can expose itself as another type (e.g. network attached storage interface, PowerShell remote interface etc

“Root VM partition 130 is highly privileged. Root VM partition 130 is used to support the infrastructure for making calls. However, forensics tool 170 cannot access root VM Part 130 directly. Some implementations allow requests for forensics data, such as hypercalls (e.g. WinHv calls and/or VMBus call from forensics root VM 160), to be routed through root VM part 130.

“Forensics Tool 170” or investigators can log on to or be directed at forensics root VM Part 160. They can also present forensics service API 163 which can be called by forensics tools 170. Hypervisors can arbitrate calls from forensics tool 170. The forensic root VM 160 receives the forensics data from the target host. To obtain the registry hive of a host, call forensics root VM 160. This will get the data from that host and provide it to forensic tool 170.

“Forensics API 163 allows forensics tool 170 the ability to target one or several running hosted VMs, and to select different types of forensics data to acquire and/or analyze. The following forensic artifacts can be requested by and/or analyzed by Forensics Tool 170: host/VM filesystem and network artifacts; host/VM memory artifacts; and host/VM event logs.

Forensic analysis can be performed on one or more targeted hosts/VMs. This type of analysis requires information from the host/VM’s filesystem. This can be done via the VM interface or as actual data. Non-limiting examples of acquiring and analyzing host/VM filesystem artifacts include: acquisition of Master File Table (MFT) activity and detection of anomalous MFT activity, acquisition of file times and detection of suspicious file time anomalies, acquisition and validation of file hashes, acquisition and analysis of Autostart Extensibility Points (ASEPs) and autoruns, acquisition and analysis of file download-open-creation-deletion information, acquisition and analysis of program execution and usage information, packing/entropy analysis, and stack rank/frequency analysis of artifacts.”

“Network analysis at host/VM level may include acquiring and analysing host/VM network artifacts, including but not limited to: acquisition and analyse of Address Resolution Protocol (ARP), Domain Name System (DNS), cache data, analysis and acquisition of network connection data, capture and analysis packet data.”

“Host/VM Memory Analysis allows an investigator to obtain and analyze information about operating systems and running processes. This can include acquiring memory data to be analysed by forensics tools 170 and direct analysis through exposure of forensics interfacing 163 to forensicstool 170. Examples of acquiring and analyzing host/VM memories artifacts are: analysis and acquisition of process information, identification of suspicious processes, analysis and handling of dynamic link library processes, analysis and acquisition of code injection behavior, analysis and acquisition of kernel hooking (e.g. rootkit behavior), analysis and acquisition of process memory dumping, and mapping.”

“Host logs are an important tool for forensic analysis to identify various activities on a host/VM. You can acquire and analyze event log sources from either a host/VM, or an entire host/VM population. Examples of how to acquire and analyze host/VM log artifacts are: acquisition of scheduled tasks logs; acquisition and analyses of logon activities; acquisition and analyses of account activities; acquisition and changes to system policies; acquisition and detections of suspicious programs and services, and acquisition and analysis event timeline data.

In order to protect user privacy and information security, both users and providers of user-related user data can use a variety of methods. These mechanisms include, but are not limited to, requiring authorization to monitor or collect data; allowing users to opt-in and out of data monitoring and collection; using privacy rules to prevent certain data being monitored, captured, or reported; providing functionality to anonymize, truncate, or obfuscate sensitive data that is allowed to be monitored or reported; using data retention policies to protect and purge data; and/or any other suitable mechanisms to protect user privacy.

“Hypervisor-Hosted forensics Switch?

“As shown at FIG. 2. Hypervisor-hosted virtualization environments 120 include a hypervisor hosted forensics children VM partition 180 and forensics kid VM. Hypervisor 110 can create and launch forensics child VM partition 180. Forensics child partition 180 can be used to implement a forensics child virtual machine as a dedicated VM that is capable of performing forensics acquisitions and analysis. It has minimal impact on hypervisor 110 or root partition 130.

“Forensics Child VM Partition 180 can create a VM that has access to hosted VMs directly via VMBus 182 or hypercalls API 111. Forensics child VM 180 can send and receive messages and/or events through hypervisor 110 to a destination part. The forensics child VM has access to WMI and window APIs.

“Forensics child VM Partition 180 can contain a forensics API 183 that can then be invoked using a forensics tools 185. Forensics child VM partition 180 can run forensic tool 185 in one implementation. An investigator could spin up forensics children VM partition 180 and then install forensics tools 185. Forensics tool 185 may be used in conjunction with forensics child VM 180. An application or automated script (e.g. PowerShell script), that collects data via forensics API 183 can implement forensics tool 185.

“The root VM partition 130 has high privileges. One implementation allows access to forensics switch 130 in root VM partition 130 to be restricted to forensics tools 185 in forensics children VM partition 180. Root VM partition 130 can route requests for forensics data, such as hypercalls (e.g. WinHv calls and/or VMBus call from forensics children VM partition 180), to forensics tool 185. However, in some cases, forensics switch138 can be exposed via root VM partition 130 to a forensics software (e.g., WinHv calls) that is not hosted on hypervisor-hosted virtualization environments 120.

“Forensics API 183 can be exposed by forensics tool 185. It can contain functionality to request, receive, or expose forensics data from hypervisor-hosted VMs that use various inter-partition communication methods. For example, forensics API 183 may include functionality to request, receive, and/or expose forensics data via VMBus 18. The VMBus 182, 142 allows calls to be routed from forensics children VM partition 180 to targeted enlightened VMs. VMBus 182 can expose and receive forensics data from VMs.

“Forensics API 183 can also be used to run enlightened virtual machines (e.g. child VM partition 140) using VMBus 18.2. Enlightened VMs may call forensics API 183 in some cases to provide forensics data as a response to a request, message and/or event.

“Forensics API 183” can be used to request, receive, and/or expose forensics data by running enlightened VMs. (e.g. child VM partition 140). This can be done using VSCs or integration services. Integration services can be installed to enable enlightened partitions to provide I/O and hypervisor aware kernels. These integration services may include one or more VSCs using the VMBus. As such, forensics API 183 can request and receive forensics data from enlightened VMs via VSCs or integration services. API 183 allows you to request, receive, or expose forensics data through communication with running VMs via WMI calls.

“Forensics API 183” can be used to request, receive, and/or expose forensics data by running VMs via hypercalls to hypervisor110 via HCIF 18.1. Hypervisor 110 can be called and forensics data can be obtained from hypervisor 110. API 183 for Forensics Service can be used to request, receive, or expose forensics data running VMs via messages and/or events through hypervisor 110.

“As you can see, a forensics toggle 138 is installed within root VM partition 130. Forensics switch 138 can be accessed by forensics child VM division 180. It is able access VMs in child VM parts 140, 150. Forensics tool185, or another service can interface to forensics switch138 and request acquisition or return of certain types forensic artifacts. These VMs are used for analysis or storage. Forensics Switch 138 is a robust implementation that allows access to unenlightened parent partitions, which do not support VMBus functionality.

“Forensics Switch 138 can be added to root VM Partition 130 as a separate construct or shim in the root VM Partition 130. Forensics service API 183 exposes the Forensics Switch 138. Mechanism to forensics child VM180 can be exposed by Forensics Switch 138 via an agent API or other mechanism (disks, network mechanisms, etc.). That forensics tool can use. Forensics API 183 can be interfaced with forensics switch 138. For example, forensics switch 138 can route calls to forensics API 183 to target VMs. It will also provide forensics data back at forensic child VM 180 for analysis.

“In different implementations, a forensics interface or switch can be dynamically added to each child VM/partition. This allows access to the required system, memory and network resources of the child VM to perform forensic analysis and acquisition. This mechanism supports hypervisor hot-plug? capability.”

“As seen, child VM partitions 140 and 150 are instrumented using forensics interfaces 148 and 158, respectively. Forensic switch 138 is loaded. It includes acquisition targets that map directly to running VMs. An investigator can access acquisition targets via the forensics service API 183. The forensics tool 185 can be used to target a host and obtain forensics data using forensics service API 183 and forensics interfaces, 148 and 158. You can call forensics switch138 via forensics interfaces148 and 158 to get a response. Forensics switch138 can respond to a request by collecting forensics information from a host/VM and sending it back to forensics tool185.

“Forensics switch 138 may work with VMBus 18.2 in some cases. VMBus 182 or 132 can be used to request forensics data. Forensics switch 138 can route a call to an enlightened VM that is running in child VM division 140. This can be done over VMBus 132 or 142. An enlightened VM running under child VM partition can be used to route forensics data to forensics switches 148, 138, 132.

“In some cases, calls and replies can be made in different ways. One mechanism can be used to make a call for forensics data, while another method can receive forensics information. One interface can send a call, while another interface collects forensics data. An interface that is used to call can be one type (e.g. network interface), while a receiving interface can expose itself as another type (e.g. network attached storage interface, PowerShell remote interface, etc.). An enlightened VM running under child VM partition 148 may be able to receive a call from forensics switching 138. It can then respond by exposing or providing forensics data using VMBus 142, 182, or using a hypercall (e.g. message, event, etc.). Hypervisor 110, without routing the forensics information back through forensics switch 38.”

“Forensics Tool 185” or an investigator can log in or be directed at forensics childVM partition 180. They can also present forensics API 183 which can be used to call forensics tool 180. Hypervisors can arbitrate calls from forensicstool 185. The forensics data are obtained from the target host and presented to the forensic child VM 180.

“Hypervisor-Hosted Artifact Acquisition and Forensic Analysis”

“There are many implementations available for hypervisor-hosted analysis. One implementation offers a dedicated forensics root VM / partition 160. A hypervisor-hosted forensics switch 138 is another option that provides root VM access to child partitions. This allows the user to acquire and analyze host artifacts from one host/VM up to thousands. You should be aware that certain features, structures and characteristics described in relation to one implementation may be used in conjunction with other implementations.

“Hypervisor-based analysis and acquisition of forensic artifacts can leverage and/or expand capabilities for the current hypervisor architecture. It also makes use of APIs and methods for communication between hypervisor and VM/child parts. VMBus and similar technologies enable interfacing with running VM host hosts to acquire or analyze data while they are running. Thousands can be examined for a specific characteristic. On the basis of observed characteristics, frequency analysis can be performed. These mechanisms can be used for host and network forensic analysis and acquisition activities against a partition/VM/partition, or a population of VMs/partitions.

“Incident responders as well security analysts require a scalable acquisition/analysis solution that can tap into host/VM information and artifacts on the hypervisor level from virtual machine. This allows for greater scale acquisition and analysis, while also mitigating sophisticated malware anti forensics and hiding techniques.

“Forensics root VM Partition 160 and/or forensics Switch 138 can be used for data acquisition and forensics analysis at hypervisor level. This can eliminate the need to load agents and load tools on each host. The benefits of Forensics Switch 138 include dynamic additions to VMs with forensics capabilities and support for unenlightened child partitions.

As a service, you can order forensic analysis of VMs. To obtain forensics data, a service that runs at the hypervisor can connect to hundreds of hosts. An analysis of scale can show that hundreds of VMs could be investigated for suspicious connections. To request their network connections list, hundreds of VMs could be called. To identify unusual connections, a frequency analysis can be done across hosts. A call can also be made for registry contents, and frequency cluster analysis can be done on files to identify potential candidates for investigation.

Cloud service providers can use this functionality to perform large-scale forensics acquisitions that can speed up their security incident investigations. These features also allow customers to choose forensics-as-a-service (FaaS). A cloud service can offer forensics data analysis and acquisition. As an add-on or separate service, a cloud service provider may offer forensics services.

Customers can use a forensics service to perform forensic analysis and acquisition on any hosted VMs they have in the cloud. Cloud computing environment providers can offer forensics services so customers can perform their own forensic analysis of their own VMs. Cloud service providers can provide scalable forensics acquisitions and analysis as a service through the creation of tenant/customer interfaces. Customers can have permission to access a centralized hypervisor supported forensics switch. FaaS customers can also have a customized forensics switch that is only accessible to the VMs belonging to them.

Click here to view the patent on Google Patents.