Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong historic secrets returned with LOCAL extraction #395

Closed
eth0izzle opened this issue Feb 25, 2018 · 10 comments
Closed

Wrong historic secrets returned with LOCAL extraction #395

eth0izzle opened this issue Feb 25, 2018 · 10 comments

Comments

@eth0izzle
Copy link

Hello,

I have a test server running Server 2016 with a standard AD setup and two users: noreset who has never reset thier password, and onereset who has reset their password once.

When extracting remotely everything works as expected:

python examples/secretsdump.py administrator:Passw0rd1@192.168.1.34 -history
acme.local\noreset 4894 aad3b435b51404eeaad3b435b51404ee 959ce30ddaed8e43368221ccd00962f5
acme.local\onereset 4895 aad3b435b51404eeaad3b435b51404ee 9b6527a2fa104886453b3b75bc0da9d6
acme.local\onereset_history0 4895 aad3b435b51404eeaad3b435b51404ee c0720d115b8b326aca0d9b95f0eca86e

The NTLM hash for acme.local\onereset_history0 is as expected, c0720d115b8b326aca0d9b95f0eca86e.

But extracting locally using SYSTEM and ntds.dit files (extracted from the same system) gives me:

python examples/secretsdump.py -system SYSTEM -ntds ntds.dit -history -just-dc-ntlm LOCAL
acme.local\noreset 4894 aad3b435b51404eeaad3b435b51404ee 959ce30ddaed8e43368221ccd00962f5
acme.local\noreset_history0 4894 aad3b435b51404eeaad3b435b51404ee 215c72ffbce4db065a3f075b39154e80
acme.local\noreset_history1 4894 aad3b435b51404eeaad3b435b51404ee bafb0405c405283ac16851a403482bc7
acme.local\onereset 4895 aad3 b435b51404eeaad3b435b51404ee 9b6527a2fa104886453b3b75bc0da9d6:::
acme.local\onereset_history0 4895 aad3b435b51404eeaad3b435b51404ee a26020764ab3ad49a93c64ea11c5c70e
acme.local\onereset_history1 4895 aad3b435b51404eeaad3b435b51404ee aa13c6953012c0f43131f7d4264fc5ce
acme.local\onereset_history2 4895 aad3b435b51404eeaad3b435b51404ee bef1c8ab6a55532771edffc5a17a19b9

Firstly you will see the noreset user has two history passwords. Secondly onereset has 3 historic passwords, and neither of the NTLM hashes are correct - they don't even match the remote extraction (c0720d115b8b326aca0d9b95f0eca86e) from above.

I have no idea why this is happening. Can anybody shed any light?

@eth0izzle eth0izzle changed the title Wrong historic passwords returned with LOCAL extraction Wrong historic secrets returned with LOCAL extraction Feb 25, 2018
@asolino
Copy link
Collaborator

asolino commented Mar 17, 2018

Hey @eth0izzle

That is indeed strange. Have you replicated the same issue on other systems?.. How did you extracted the DIT file and hives? VSS?

@eth0izzle
Copy link
Author

Not yet. DIT and hive was extracted using ndsutil (which I believe uses VSS).

@asolino
Copy link
Collaborator

asolino commented Nov 20, 2018

Closing. Reopen if somebody experiences the same issue

@asolino asolino closed this as completed Nov 20, 2018
@xorcat
Copy link

xorcat commented Apr 26, 2019

I believe I'm seeing the same issue with a DIT extracted from a Server 2016 host using VSS.

I did not attempt extraction remotely, so I can't say that the result was different, and I sadly no longer have access to the environment.

What I can say, is that out of ~3000 current hashes, I was able to crack ~50%, and from the extracted _history hashes (~45000), I have been able to crack zero (0).

Unfortunately, as I hope you can understand, I'm unable to share the files.

Let me know if there is any further diagnosis which I can perform.

