Push the Red Button

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" ;)

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

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

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