Push the Red Button

I've just released a technical report summarizing some work I did a couple years ago that explores how forensic memory analysis and virtual machine introspection are closely linked. Abstract : Virtual machine introspection (VMI) has formed the basis of a number of novel approaches to security in recent years. Although the isolation provided by a virtualized environment provides improved security, software that makes use of VMI must overcome the semantic gap, reconstructing high-level state information from low-level data sources such as physical memory. The digital forensics community has likewise grappled with semantic gap problems in the field of forensic memory analysis (FMA), which seeks to extract forensically relevant information from dumps of physical memory. In this paper, we will show that work done by the forensic community is directly applicable to the VMI problem, and that by providing an interface between the two worlds, the difficulty of developing new virtualization ...

Now that the IEEE Symposium on Security and Privacy program has finally been posted , I can describe some research I've been working on for the past year and a half related to virtual machine introspection (VMI) and memory forensics. A well-known problem with VMI and memory forensics is the semantic gap -- basically, the kind of information you want out of a memory image or a running VM is high level information (what processes are running, what files are open, and so on) but what you get is a big bunch of uninterpreted bytes (i.e., a view of physical memory). Bridging this gap is what tools like Volatility were built to do, and they do it well. However, building a tool like Volatility takes a lot of work and a lot of knowledge about the internals of the operating system you're trying to examine. With operating systems like Windows, which are closed source, this kind of knowledge comes from things like the Windows Internals book, blog posts, and good old fashioned reverse en...

It's pretty well known, in memory forensics circles, that there are two common ways of finding processes in memory images: list-walking , which traverses the kernel's linked list of process data structures, and scanning , which does a sweep over memory, looking for byte patterns that match the data found in a process data structure. Having two different ways of finding processes can be very handy, especially when we suspect that someone may be trying to hide processes. One common way of hiding processes in Windows is called DKOM (Direct Kernel Object Manipulation) ; this technique works by just unlinking the process you want to hide from the kernel's list, like so: This makes it invisible from programs such as the task manager, as well as memory forensic tools that use list-walking (including Volatility's pslist). However, such hidden processes can still be found by scanning memory using a signature for the process data structure; this is what psscan2 does. Unfortunatel...

This past Tuesday I attended the 2009 SANS Forensic Summit. In part, I was there to give a talk on combining volatile memory analysis with forensic analysis (see below for the slides from that), but I was also pretty excited about getting to hang out with the bright lights of the forensics community like Harlan Carvey, Chris Pogue, Richard Bejtlich, and many more. Unfortunately, I was only able to attend the first day, which consisted primarily of technical talks on various aspects of forensics, incident response, and live forensics. All the talks were really excellent; Rob Lee and the folks at SANS should be commended for their great work in putting everything together. In this post I'm going to just describe the talks, rather than the panels; unfortunately I forgot to take notes during the panels and so I don't have as much to say about them, other than that they were fun and highly informative. On to the talks! The first talk of the morning was Richard Bejtlich's keynote...

I've been too busy to do any longer entries recently, but I wanted to note a couple things quickly. First up, Andreas Schuster has just released a wonderful set of slides on using Volatility to do memory forensics. The slides include: Great background material on the how, what, and why of memory acquisition and forensics. A refresher on some OS basics you need to really understand memory analysis. An amazing and comprehensive walkthrough on how to use a number of Volatility modules plugins in an investigation (including a few of my own tools, like ssdt.py and VolReg ). Great information on the internals of Volatility, including a tutorial on creating your own plugins. This is really awesome stuff, and I highly recommend it to anyone looking to learn more about Volatility or even start contributing to the community with new plugins! Many thanks to Andreas! Second, I wanted to let everyone know once again that I'm going to be speaking at the SANS WhatWorks Summit in Forensics a...

Tim Morgan was looking for some reference Windows 7 registry hives the other day to test reglookup , and it occurred to me that others might find them useful as well. So, without further ado, here's a link to download some registry hives I took from a fresh Windows 7 VM. Also, in case you were thinking of being clever, the VM password was "password" ;)

Peter Norris was kind enough to point me at his Masters Thesis, The Internal Structure of the Windows Registry . Much of the information was previously available from a variety of sources (including this blog), but Peter's work also goes into a lot of unexplored territory, and doesn't shy away from the more esoteric aspects of the registry -- like how and when the Configuration Manager decides to update the on-disk copy of the registry with changes from memory. Anyone who works with registry data for forensics or creates tools to work with the Windows registry would do well to give this a thorough read-through. Thanks to Peter for this excellent contribution!

When I first released the registry tools for Volatility , I discussed the possibility of interoperating with Harlan Carvey's excellent RegRipper . Now, thanks to Inline::Python and a bit of hackery, you can now run RegRipper against a memory image! Unfortunately, since Inline::Python only seems to work on Linux, you'll need to have a working Linux box around to use this (if anyone knows of a cross-platform way to use Python code from Perl, please let me know!). I'll get to the details of how this works later, but for now let's talk about how you actually use this stuff. First of all, since we depend on Inline::Python to manage the unholy union of Perl and Python, you'll need to get it from CPAN or your distribution's package manager. No need to install Parse::Win32Registry ; I've replaced it with my own registry code that will run against memory. Next, you should download the latest version of the registry tools [ tarball , zip ] (side note: I updated the...

I've found a couple bugs in the registry code I released recently, and at least one is significant enough that a new release is warranted. Teach me to release code I wrote in a couple hours on a plane ;) The list of fixes is: Fix a bug that prevented any volatile subkeys from appearing when using the subkeys() function. Add a check for None when using lsadump (reported by Paul Bobby, thanks!) Add appropriate license statements at the top of each file (thanks AAron!). For the record, the license is the GNU General Public License (GPL). You can download the new version as a zip or tarball , and install it exactly as the previous version, by extracting it into your Volatility directory. If you have a previous version installed, this should just overwrite it (though you may have to tell your unzip program that's okay). As before, PyCrypto is required for the credential extraction modules. One final note: I have seen some crashes when people attempt to use the hash extraction code...

Hi everyone! I know it's a bit late, but I made you all a Christmas present: tools for accessing registry data in Windows memory dumps. This the work that I presented at DFRWS 2008 ; it took a while to release because I had to find time to port it to Volatility 1.3. To use them, grab either the zip or the tarball and extract it to your Volatility directory. You'll get the following new plugins (along with some supporting files): hivescan : finds the physical address of CMHIVE structures, which represent a registry hives in memory hivelist : takes a physical address of one CMHIVE, returns the virtual address of all hives, and their names printkey : takes a virtual address of a hive and a key name (e.g., 'ControlSet001\Control'), and display the key's timestamp, values and subkeys hashdump : dump the LanMan and NT hashes from the registry (deobfuscated). See this post for more details on how this is accomplished. lsadump : dump the LSA secrets (decrypted) from the ...

By now, you all probably know that you can dump running programs from memory using the procdump module in Volatility. But not all malware runs as a user-mode process. What about malicious kernel modules? As it turns out, dumping these is also quite straightforward, and it's easy to write a plugin to do it. In fact, it's downright trivial -- kernel modules are just PE files mapped into kernel memory (in exactly the same way as normal programs are PE files mapped into user memory). So to dump a particular kernel module, we can use Volatility's built-in PE dumper (the source is in forensics/win32/executable.py , and point it at the memory address of a kernel module. Naturally, I've made a plugin that implements this: grab moddump.py and put it in your memory_plugins directory, and you'll be good to go. Here's what it looks like in action: $ python volatility moddump --help Usage: moddump [options] (see --help) Options: -h, --help show this help mes...

In which window messages are explored, a new plugin is created, and we learn the importance of reading messages sent to you regularly. In Windows, the GUI system is event-driven –actions occur in response to various events generated by the system. When you press a key on the keyboard, Windows generates a window message (specifically, WM_KEYDOWN ) and sends it to the thread that owns the window that's in focus. That thread then call's the window's event handling procedure (the so-called WindowProc ) to process the message. There are many such messages , covering input events such as keyboard and mouse actions, system-level events such as notification of a time change or a change in the system's power state , and events related to the windowing system, such as resizing or moving a window. How can these be forensically relevant? Well, as it turns out, some threads in buggy applications aren't always good at processing their messages, and messages they receive pi...

Throughout our previous discussions of registry keys, hives, and so on, we have run into the concept of a cell index several times. They appear in kernel memory in places such as the KeyCell member of the _CM_KEY_CONTROL_BLOCK structure; likewise, all of the structures representing portions of the hive itself ( _CM_KEY_NODE , _CM_KEY_VALUE , and so on) have members that point to other structures by cell index rather than by virtual address. The reason for this is that registry hives live two lives: one, as on-disk files, stored in %WINDIR%\system32\config\ , and another, as an in-memory structure that the Configuration Manager uses in memory. In the former, cell indices can be thought of essentially as simple offsets from the start of the file; in the latter, however, the situation is more complicated. When registry hives are represented in memory, they must account for the fact that new keys and values may be added at any time. Since space for the hives is allocated out of paged po...

Last time , we found out how to find information about loaded registry hives in Windows memory dumps. However, just knowing what hives are loaded may not be particularly useful. To fill out our view of the state of the system's registry, we will also want to get information about registry keys currently open in the Configuration Manager. To start, though, we will need to know a little bit more about how the Configuration Manager represents keys in memory. Each open key is represented by a Key Control Block. Key Control Blocks, or KCBs, store a number of pieces of metadata about the key, such as the name, last write time, pointers to the cached values contained in the key (recall that the registry is essentially a filesystem, where keys act as folders and values are the files). To see precisely what information we can get about a key from its KCB, we can look at the _CM_KEY_CONTROL_BLOCK structure in Windbg: lkd> dt nt!_CM_KEY_CONTROL_BLOCK +0x000 RefCount : Uint2B ...

The Windows registry can be an important forensic resource. Harlan Carvey has written extensively on various aspects of registry analysis, and is even considering writing a book on the topic. I have already written about attempting to extract hives from memory ; in this post, we will again look at registry hives in Windows memory, but this time in a more top-down fashion, by examining the data structures used to represent hives by the Configuration Manager. A hive is represented by the Windows Configuration Manager using the _CMHIVE data structure. You can examine this structure in detail using the dt command in Windbg: lkd> dt nt!_CMHIVE +0x000 Hive : _HHIVE +0x210 FileHandles : [3] Ptr32 Void +0x21c NotifyList : _LIST_ENTRY +0x224 HiveList : _LIST_ENTRY +0x22c HiveLock : Ptr32 _FAST_MUTEX +0x230 ViewLock : Ptr32 _FAST_MUTEX +0x234 LRUViewListHead : _LIST_ENTRY +0x23c PinViewListHead : _LIST_ENTRY +0x24...

David Litchfield of NGS Software has put up several excellent articles on Oracle Database Forensics. Litchfield is generally considered to be the most knowledgeable person in the field of database security, so his thoughts on database forensics carry a lot of weight. So far four articles have been posted: Oracle Forensics Part 1: Dissecting the Redo Logs Oracle Forensics Part 2: Locating Dropped Objects Oracle Forensics Part 3: Isolating Evidence of Attacks Against the Authentication Mechanism Oracle Forensics Part 4: Live Response I haven't read through them in detail yet, but it looks like they have a ton of awesome information about the binary format of the redo logs and recovering information that has been deleted (dropped) from the database.

I've just had my first paper accepted to a conference! The paper, titled The VAD Tree: A Process-Eye View of Physical Memory, describes how to use the Virtual Address Descriptor structure of the Windows kernel to do a variety of nifty things, including list DLLs loaded by the process and categorize a process's memory allocations into shared regions, mapped files, and private allocations. I'll be presenting it at the 7th annual Digital Forensics Research Workshop in Pittsburgh this August. Here's the abstract: This paper describes the use of the Virtual Address Descriptor (VAD) tree structure in Windows memory dumps to help guide forensic analysis of Windows memory. We describe how to locate and parse the structure, and show its value in breaking up physical memory into more manageable and semantically meaningful units than can be obtained by simply walking the page directory for the process. Several tools to display information about the VAD tree and dump the memory re...

Despite my earlier bold claims that I'd be doing more analysis of "Big Yellow," I'm going to have to renege for now. At work, we recently came across a user who was trying to connect to an external IP upwards of a thousand times per day; some investigation showed that his machine had been compromised by a trojan, and so we started in on incident response. This has left me with very little time to look at Big Yellow, but it did give me something new to write about--Windows memory forensics. Our first response was to get the user to run a cool little bundle that my friend Andy and I have been working on that collects as much forensically important information from the user's system as possible and uploads it to a server using Webjob . The package includes a bunch of Sysinternals tools, ftimes to get file hashes and search for specific strings, and a version of dd from the Forensic Acquisition Utilities that can dump physical memory. This last bit is what we'l...