Push the Red Button

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

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

I've been taking a look at the structure of PDB files recently. PDB files are Microsoft's proprietary file format for storing debug information. They are generated by the Visual Studio family of products, and Microsoft has been kind enough to provide a full set of PDB files for its own operating system files since Windows 2000, which means that we get access to a whole bunch of great information like function symbols and type information. These can provide an excellent insight into the internals of the Windows operating system. Naturally, the file format is undocumented and proprietary (there used to be a page on MSDN stating as much, but I can't seem to find it now). However, Sven Schreiber, in his book Undocumented Windows 2000 Secrets: A Programmer's Cookbook , provides details on the format and some sample code for reading the information in such files. Although the original code only deals with PDB files created with Visual Studio 6.0 and below, he has recently r...