Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
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 ^_^