-
Notifications
You must be signed in to change notification settings - Fork 357
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
Inconsistency between --lsa via NTLM and Kerberos #55
Comments
Maybe something is wrong in impacket. 🧐 |
The bug is located in secretsdump, function getMachineKerberosSalt(). Using Kerberos, Impacket is not able to obtain the domain FQDN and the computer name which are required to build the salt used to decrypt AESKeys. The following code patches the bug:
And now we can obain the AESKeys as well via --lsa -k Leaving this issue open until fix is merged in both fortra/theporgs/our impacket ? |
@Dfte This is a Really nice patch, I think this should be made a PR in fortra's upstream |
I'll PR this in the afternoon yeah! |
PR's done, we'll have to wait for it to be merged :) |
Hello @Dfte can you do the same pr on https://github.com/Pennyw0rth/impacket/tree/gkdi ? :) |
Closed as fixed in Pennyw0rth/impacket#3 |
It looks like there is some inconsistency between the result of the --lsa option when connecting via NTLM and Kerberos:
Below is the result when dumping lsa via a NTLM authentication:
And here is the result when dumping via Kerberos (-k):
The AES and DES keys for the DC$ account are not dumped.
I'll take a look at why ASAP.
The text was updated successfully, but these errors were encountered: