Repository: fortra/impacket
Issue category: Feature Request

Issue:
SAM Dump for accounts without secrets
I realised that some defaults Windows accounts, like for example WDAGUtilityAccount, throw the following error:

![image](https://github.com/user-attachments/assets/cb6a1d68-d50a-4a0b-8689-41bf878a9ca2)

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:

```python
if userAccount['NTHashLength'] == 0:
    logging.error('SAM hashes extraction for user %s failed. The account doesn\'t have hash information.' % userName)
    continue
```

to 

```python
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 :)


Hints:
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](https://github.com/user-attachments/assets/b96bf51c-df29-4881-b031-8927799dd7c6)
I'm running a Windows Server 2019 v1809
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 ?
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

Patch:
diff --git a/impacket/examples/secretsdump.py b/impacket/examples/secretsdump.py
index 43b776218..537c45dab 100644
--- a/impacket/examples/secretsdump.py
+++ b/impacket/examples/secretsdump.py
@@ -1432,7 +1432,7 @@ def dump(self):
             userName = V[userAccount['NameOffset']:userAccount['NameOffset']+userAccount['NameLength']].decode('utf-16le')
 
             if userAccount['NTHashLength'] == 0:
-                logging.error('SAM hashes extraction for user %s failed. The account doesn\'t have hash information.' % userName)
+                logging.debug('The account %s doesn\'t have hash information.' % userName)
                 continue
 
             encNTHash = b''


Test patch: