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(at)studenti.unina.it

Many thanks to Jason R. DePriest for 'patching' my english ^_^