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

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!

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

I'm pleased ecstatic to announce that my paper, Forensic Analysis of the Windows Registry in Memory , has been accepted into the 8th annual Digital Forensics Research Workshop ! The full program is available, and it looks like there are a lot of really cool presentations scheduled. Memory analysis is heavily featured this year, and has been given a whole session. As usual, all the papers will be posted on the DFRWS website once the conference begins. Until then, here's the abstract of my paper: This paper describes the structure of the Windows registry as it is stored in physical memory. We present tools and techniques that can be used to extract this data directly from memory dumps. We also provide guidelines to aid investigators and experimentally demonstrate the value of our techniques. Finally, we describe a compelling attack that modifies the cached version of the registry without altering the on-disk version. While this attack would be undetectable with conventional on...

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

When a Windows computer is joined to a domain, authentication of users is performed not against the local SAM database, but by querying the domain controller. From this description, we might be tempted to conclude that there won't be any useful credentials stored in the registry on a machine that is part of a domain; the users and their hashes don't actually exist on the local machine but rather on the domain controller. As it turns out, however, by default Windows does store domain credentials on client machines. The reason for this is simple: if the domain controller is unavailable for some reason, users would still like to be able to log into their machines using their credentials; for this reason Windows caches domain credentials of the last (by default) 10 users to log on to the machine. The exact number of cached logons is controlled by the value "CachedLogonCount" of HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon . Cached Credentials in the Registr...

The LSA secrets store is a protected storage area used the the Local Security Authority (LSA) system in Windows to keep important pieces of information safe from prying eyes. As with Syskey, however, we will see that these secrets are only obfuscated, and once the mechanism is known, we can extract them from the registry with ease. Even without knowing the obfuscation algorithm, however, it is possible to read the values of this data using the LsarQuerySecret function exported by lsasrv.dll, but only if one has the LocalSystem privilege (for example, if the process is running under the SYSTEM account). What kind of data is stored in these secrets? Here are a few that I've come across: $MACHINE.ACC : has to do with domain authentication, see KB175468 DefaultPassword : password used to logon to Windows if auto-logon is enabled NL$KM : secret key used to encrypt cached domain passwords L$RTMTIMEBOMB_[...] : FILETIME giving the date when an unactivated copy of Windows w...

The Security Accounts Manager The Security Accounts Manager , or SAM, has been used by Windows since the days of NT to store information on local user accounts (or, in the case of a domain controller, the accounts for all users on the domain). It takes the form of a registry hive, and is stored in %WINDIR%\system32\config . Generally, two types of hash are stored in the SAM: the LanMan hash and the NT hash. The LanMan hash has many flaws: It is not salted, and is thus vulnerable to precomputed dictionary attacks such as rainbow tables . The hash is split into two 7-byte pieces, which allows attacks to be performed against each piece at the same time. This also means that if the password is shorter than 7 characters, the last half of the hash will be a constant value. The password is converted to uppercase before hashing, which reduces the keyspace. The LM hash is computed by padding or truncating the password to 14 characters, splitting it into two halves, and then usin...

This is just a short post to talk about a new tool I've developed, called CredDump . CredDump is a pure- Python implementation of the bkhive/samdump2 , lsadump2 , and cachedump utilities commonly used to audit Windows password security. Why re-implement these tools? Well, for one thing, I like Python, and wanted to learn the details of how they all worked. Much more importantly though, this tool is completely cross-platform and requires only the registry hives recovered from the system to operate. Most other tools currently available rely on some aspect of Windows to provide their functionality. For example: lsadump2 calls advapi32.LsarQuerySecret to obtain the unencrypted LSA secrets. cachedump searches through the address space of lsass.exe to obtain the unencrypted LSA key, and uses advapi32.SystemFunction005 to decrypt the value of NL$KM with it. Cain & Abel is the closest to operating entirely offline, but still uses advapi32.SystemFunction005 to do the de...

Quick addendum: I thought it might also be fun to post how many keys were open in each hive (this is for xp-laptop-2005-07-04-1430.img -- and sorry for the huge amount of space, Blogger's auto-formatting seems to get confused around tables): Hive Key Count [...]a\Microsoft\Windows\UsrClass.dat 1 [...]Settings\LocalService\NTUSER.DAT 7 [...]WINDOWS\system32\config\SECURITY 11 [...]1\WINDOWS\system32\config\system 1122 [...]a\Microsoft\Windows\UsrClass.dat 1 [...]ts and Settings\Sarah\NTUSER.DAT 147 [...]a\Microsoft\Windows\UsrClass.dat 1 [...]\WINDOWS\system32\config\default 25 [...]ttings\NetworkService\NTUSER.DAT 4 [...]ume1\WINDOWS\system32\config\SAM 14 [NONAME] 4 [NONAME] 4 [...]WINDOWS\system32\config\software 2657

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

As I mentioned last week, I moved to a new apartment this week, and as a result I didn't have a lot of time to do any serious work. Still, I didn't want to let the entire week go to waste, so I decided to try and tackle a problem that I thought would be relatively simple: extracting a copy of the binary registry hives out of memory. As it turned out, this was actually a bit more difficult than I expected, and I'll have to get back to the problem at a later date, but I thought in the meantime I'd write about what steps I took, where I ran into trouble, and describe the approach I hope to take when I revisit the issue. There were several reasons to suspect that one might find at least partial copies of the registry in memory: the registry stores all of the configuration data for the Windows operating system, and its contents are referred to and updated quite often during normal operation (let Sysinternals' Regmon run for few minutes and look at the output if you hav...