Samba secretsdump.py not working

xdka commented 3 years ago

Configuration

impacket version: latest (from git) Target OS: Ubuntu 16.04 Samba Version : 4.3.8

Debug Output With Command String

Password:
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
[-] DRSR SessionError: code: 0x20e4 - ERROR_DS_CANT_FIND_EXPECTED_NC - The naming context could not be found.
[*] Something wen't wrong with the DRSUAPI approach. Try again with -use-vss parameter
[*] Cleaning up... ```

Additional context

Hi,

When trying to secretsdump.py -no-pass -just-dc Domain/'DC_NETBIOS_NAME$'@DC_IP_ADDR into my SAMBA AD DC I face an error message. I Wanted to know if it was related to the implementation of secretdump or If I could have missed something during my samba configuration.

Thanks and have a great week 👍

asolino commented 3 years ago

Hey @haruju

It doesn't look like you're running secretsdump.py wrong. I don't think the DRSUAPI approach has been testes against a non Windows AD before. In fact Samba is not a scenario included in the original development of this feature (not even tested). There are clearly some things to polish based on your output.

Leaving this open in case somebody wants to add support for this scenario

xdka commented 3 years ago

Hey @asolino and thanks for the answer.

I've made some research and it seems like that the issue could be related to the following file :

file : impacket/impacket/examples/secretdumps.py class : RemoteOperations function : saveNTDS

I have little knowledges but it seems like some operations are trying to get parameters from the register and I doubt Samba/Ubuntu works that way.

I'll wait for an answer but it may takes some times I guess 👍

mingxuechao commented 3 years ago

I got the same error. my reason: DRSUAPI depend on dynamic tcp ports whitch ranges from 49152 to 65535 after windows 2008 by default. But firewall deny the port or the route drop the packages. So DRSUAPI works wrong.

jagotu commented 3 years ago

Hey,

I debugged what prevents secretsdump.py from working on samba DCs and discovered two facts:

samba requires something that looks like it belongs to the domain in the Name field, otherwise it short circuits with an error. It resolves the actual user through the guid (same as windows), but filling at least "DC=domain,DC=local" style DN into the name is necessary.
samba doesn't support pPartialAttrSet, or at least not in the way it's used by secretsdump

I prepared a version of secretsdump that successfully dumps hashes from samba on my fork (obviously still only -just-dc makes sense for samba): https://github.com/jagotu/impacket/commit/bfad6c132982d6c42cce8ff51546a8fe44e7e221

@xdka @mingxuechao could you try if this version works on your samba setups? If yes, I think I will rework it so that these changes are under a flag, as dumping samba will not be a common scenario and I wouldn't want to unnecessarily change the default code path in case it breaks in some edge cases.

mingxuechao commented 2 years ago

@jagotu It doesn‘t work with my scenario.

I got the same error. my reason: DRSUAPI depend on dynamic tcp ports whitch ranges from 49152 to 65535 after windows 2008 by default. But firewall deny the port or the route drop the packages. So DRSUAPI works wrong.

Q1984 commented 2 years ago

Hello Guys,

Is there any news regarding samba version of secretsdump? Or any other approach to extract remotely the hashes from a linux domain controller?

jagotu commented 2 years ago

I attempted to resolve some of the issues (see https://github.com/SecureAuthCorp/impacket/issues/991#issuecomment-953115070), but as samba is not a common usecase the changes probably never got tested outside of a lab environment (apart from one other comment but that turned out to be a firewall issue). A perfect opportunity for you to try and report if it works :)

If it doesn't, please provide debug output and the samba version so me or someone else can eventually look into it.

Q1984 commented 2 years ago

Thanks for the suggestion, I got the following errors when I dump with arguments

secretsdump.py -hashes :redacted administrator@192.168.xxx.xxx -just-dc -debug

[+] Calling DRSCrackNames for S-1-5-21-redacted-500 [+] Calling DRSGetNCChanges for {93ae4315-c270-4269-b487-598720f463e5} [+] Entering NTDSHashes.decryptHash [+] Decrypting hash for user: DC=redacted,DC=local [-] Error while processing user! [+] Exception Traceback (most recent call last): File "/usr/local/lib/python3.8/dist-packages/impacket/examples/secretsdump.py", line 2562, in dump self.decryptHash(userRecord, File "/usr/local/lib/python3.8/dist-packages/impacket/examples/secretsdump.py", line 2338, in decryptHash answer = "%s:%s:%s:%s:::" % (userName, rid, hexlify(LMHash).decode('utf-8'), hexlify(NTHash).decode('utf-8')) UnboundLocalError: local variable 'LMHash' referenced before assignment [-] local variable 'LMHash' referenced before assignment [+] Calling DRSCrackNames for S-1-5-21-redacted-501 [+] Calling DRSGetNCChanges for {21e244d7-9d45-40ce-a292-27149a8b6a2b} [+] Entering NTDSHashes.decryptHash [+] Decrypting hash for user: DC=redacted,DC=local [-] Error while processing user! [+] Exception Traceback (most recent call last): File "/usr/local/lib/python3.8/dist-packages/impacket/examples/secretsdump.py", line 2562, in dump self.decryptHash(userRecord, File "/usr/local/lib/python3.8/dist-packages/impacket/examples/secretsdump.py", line 2338, in decryptHash answer = "%s:%s:%s:%s:::" % (userName, rid, hexlify(LMHash).decode('utf-8'), hexlify(NTHash).decode('utf-8')) UnboundLocalError: local variable 'LMHash' referenced before assignment [-] local variable 'LMHash' referenced before assignment [+] Calling DRSCrackNames for S-1-5-21-redacted-502 [+] Calling DRSGetNCChanges for {7ef707e4-3e75-4707-88e8-32d4608bc0e4} [+] Entering NTDSHashes.decryptHash [+] Decrypting hash for user: DC=redacted,DC=local [-] Error while processing user! [+] Exception Traceback (most recent call last): File "/usr/local/lib/python3.8/dist-packages/impacket/examples/secretsdump.py", line 2562, in dump self.decryptHash(userRecord, File "/usr/local/lib/python3.8/dist-packages/impacket/examples/secretsdump.py", line 2338, in decryptHash answer = "%s:%s:%s:%s:::" % (userName, rid, hexlify(LMHash).decode('utf-8'), hexlify(NTHash).decode('utf-8')) UnboundLocalError: local variable 'LMHash' referenced before assignment [-] local variable 'LMHash' referenced before assignment [+] Calling DRSCrackNames for S-1-5-21-redacted-1000 [+] Calling DRSGetNCChanges for {45af8447-9f14-46e7-ae8d-4000b7a8954c} [+] Entering NTDSHashes.decryptHash [+] Decrypting hash for user: DC=redacted,DC=local [-] Error while processing user! [+] Exception

and so on till reaches the end of user sids.

Samba version: Samba 4.3.0 No firewall between.

jagotu commented 2 years ago

@Q1984 It seems possible that in some configurations samba just doesn't send back a dBCSPwd (containing the LM hash) attribute at all, which the script doesn't like.

I pushed a new commit that will hopefully resolve your issue at https://github.com/jagotu/impacket/commit/886f3ffc350ee5026b0071577b43f7aff18fa2c4

Q1984 commented 2 years ago

@jagotu Works like a charm, thank you! Do you plan to create a separate script like secretsdump_samba.py and integrate to the official impacket suite? I think it would cover this missing feature.

jagotu commented 2 years ago

@Q1984 my idea was to eventually just add a -sambasupport switch to the script (duplicating the whole script doesn't sound like a good idea).

But so far I'm more comfortable with keeping it in a fork and receiving more reports about whether it's working properly from actual real networks before throwing it onto impacket's maintainers :)

0xdeaddood commented 2 years ago

Hey @jagotu!

It works great in my environment! Currently, we're working on testing other Impacket examples against Samba. So, it would be great to add your changes to support secretsdumps.py. As you mentioned, we may need more testing before we start including changes.

jagotu commented 2 years ago

@0xdeaddood Awesome to hear that! I'll happily rework it into something more mergeable, but I kinda want to hear your opinion about the design you're aiming for, mainly with whether to alter the main flow or go with having "samba-specific" hacks behind a flag.

Given that windows probably accounts for 99.9% of this library's uses I'm leaning towards a flag, but it's your call. While these specific changes AFAIK shouldn't bring any problems to Windows interactions, for all I know they might aid in detecting by AVs and given the exclusion of partial attributes set probably increase traffic/slow down dumping.

0xdeaddood commented 2 years ago

@jagotu. I think that the flag approach would be the best option. However, let me test the rest of the cases to see if we can find a common approach to implement (and analyze the other things that you mentioned 🙂)

fortra / impacket