On the x64 version of Windows 2003 or XP (kernel 5.2), almost every tool fails to dump the LSA secrets and the domain cached credentials. Not sure why this has never been picked up before...
C:\>systeminfo | findstr /r /c:"^OS Version:" /c:"^System Type:"
OS Version: 5.2.3790 Service Pack 2 Build 3790
System Type: x64-based PC
C:\>reg save hklm\security z:\w2k3r2x64\security.save
C:\>reg save hklm\system z:\w2k3r2x64\system.save
Using the latest version of Impacket's secretsdump.py (svn r1389), we get a decryption error:
$ python impacket/examples/secretsdump.py -system ./system.save -security ./security.save LOCAL
Impacket v0.9.13-dev - Copyright 2002-2015 Core Security Technologies
[*] Target system bootKey: 0x5272bccbeb751023c3ce8cf7c7ec9413
[*] Dumping cached domain logon information (uid:encryptedHash:longDomain:domain)
[*] Dumping LSA Secrets
[!] Input strings must be a multiple of 8 in length
[*] Cleaning up...
Same bug with Metasploit, when parsing the registry live, directly on the host:
meterpreter > run post/windows/gather/lsa_secrets
[*] Executing module against BLAH2K3
[*] Obtaining boot key...
[*] Obtaining Lsa key...
[*] XP or below system
[-] Post failed: OpenSSL::Cipher::CipherError data not multiple of block length
[-] Call stack:
[-] /home/seb/tools/exploit/metasploit-framework/lib/msf/core/post/windows/priv.rb:354:in `final'
[-] /home/seb/tools/exploit/metasploit-framework/lib/msf/core/post/windows/priv.rb:354:in `block in decrypt_secret_data'
[-] /home/seb/tools/exploit/metasploit-framework/lib/msf/core/post/windows/priv.rb:345:in `each'
[-] /home/seb/tools/exploit/metasploit-framework/lib/msf/core/post/windows/priv.rb:345:in `decrypt_secret_data'
[-] /home/seb/tools/exploit/metasploit-framework/modules/post/windows/gather/lsa_secrets.rb:63:in `block (2 levels) in get_secret'
[-] /home/seb/tools/exploit/metasploit-framework/modules/post/windows/gather/lsa_secrets.rb:46:in `each'
[-] /home/seb/tools/exploit/metasploit-framework/modules/post/windows/gather/lsa_secrets.rb:46:in `block in get_secret'
[-] /home/seb/tools/exploit/metasploit-framework/modules/post/windows/gather/lsa_secrets.rb:42:in `each'
[-] /home/seb/tools/exploit/metasploit-framework/modules/post/windows/gather/lsa_secrets.rb:42:in `get_secret'
[-] /home/seb/tools/exploit/metasploit-framework/modules/post/windows/gather/lsa_secrets.rb:111:in `run'
However Mimikatz will work nicely:
mimikatz # lsadump::secrets z:\w2k3r2x64\system.save z:\w2k3r2x64\security.save
Domain : BLAH2K3
SysKey : 5272bccbeb751023c3ce8cf7c7ec9413
Policy subsystem is : 1.7
LSA Key : 02e5d2269c0423de06bdbfff76c002d2
Secret : D6318AF1-462A-48C7-B6D9-ABB7CCD7975E-SRV
cur/hex : a8 fd 4f ac 04 34 d3 48 bb 0f 01 68 89 f6 60 d8
Secret : DPAPI_SYSTEM
cur/hex : 01 00 00 00 de 58 e1 db 8a 76 c1 da f7 0e 49 76 37 8f b4 a2 ec 64 d6 47 e0 9a f9 ba 88 23 44 cd e4 86 8f ad f8 8b 01 9c e8 e4 cf c7
[...]
Mimikatz works because it properly extracts the encrypted value of the LSA secret before decrypting it. Whereas the other tools do not extract the right amount of ciphertext and therefore fail at decrypting the secret.
Mimikatz simply reads the first 4 bytes of the LSA secret binary blob (in Policy\Secrets\secretname\CurrValue) to get the correct size of the encrypted secret:
mimikatz/modules/kuhl_m_lsadump.c:
717: key.Buffer = lsaKeyUnique->key;
718: data.Length = data.MaximumLength = ((PNT5_HARD_SECRET) secret)->encryptedStructSize;
719: data.Buffer = (PBYTE) secret + szSecret - data.Length; // dirty hack to not extract x64/x86 from REG ; // ((PNT5_HARD_SECRET) secret)->encryptedSecret;
Benjamin calls it a dirty hack because he reckons they probably just use their own structures at Microsoft. However simply using the size information was an easy shortcut for him and allows mimikatz to be able to parse x64 hives on a x86 system and vice versa.
Surprisingly the other tools do not look at the size information and have all assumed that the encrypted secret starts at offset 0xC in the blob, which is correct on x86 but not on x64.
For example, let's have a look at the DPAPI_SYSTEM secret. On x86 the encrypted secret starts at 0xC indeed (0x44-0x38):
However on x64, the encrypted secret starts at 0xF (0x48-0x38):
As these tools are not able to properly decrypt the LSA secrets, they are not able to dump the Domain Cached Credentials either because on NT5, each DCC is encrypted with the LSA secret NL$KM (stored in Policy\Secrets\NL$KM).
I looked at the source code of a lot of other tools and they all use the same offset. The earliest reference to this offset seems to come from a program called x_dialupass2.cpp published in October 2004:
LSADataIn.pbData = (BYTE *)Data + 0xC; //密文从第0xC位开始 << translates to "ciphertext at 0xC from start"
LSADataIn.cbData = dwSize-0xC;
LSADataIn.cbMaxData = LSADataIn.cbData;
This offset might have been borrowed from someone else's research though. The google-translated Chinese isn't very clear and mentions some demo code from a Russian forum which no longer exists.
The x_dialupass2.cpp program simply scans the memory of lsass.exe to extract the LSA key, then for each LSA secret in the registry, it reads the encrypted secret at offset 0xC and calls advapi.dll:SystemFunction005 to decrypt the secret with the LSA key (no one could figure out the decryption algorithm at the time).
A year later, the program CacheDump copied the code of x_dialupass2 to dump the domain cached credentials. The approach becomes: scan lsass.exe to extract the LSA key, read the encrypted NL$KM secret at offset 0xC, call advapi.dll:SystemFunction005 to decrypt NL$KM and use it to decrypt every DCC.
Since then, the 0xC offset has been carried into every subsequent tool.
I've compiled a list of tools that are unable to dump the LSA secrets and/or the DCC on NT5 x64.
I've found this 0xC offset in all of the open-source tools. For the two closed-source tools, Cain & Abel and Nirsoft's lsa_secrets_view, they must be using this offset as well because they don't work either.
In chronological order:
Tools not affected:
On the other hand, tools that use DLL injection into lsass are not affected because they call LsarQuerySecret of lsasrv.dll or LsaRetrievePrivateData of advapi32.dll to obtain the LSA secrets unencrypted:
I was able to reproduce this issue on Windows 5.2.3790 (2003 or XP). Note that starting with Vista (NT6), LSA secrets are decrypted in a different manner (no offset needed anymore), so you should have only experienced this bug on Windows 2003 & XP. Although again, I couldn't find any past discussion about it.
Here is a patch for secretsdump that fixes this issue:
--- secretsdump.py (revision 1389)
+++ secretsdump.py (working copy)
@@ -821,6 +821,10 @@
def __decryptSecret(self, key, value):
# [MS-LSAD] Section 5.1.2
plainText = ''
+
+ encryptedSecretSize = unpack('<I', value[:4])[0]
+ value = value[len(value)-encryptedSecretSize:]
+
key0 = key
for i in range(0, len(value), 8):
cipherText = value[:8]
@@ -890,7 +894,7 @@
tmpKey = self.__sha256(self.__LSAKey, record['EncryptedData'][:32])
self.__NKLMKey = self.__decryptAES(tmpKey, record['EncryptedData'][32:])
else:
- self.__NKLMKey = self.__decryptSecret(self.__LSAKey,value[1][0xc:])
+ self.__NKLMKey = self.__decryptSecret(self.__LSAKey, value[1])
def __pad(self, data):
if (data & 0x3) > 0:
@@ -1055,7 +1059,7 @@
record = LSA_SECRET_BLOB(plainText)
secret = record['Secret']
else:
- secret = self.__decryptSecret(self.__LSAKey,value[1][0xc:])
+ secret = self.__decryptSecret(self.__LSAKey, value[1])
self.__printSecret(key, secret)
Reach me at @lanjelot for more intel. Thanks for reading!