Starting in Windows 10 and Server 2016, Microsoft added the option to enable various forms of virtualization-based security (VBS). This feature suite currently includes Credential Guard, Device Guard, Application Guard, and more. All of these optionts leverage virtual secure mode (VSM), which includes a secure kernel and secure user mode component and is made possible through the use of a hypervisor. On the forensics side, encountering a system with virtual secure mode or some form of virtualization-based security enabled can have an impact on your investigation. This post is about one of the more significant impacts I’ve seen thus far: memory acquisition.Physical memory is commonly acquired using a software-based memory acquisition tool such as winpmem, DumpIt, Magnet RAM Capturer, FTK Imager, or one of the several other options available. These tools typically load a device driver into the kernel and subsequently read memory through mapping the DevicePhysicalMemory object, using a function such as MmMapIoSpace, or directly manipulating the page tables. Many of these tools also share a similar trait: their use on a system with virtual secure mode enabled results in a system crash.
Clearly, a BSOD while attempting to acquire physical memory from a system is not ideal. If the system is an end-user machine, you will likely be left with a frustrated user (not to mention the obvious impact on your memory dump). If the system is a more critical piece of the organization such as a server, the consequences of a system crash could extend well beyond the impact on your memory dump. One way to avoid this scenario is to first determine whether virtual secure mode is enabled.One of the easiest ways to determine if VSM is enabled on a live system is to check whether the “Secure System” process is running. This is the process associated with the secure kernel and, in my experience, serves as the “trigger point” as to whether a system will crash when running several memory acquisition tools. Simply put, if the “Secure System” process is running, make sure you are using a tool that plays nice with virtual secure mode.
Most of the memory acquisition tools I’ve tested on a system with VSM enabled result in a system crash shortly after the acquisition driver is loaded. The tested tools include multiple versions of winpmem, Magnet RAM Capturer, FTK Imager, and older versions of DumpIt. The table below lists some of the unsuccessful tools I’ve identified. I should note that the DumpIt v3 issue was not necessarily related to VSM; rather, it was a lack of an EV certificate that prevented the DumpIt driver from loading in the first place.
Fortunately, there are tools that currently dump memory even when VSM is enabled. The tools I’ve identified at this point are Belkasoft RAM Capturer, Comae Technologies‘ DumpIt v3.0.20170620, and Passmark osforensics v5.1.1001. There are also some tools that I have not yet been able to test due to licensing issues or otherwise. These include options such as WindowsSCOPE and the combination of F-Response with a separate acquisition tool. If anyone has a specific tool or version they would like to see tested, let me know and I’d be happy to give it a shot and report the results as long as the tool is available to me.
Update (9/6/17): I was able to use a trial license of WindowsSCOPE to test memory acquisition from a system with VSM enabled. WindowsSCOPE was not able to acquire a memory dump, but it did not result in a system crash. Instead, a small error message reported that the selected memory “could not be fetched”. The table above has been updated with these results.
Update (9/11/17): According to Stick Dave, the lastest version of winen (as of 9/11/17) fails to acquire memory from a system with VSM enabled. Like many other tools, it fails with a BSOD.
Update (3/23/18): The latest version of DumpIt (3.0.20180307.1) also acquires memory from a system with VSM enabled without causing a BSOD.