Push the Red Button

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...

If you follow Matthieu Suiche's blog (and if you don't, you really should!), you probably saw his post about an undocumented type of registry value -- CM_BIG_DATA. This is a registry optimization introduced by Microsoft with Windows XP that allows for more efficient storage of large amounts of data in the registry. You can read more about the details of this new way of storing large values in his post , but I wanted to announce the release of a new version of VolReg with experimental support for BIG_DATA values. As always, you can get the latest version of VolReg from my Volatility plugin page . This release also fixes a bug found by AAron Walters where an exception would be raised if the data returned for a value is less than the required amount for that type (e.g., only two bytes being available for a REG_DWORD). I also updated Volshell , fixing a regression found by J. Hewlett that broke the ability to use the "dt" command to examine a data structure without overl...

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!

This post could also be titled " Teaser ", part 2 :) As part of my research at GT, I've been looking at using Volatility to examine the state of running virtual machines. Using PyXa, a wrapper around Bryan Payne's XenAccess library (available in the tools directory of the latest XenAccess release), you can get access to the memory of Xen guest VMs in Python. From there, it's just a small step to create a new address space that Volatility can use to examine virtual machines just as if they were any other memory image. One application of this is using introspection to find out the state of windows on screen. This has advanced significantly since the last time I mentioned it, and it's now possible to track windows, including their z-order and some on-screen text, in near-real time. To demo this I used Volatility to examine the internal data structures of Win32k.sys and extract the locations and sizes of all visible windows, and then used PyGame to draw them ...

Everyone's been (rightfully) beating up on Guidance for their recent FUD-laden e-mail about F-Response; you should check out the excellent rebuttals by Harlan Carvey and hogfly . I'm not going to address most of the e-mail, but I thought I should tackle some things that are simply factually wrong about Volatility. I'm hardly an unbiased party (being a developer on Volatility), but unlike Guidance, I'm going to provide verifiable information to back up my claims. From the Guidance mail: While these utilities [included in the Volatility Framework] can identify running processes, open files and registry handles for running processes and open network sockets and connections, they cannot identify hidden processes, injected DLLs and NIC information. There are three factual inaccuracies in this statement: Volatility cannot identify hidden processes. In fact, Volatility can list processes using multiple methods. The pslist module walks the list of active processess, and will f...

As I've now released a number of plugins for Volatility, and some have gone through a couple revisions, I thought I'd put them all up on a single page , which can point to the latest versions and act as a sort of one-stop shop. I've also updated the registry tools yet again, to fix some bugs and add new functionality, and also made some enhancements to volshell. You can read about the changes below: Changes to VolReg : New command hivedump : dump keys and timestamps (and optionally value data) from all hives to a CSV file. Many improvements to robustness and error handling when reading key and value data. When checking the registry hive names, catch exceptions and try to continue anyway (reported by chris). Changes to volshell : A new command, dis , is available. If distorm is installed, it will disassemble bytes from a given memory address as x86 code. db no longer rounds length to a multiple of 4. Use a single profile object throughout all commands (speed improvement) dt...

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 don't have time for a full post right now, but I thought I'd offer a fun product of some things I've been working on recently. The work involves getting information about the windows on screen at the time a memory image was taken. One of the things you can extract is the position and size of each widget (called a "window", though I find this terminology a little confusing). Since I don't have time to go into the data structures and so on involved, I thought I'd give you all two "screenshots" that I reconstructed from the NIST XP SP2 memory images. Basically it's a white canvas as large as the screen resolution, with rectangles drawn on for each window on the screen. Without further ado: From the 6/25 image: From the 7/4 image: More details to come :)

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...