RE: [Vol-users] Windows Server 2008

George, Thanks very much. This is good. This is probably quibbling over semantics, but it is not necessary to install WinDBG on the system whose memory you want to image. You can run LiveKD from a USB drive or mapped share. I have used LiveKD to image locally and remotely without installing anything on the host. LiveKD, kd.exe, and several other files from the Microsoft debugging toolset have to be available to the system being imaged, however. Everything you said makes sense, and it is quite valuable to have called out--especially by one of the top guys in the field. In fact, I was hoping you and others would speak up to poke all the holes you could. If I or anyone else used the procedures I outlined, they should be fully informed regarding potential drawbacks. If your memory toolset is already Windows 8 and Server 21012 ready, I will have to see if we can fit it in the budget. Having used your tools in the past, I wouldn't hesitate to employ them again. As for lag in the rest of our tool set, unfortunately for too many tools, it is too often several months to years more us. Many very well-known forensics tools are not really NTFS reliable, and we have no tools yet for Windows 8 WinInet artifacts or the new file system. Since we have tens of thousands of Windows 8 and 2012 systems running already, we have already been feeling the lag. Thank you very much. And don't be hesitant to take any of my suggestions or procedures to task. Troy -----Original Message----- From: vol-users-bounces(a)volatilityfoundation.org [mailto:vol-users-bounces@volatilesystems.com] On Behalf Of George M. Garner Jr. Sent: Tuesday, July 03, 2012 9:27 AM Cc: vol-users(a)volatilityfoundation.org Subject: Re: [Vol-users] Windows Server 2008 Troy, I will address at present only the first method, using LiveKd to acquire memory from the root OS. As we know, sophisticated malware can jump out of common VM's to the root partition. So you have to be certain that the root partition is clean before you can reliably acquire memory from the other partitions. LiveKd does produce a nice clean dump in MS crashdump format. However, the method does have a few disadvantages of which readers should be aware. The first disadvantage, as Aaron has already noted, is that LiveKd requires that you have Windbg installed. Readers of the list who are required to follow a forensic methodology may find that objectionable. However, more importantly, LiveKd essentially attaches a debugger to the system. Attaching a debugger to a contemporary version of Windows makes some significant changes to the operating system. For example, the values of nt!KdDebuggerEnabled and nt!KdDebuggerNotPresent are changed. On x64 systems the nt!KdDebuggerDataBlock is decoded and important operating system components (e.g. Patchguard) are disabled. A lot of contemporary malware will monitor the values of nt!KdDebuggerEnabled and/or nt!KdDebuggerNotPresent and either change behavior or melt when a debugger is present. A third problem is that LiveKd (like most memory forensic acquisition tools) only acquires physical memory within the OS physical memory map. It is relatively trivial, using undocumented but exported OS API's, to remove memory from the physical memory map so that the critical evidence is never acquired for analysis by most contemporary memory forensic acquisition tools. Also, some important memory artifacts may be found outside of the physical memory map even in the absence of more advanced hiding techniques. For example, the real mode interrupt vector table is located outside of the physical memory map. When BIOS or bootkits load, they typically copy some real mode code to the top of real mode memory in an area that is outside of the physical memory map. It is true that most bootkits today will attempt to remove those artifacts. However, as is often the case, installing the malicious code and then removing it is not the same as never having installed the code at all. Subtle changes remain which may be your only indication that you need to investigate this system further. The ACPI tables are not part of the physical memory map. NVRAM is not part of the physical memory map. Processor MSR registers and IOAPIC are not part of the physical memory map. Yet they both can be used to alter the flow of execution. Michael may wish to believe that this additional information "may be irrelevant for many investigations." http://lists.volatilityfoundation.org/pipermail/vol-users/2012-March/000350…. However, those are the cases that bite you in the ass. There is no magic bullet. Every investigative method has its advantages and disadvantages. However, whatever method you choose, it is important to understand how the method may affect the outcome of the investigation. At GMG Systems, we generally adopt the philosophy that more evidence is better than less. If you acquire enough evidence you are free to disregard some of it if you do not believe it pertinent to the current investigation. You still can come back to it later when you realize that you may have made a mistake. If you do not acquire some evidence, that pretty much limits your options for the future. Whatever method you choose, the "bad guys" will find out about it and look for its weaknesses. That is one reason why it is important to properly test your tools: So you are not the only one who does not know what those weaknesses are. When the operating system creates a memory dump it saves the current processor state to Pcr->Prcb.ProcessorState. The debug engine (i.e. Windbg) reads a value from that processor state to determine the segmentation (16-bit real mode, 32-bit or 64-bit proteccted mode) of the memory dump. We don't want to write anything to Pcr->Prcb.ProcessorState because we make a forensic tool and the information that would be overwritten might be relevant to some investigation. For example, it might contain the state from the last time the system hibernated. Most often though it just contains zeroes, which makes Windbg think that this is a 16-bit real mode memory dump. The irony is that Windbg uses a 64-bit linear address to look up Pcr->Prcb.ProcessorState. So it already knows that this is not a 16-bit memory dump (like that is ever going to happen on a contemporary version of Windows). Until the latest version of Windbg there was no way to tell Windbg that it had made a mistake (aside from attaching another instance of Windbg and stuffing values into the debug engine. But now we can. Think in terms of days, not weeks. Regards, George. _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users