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

SAM Dump for accounts without secrets #1839

Closed
Dfte opened this issue Oct 20, 2024 · 3 comments · Fixed by #1860
Closed

SAM Dump for accounts without secrets #1839

Dfte opened this issue Oct 20, 2024 · 3 comments · Fixed by #1860
Assignees
Labels
in review This issue or pull request is being analyzed

Comments

@Dfte
Copy link

Dfte commented Oct 20, 2024

I realised that some defaults Windows accounts, like for example WDAGUtilityAccount, throw the following error:

image

However there is no error here. WDAGUtilisatyAccount does not have a NT hash in the SAM database because this is a virtual account used to contain applications in a sandbox (for example browsers) and these featuers are not used on windows servers. Considering I never saw secretsdump failing in dumping SAM database, I believe it is possible to switch the following liens from impacket/impacket/examples/secretsdump.py:

if userAccount['NTHashLength'] == 0:
    logging.error('SAM hashes extraction for user %s failed. The account doesn\'t have hash information.' % userName)
    continue

to

if userAccount['NTHashLength'] == 0:
    logging.debug('SAM hashes extraction for user %s failed. The account doesn\'t have hash information.' % userName)
    continue

That way most of tools using impacket secretsdump won't have a messed up output.

Let me know what you think about this :)

@Dfte Dfte changed the title SAM Dump for accoutns without secrets SAM Dump for accounts without secrets Oct 20, 2024
@gabrielg5 gabrielg5 self-assigned this Nov 7, 2024
@anadrianmanrique anadrianmanrique added the in review This issue or pull request is being analyzed label Nov 22, 2024
@gabrielg5
Copy link
Collaborator

Hi @Dfte,
Which configuration are you running on? I tried here with a Windows Server 2019 in azure and the account WDAGUtilityAccount has a hash that is printed when running secretsdump
Also rechecked that the account was disabled (according to #802), and it was
image
I'm running a Windows Server 2019 v1809

@gabrielg5 gabrielg5 added the waiting for response Further information is needed from people who opened the issue or pull request label Dec 5, 2024
@Dfte
Copy link
Author

Dfte commented Dec 6, 2024

I have tested this against a domain controller. Now it's ovbious that there are no hashes for such accounts in the SAM database which is disabled anyway for domain controllers. But is there really a reason to display an error for such use cases considering there is no way for a local account not to have at least a default LM/NT hash ?

@gabrielg5
Copy link
Collaborator

Hey,

mm I don't think so.
I wanted to better understand / replay that scenario to check if there's some property in those objects that could help us realize it's not an issue not having gathered the hash.
But yes, I agree with you that we shouldn't be showing this case as an error

Will be playing with it a bit more and can create a PR to change it

@gabrielg5 gabrielg5 removed the waiting for response Further information is needed from people who opened the issue or pull request label Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in review This issue or pull request is being analyzed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants