Windows 2k/NT/XP's syskey encryption Syskey is a Windows feature that adds an additional encryption layer to the password hashes stored in the SAM database. The main purpose of this feature is to deter 'offline' attack. In fact one of the most common ways to gather passwords is to copy the system SAM database and then use one of the many good password crackers[1] to "recover" the passwords; of course physical access is almost always required. So with syskey the attacker needs to remove the additional encryption layer to get the password hashes (this is not entirely true as some tools can crack even syskeyed hashes while losing some performance). The key used by Syskey to encrypt the password hashes (called bootkey or system key) can be generated and stored in three ways. The method to use is selected when running syskey.exe on the host. 1) Using a user supplied passphrase(actually the MD5 hash of it). The system will prompt for the passphrase during startup. 2) Using a system generated key stored on a floppy. The system will ask for the boot floppy during startup. 3) Using a system generated key stored on the "the local system using a complex obfuscation algorithm" (citing Microsoft site[2]). This is the default method used. In the first two cases generally nothing can be done. If you cannot get the passphrase or the boot floppy you are compelled to crack the syskeyed hashes. The last case is different. This document describe the "complex obfuscation algorithm" and the steps required to restore the password hashes from their syskeyed equivalent. Some tools are also presented to automate the process. From now on we will talk about the case when the bootkey is stored on the system. During Windows boot phase before user are allowed to logon to the system, the main thread of Smss (Session Manager) starts the Winlogon process. Winlogon is the process required to load the Local Security Subsystem (Lsass) which in turn loads the Security Accounts Manager (SAM) service (the interface to the SAM database). The registry is accessed by the above-mentioned processes. In particular the following keys are accessed: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\JD HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Skew1 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Data HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\GBG The same keys are also accessed during the bootkey generation phase by the Syskey.exe tool. A more in depth analysis of the code accessing these keys uncover that the "complex obfuscation algorithm" is no more than a permutation of the class name of the above-mentioned keys. Is almost trivial to develop a tool to recover the syskey obfuscated bootkey from the registry. To make things simpler on pre SP4 system the ACL on the above keys allows 'Users' read access so a "normal" user can retrieve the registry stored bootkey. The tool developed to make this operation is called Bkreg. On SP4+ system it is still possible to recover the syskey bootkey. The ACLs on the keys only allow Administrator access, so Bkreg can recover the bootkey on SP4 system only if executed by the Administrator. But there is another way to access the registry keys. An attacker can steal (maybe at the same time of the SAM database) the system hive and access from there the above mentioned keys to recover the syskey bootkey. The tool developed to make this operation is called Bkhive. Now we have the bootkey, conveniently stored in a file, and the SAM hive; we need to know how to remove the syskey encryption. The process that decrypts the password hashes (using the bootkey) is Samss. The steps required to do so are: 1) The value 'F' of the registry key SAM\SAM\Domains\Account is accessed. The contents of that value is of binary type. 16 byte (starting at offset 0x70) from the F value are hashed (MD5) with the bootkey and some constant. The result is used as the key to decrypt (RC4) the 32 byte of the F value (starting from 0x80). The first 16 byte of the result are used later in the algorithm. I call them hbootkey. 2) For each rid subkey in SAM\SAM\Domains\Account\Users. The value 'V' of the key is accessed. The content of that value is of binary type and contain the syskey encrypted password hashes. The hbootkey (computed in step 1), the user rid and a constant string( different if decoding NT or lanman password) are hashed (MD5). The result is used as the key to decrypt (RC4) the syskeyed password hashes. So syskey encrypts the password hashes with the RC4 algorithm using as key "something" derived (through MD5) from the syskey bootkey. I've developed a tool to automate the above steps and include the features of SAMDUMP. The tool is called SAMDUMP2; SAMDUMP2 can, when given a SAM hive and a bootkey file (generated by Bkreg or Bkhive), output the password hashes in SAMDUMP/PWDUMP format. So an attacker with physical access can: 0) Boot using another OS (maybe Linux or DOS) 1) Steal the SAM and SYSTEM hive (from %WINDIR%\System32\config) 2) Recover the syskey bootkey from the SYSTEM hive using Bkhive (or Bkreg on pre Sp4 system) 3) Dump the password hashes using SAMDUMP2 4) Crack them offline using his favorite cracking tool References [1] http://www.atstake.com/products/lc/ http://www.oxid.it/cain.html http://www.openwall.com/john/ http://www.openwall.com/passwords/nt.shtml [2] http://support.microsoft.com/support/kb/articles/q143/4/75.asp Nicola Cuomo ncuomo@studenti.unina.it Many thanks to Jason R. DePriest for 'patching' my english ^_^