$ python2 ~/tools/impacket/examples/secretsdump.py -ntds ntds.dit -system SYSTEM -history -outputfile secretsdumped.txt LOCAL
Impacket v0.9.18-dev - Copyright 2002-2018 Core Security Technologies
[...]

@eth0izzle
Copy link
Author

@asolino I have also experienced the same issue on a different machine since my original issue.

@xorcat
Copy link

xorcat commented Apr 26, 2019

Also, debug output, in case it's helpful, for a particular user's extraction (hashes snipped, however this particular user had 25 historic hashes)

[+] Multivalue detected in column ATTc0, returning raw results
[+] Trying to fetch page 16051 (0x7d68000)
[+] Multivalue detected in column ATTl591181, returning raw results
[+] Multivalue detected in column ATTb590468, returning raw results
[+] Multivalue detected in column ATTc0, returning raw results
[+] Multivalue detected in column ATTk590772, returning raw results
[+] Multivalue detected in column ATTm131282, returning raw results
[+] Multivalue detected in column ATTm-1610706279, returning raw results
[+] Multivalue detected in column ATTm-2066838235, returning raw results
[+] Multivalue detected in column ATTm-2029542006, returning raw results
[+] Multivalue detected in column ATTj-1770041216, returning raw results
[+] Entering NTDSHashes.__decryptHash
[+] Decrypting hash for user: John Doe
[snipped_hashes]
[+] Leaving NTDSHashes.__decryptHash
[+] Entering NTDSHashes.__decryptSupplementalInfo
[+] Leaving NTDSHashes.__decryptSupplementalInfo

@BraveLittleRoaster
Copy link

BraveLittleRoaster commented Aug 1, 2019

Can this issue be reopened? When testing on Server 2016, I am also experiencing this. I've tested a few different scenarios.

I set a user account with a password "Password123", or NTLM: 58a478135a93ac3bf058a5ea0e8fdb71
Then reset it to something randomly generated. I repeat this process a few times and here is what I'll get:
Run a few times:

26c2c3bcb1ce41980f54ddae078c97ff,
937f0e8b8bee213040e2d91baef8ac2a,
35f6a91319eed7183caa5ab02134b0bf,
1e96b23f1a554188ec72cf6744579386,
6b37bda4a1cf9ddadbb024b8b2d9b49e,
993f82de7e6b7dc4b35edbcce7dfc0fb,
a0f172dcbdd2784ef006267f84abc35a,
988d0111fa68e2635415be4fccefe081

Run some more times:

a6dfe640aaab3f1b4230fcdbfb47c861,
44089f9a96c7d67ae10c26e6f5c76f5d,
6155635d7ad0671e0cf3e1aacd2b74a9,
bde5c798bbc4528d5250d48787111024,
10f1d45ae519bc3581da4489e0b39af8,
4369e77b3828e601f7b86a24ea0d671d,
09d5819273d0a19d1f520f7799281fdd,
cb94f9229b46726f13fc469dc3a6610a,
0572e648a5ec16aaad5ee6c62fd70059,
24f2f25b67ba55e0d5202aeed374ddd4

The hash for Password123 never appears. However if it is the currently set password, it appears as normal.

@asolino
Copy link
Collaborator

asolino commented Aug 1, 2019

Please continue on #656 since looks like it's all related to the same bug.

@asolino
Copy link
Collaborator

asolino commented Aug 1, 2019

It would be good @BraveLittleRoaster to test the workaround proposed on #656 to check if that fixes the issue

@BraveLittleRoaster
Copy link

Closing. Reopen if somebody experiences the same issue

This can get replicated fairly easy. I've had this issue every time via deploying in Server 2016 & Server 2019 on AWS.

Deploy a new instance of either, install AD, load some users then start resetting their passwords to known bad NTLM hashes.

If you dump the DIT file with ntdsutil.exe or VSS it will always have different hash histories every time.
For your environment, how are you not getting this issue, I guess specifically what method are you using to copy or clone the DIT? This could help me narrow down why I'm seeing this. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants