Old-style Windows NT LM hash recovery - Revision history

Huntertur: /* Manual recovery */ Be clear that this is not yet a proper LM hash

2024-02-05T07:24:21Z

Manual recovery: Be clear that this is not yet a proper LM hash

← Older revision		Revision as of 07:24, 5 February 2024
Line 30:		Line 30:
	## For the example account, Key 1 will be: <code>f4 01 00 00 f4 01 00</code>		## For the example account, Key 1 will be: <code>f4 01 00 00 f4 01 00</code>
	## For the example account, Key 2 will be: <code>00 f4 01 00 00 f4 01</code>		## For the example account, Key 2 will be: <code>00 f4 01 00 00 f4 01</code>
	# Split the LM hash into two 8-byte chunks.		# Split the encrypted LM hash into two 8-byte chunks.
	## For the example account, Chunk 1 is: <code>09e72baf281e2a2e</code>		## For the example account, Chunk 1 is: <code>09e72baf281e2a2e</code>
	## For the example account, Chunk 2 is: <code>00092899a8cb74f3</code>		## For the example account, Chunk 2 is: <code>00092899a8cb74f3</code>

Huntertur: /* Manual recovery */ Make hash filename consistent

2024-02-05T05:01:00Z

Manual recovery: Make hash filename consistent

← Older revision		Revision as of 05:01, 5 February 2024
Line 64:		Line 64:
	## If you have a GPU, this will execute in the order of seconds.		## If you have a GPU, this will execute in the order of seconds.
	## If you do not have a GPU, this will execute in the order of tens of minutes.		## If you do not have a GPU, this will execute in the order of tens of minutes.
	# Run <code>hashcat -m 3000 -a 3 ~~fixed~~.txt --show</code> to see the password.		# Run <code>hashcat -m 3000 -a 3 hashes.txt --show</code> to see the password.
	## Do ''not'' trust the password output of the command from the previous step. It will only show the recovered password for the first half of the LM hash even though both halves were recovered and needed to successfully login.		## Do ''not'' trust the password output of the command from the previous step. It will only show the recovered password for the first half of the LM hash even though both halves were recovered and needed to successfully login.
	## The output will be in LM Hash : Uppercase Password format, like this: <code>ae6e1b1fccb24d5b944e2df489a880e4:COMPUTER</code>		## The output will be in LM Hash : Uppercase Password format, like this: <code>ae6e1b1fccb24d5b944e2df489a880e4:COMPUTER</code>

Huntertur: /* Attempted tools */ Add creddump's behavior

2024-02-05T04:38:59Z

Attempted tools: Add creddump's behavior

← Older revision		Revision as of 04:38, 5 February 2024
Line 9:		Line 9:
	" No LANMAN hash found either. Try login with no password!"		" No LANMAN hash found either. Try login with no password!"
	* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)		* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)
			** ''incorrectly returns the null LM hash''
	* impacket 0.11.0 (specifically, secretsdump.py)		* impacket 0.11.0 (specifically, secretsdump.py)
	** "TypeError: 'NoneType' object is not subscriptable"		** "TypeError: 'NoneType' object is not subscriptable"

Huntertur: /* Attempted tools */ Move creddump's error to impacket's

2024-02-05T04:06:15Z

Attempted tools: Move creddump's error to impacket's

← Older revision		Revision as of 04:06, 5 February 2024
Line 9:		Line 9:
	" No LANMAN hash found either. Try login with no password!"		" No LANMAN hash found either. Try login with no password!"
	* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)		* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)
⚫	** "TypeError: 'NoneType' object is not subscriptable"
	* impacket 0.11.0 (specifically, secretsdump.py)		* impacket 0.11.0 (specifically, secretsdump.py)
		⚫	** "TypeError: 'NoneType' object is not subscriptable"

	The crux of the incompatibility appears to be that Microsoft changed the format of the structures in SAM in NT4 SP3 to add support for the then-new Syskey utility, adding another layer of encryption provided by a ''boot key''. This boot key is stored in the registry by default, but Syskey can require it to be entered upon boot. The old SAM format does not have any concept of this, but the four tested tools all expect it to exist.		The crux of the incompatibility appears to be that Microsoft changed the format of the structures in SAM in NT4 SP3 to add support for the then-new Syskey utility, adding another layer of encryption provided by a ''boot key''. This boot key is stored in the registry by default, but Syskey can require it to be entered upon boot. The old SAM format does not have any concept of this, but the four tested tools all expect it to exist.

Huntertur: /* Attempted tools */ Add error for creddump

2024-02-05T04:05:57Z

Attempted tools: Add error for creddump

← Older revision		Revision as of 04:05, 5 February 2024
Line 9:		Line 9:
	" No LANMAN hash found either. Try login with no password!"		" No LANMAN hash found either. Try login with no password!"
	* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)		* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)
			** "TypeError: 'NoneType' object is not subscriptable"
	* impacket 0.11.0 (specifically, secretsdump.py)		* impacket 0.11.0 (specifically, secretsdump.py)

Huntertur: /* Attempted tools */ Add error from chntpw

2024-02-05T04:04:53Z

Attempted tools: Add error from chntpw

← Older revision		Revision as of 04:04, 5 February 2024
Line 7:		Line 7:
	** "SAM account's F value has a wrong size"		** "SAM account's F value has a wrong size"
	* chntpw version 1.00 140201		* chntpw version 1.00 140201
			" No LANMAN hash found either. Try login with no password!"
	* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)		* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)
	* impacket 0.11.0 (specifically, secretsdump.py)		* impacket 0.11.0 (specifically, secretsdump.py)

Huntertur: Fix typo in computer model

2024-02-05T04:00:43Z

Fix typo in computer model

← Older revision		Revision as of 04:00, 5 February 2024
Line 1:		Line 1:
	'''Old-style Windows NT LM hash recovery''', specifically for the pre-NT4 SP3 world, does not seem to be documented. I recently had to figure this out for recovering the Administrator password for the [[~~Motorla~~ Net6200/166]], which was running the PowerPC version of Windows NT 4.0 SP2. I hope this information can be useful for others.		'''Old-style Windows NT LM hash recovery''', specifically for the pre-NT4 SP3 world, does not seem to be documented. I recently had to figure this out for recovering the Administrator password for the [[Motorola Net6200/166]], which was running the PowerPC version of Windows NT 4.0 SP2. I hope this information can be useful for others.

	== Attempted tools ==		== Attempted tools ==

Huntertur: Create page

2024-02-05T03:52:04Z

Create page

New page

'''Old-style Windows NT LM hash recovery''', specifically for the pre-NT4 SP3 world, does not seem to be documented. I recently had to figure this out for recovering the Administrator password for the [[Motorla Net6200/166]], which was running the PowerPC version of Windows NT 4.0 SP2. I hope this information can be useful for others.

== Attempted tools ==

The following tools were attempted to be used to recover the LM hash for the Administrator account. All of them either bombed out with an error message or crashed.
* Cain & Abel v4.9.56
** "SAM account's F value has a wrong size"
* chntpw version 1.00 140201
* creddump ed95e1a9a920e04733a2950f7de0ff5bdfec631c (specifically, pwdump.py)
* impacket 0.11.0 (specifically, secretsdump.py)

The crux of the incompatibility appears to be that Microsoft changed the format of the structures in SAM in NT4 SP3 to add support for the then-new Syskey utility, adding another layer of encryption provided by a ''boot key''. This boot key is stored in the registry by default, but Syskey can require it to be entered upon boot. The old SAM format does not have any concept of this, but the four tested tools all expect it to exist.

== Manual recovery ==

# Obtain an offline registry editor. I used Registry Spy 1.1.0 by Andy Smith.<ref>https://github.com/andyjsmith/Registry-Spy</ref>
## <code>sudo apt install libxcb-cursor0</code>
## <code>python3 -m venv env</code>
## <code>source env/bin/activate</code>
## <code>python3 setup.py install</code>
## <code>registryspy</code>
# Get a copy of <code>%WINDIR%\System32\Config\SAM</code> from the pre-NT4 SP3 machine.
# Navigate to <code>\SAM\Domains\Account\Users\000001F4</code>. This represents the Administrator account. <code>000001F4</code> is its ID (decimal 500).
# Copy the 32nd last to 16th last bytes of the hexadecimal view of <code>V</code> somewhere, without whitespace. This should be your ''encrypted'' LM hash. Mine looked like this: <code>09e72baf281e2a2e00092899a8cb74f3</code>
# Compute the little-endian representation of the account's ID. For the Administrator account, this will be: <code>f4 01 00 00</code>
# Repeat this representation three and a half times, to get fourteen bytes. Split this in half to get two 56-bit DES keys.
## For the example account, Key 1 will be: <code>f4 01 00 00 f4 01 00</code>
## For the example account, Key 2 will be: <code>00 f4 01 00 00 f4 01</code>
# Split the LM hash into two 8-byte chunks.
## For the example account, Chunk 1 is: <code>09e72baf281e2a2e</code>
## For the example account, Chunk 2 is: <code>00092899a8cb74f3</code>
# DES-decrypt Chunk 1 with Key 1 and Chunk 2 with Key 2, then concatenate both decrypted chunks. This is your ''decrypted'' LM hash. Mine looked like this: <code>ae6e1b1fccb24d5b944e2df489a880e4</code>
## As a quick-and-dirty solution, I took the Wine implementation of DES,<ref>https://github.com/wine-mirror/wine/blob/c3918f2a82fd67301cf5fe1b35894506a34a2135/dlls/advapi32/crypt_des.c</ref> removed the two <code>#include</code> statements, and appended this: <syntaxhighlight lang="c">
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
char *k1 = "\xf4\x01\x00\x00\xf4\x01\x00";
char *k2 = "\x00\xf4\x01\x00\x00\xf4\x01";
char *in1 = "\x09\xe7\x2b\xaf\x28\x1e\x2a\x2e";
char *in2 = "\x00\x09\x28\x99\xa8\xcb\x74\xf3";
char out1[8];
char out2[8];

CRYPT_DESunhash(out1, k1, in1);
CRYPT_DESunhash(out2, k2, in2);

for (int i = 0; i < 8; i++)
printf("%x", (unsigned char)out1[i]);
for (int i = 0; i < 8; i++)
printf("%x", (unsigned char)out2[i]);

puts("");

return EXIT_SUCCESS;
}</syntaxhighlight>
# Create a text file named <code>hashes.txt</code> that contains the ''decrypted'' LM hash in a colon-delimited format.
## An example looks like this: <code>Administrator:500:ae6e1b1fccb24d5b944e2df489a880e4::::</code>
# Run <code>hashcat -m 3000 -a 3 hashes.txt</code> to recover the password.
## If you have a GPU, this will execute in the order of seconds.
## If you do not have a GPU, this will execute in the order of tens of minutes.
# Run <code>hashcat -m 3000 -a 3 fixed.txt --show</code> to see the password.
## Do ''not'' trust the password output of the command from the previous step. It will only show the recovered password for the first half of the LM hash even though both halves were recovered and needed to successfully login.
## The output will be in LM Hash : Uppercase Password format, like this: <code>ae6e1b1fccb24d5b944e2df489a880e4:COMPUTER</code>
# Take the uppercase password and attempt to login to the pre-NT4 SP3 machine with some permutation of casing.
## While the LM hash is computed from an uppercase version of the password, the machine might still need the correct casing in order to login. For me, the correct casing was <code>computer</code>.
## It is likely best to attempt all-uppercase, all-lowercase, and sentence-case versions first, before brute-forcing all ''2^n'' possibilities, where ''n'' is the count of alphabetical characters in the recovered password.

== References ==

<references />

[[Category:Guides]]
[[Category:Windows]]