No SID For ServerListFile Servers

[Zamanry]

Hello, on a non-domain joined Windows 10 machine without any EDR/AV, I got the following error:

The txt file had four known, line-delimited MSSQL servers with SPNs running on TCP/1433. It successfully collected all of them as seen by the large orange box's 4 lines where their FQDNs were. Looking for help here.

[Mayyhem]

Thanks for the report! I'm checking this out today and will get back to you.

[Mayyhem]

@Zamanry , I'm having trouble replicating this issue from a non-domain joined machine using the AD module or the .NET DirectoryServices fallback, but I'll do my best to help troubleshoot.

• Is a domain controller configured as one of the DNS resolvers for the system running MSSQLHound?
• Are you able to resolve those FQDNs in the target domain from that machine with nslookup?

You can also try adding the -Verbose switch to your command and stepping through the Get-DomainsToTry and Test-DomainAccessibility functions to see where the failure occurs. If you'd like to redact and send me the results with the -Verbose switch on, I can take a closer look too.

[Zamanry]

Hi Chris, thanks for the help! See below:

• My DNS servers point to DC1 and DC4. We've been able to resolve through system DNS just fine on this engagement.
• nslookup succeeded for the FQDNs of the SQL servers. nslookup also works for DC FQDNs and IPs.

I am running this from a runas /netonly shell, running PowerShell 5.1. Account is valid as seen in the shell via:

net use F: \\dc01.ad.domain.com\SYSVOL
The command completed successfully.

PS C:\Users\localusername\Desktop\mssqlhound> net use F: /del

Please note that this system has eth0 and eth1. eth0 is client-facing internal network, eth1 is Crowe-internal facing (169.254.100.3). For the public IPs, I kept the first octet accurate. Here's the -verbose output:

Zamanry-MSSQLHound-Error.txt

[Mayyhem]

Thanks for the detailed info and for taking the time to redact all of that! The problem is occurring here somewhere:

VERBOSE: Testing domain resolution for: ad.domain.com
VERBOSE: Domain 'ad.domain.com' resolves to private IP(s): 10.120.120.120, 10.121.121.121, 10.122.122.122, 10.123.123.123
VERBOSE: Testing domain resolution for: domain.com
VERBOSE: Domain 'domain.com' resolves to public IP(s): 3.4.5.6, 15.16.17.18 - skipping
VERBOSE: Skipping domain 'domain.com': doesn't resolve to private IP
...
VERBOSE: Testing domain accessibility: ad.domain.com
VERBOSE: Domain accessibility test timed out for 'ad.domain.com'
VERBOSE: Domain 'ad.domain.com' accessibility: False
VERBOSE: Skipping inaccessible domain: ad.domain.com

I think the hardcoded timeout might just be too short and the initial Get-ADDomain test is failing too early as a result here:

MSSQLHound/MSSQLHound.ps1

Line 4132 in ab04d43

$null = Get-ADDomain -Identity $Domain -ErrorAction Stop

Can you please try finding this line and increasing the timeout to a higher value?

MSSQLHound/MSSQLHound.ps1

Line 4097 in ab04d43

[int]$TimeoutSeconds = 5

If that works, I can increase the default value and make it a user-defined command line option. We could also try adding an option to use DNS or .NET DirectoryServices explicitly even if the ActiveDirectory module is available and see if that works.

Thanks again for submitting this feedback. We'll get to the bottom of it!

[Zamanry]

I increased timeout to 10, no dice. But I see the issue. Whenever we use cmdlets like Get-ADDomain, we always have to add -Server dc1.ad.domain.tld or -Server ad.domain.tld traditionally. In this picture below, should I have DNS servers listed within the DNS server addresses, in order of use:? I've always figured DHCP would update this, no? Point is, the Get-ADDomain I think depends on this box.

Please note that there is ad.forest.com and ad.domain.tld. I've been mindful in my redactions to be accurate. However, forest is barely ever used. Domain is used 99%.

[Mayyhem]

I'm not entirely sure. If you're able to resolve the SQL boxes when your DNS servers point to DC1 and DC4, then I don't know why Get-ADDomain wouldn't pick that up from your system's settings like nslookup does, but I think this is worth adding a command line option that allows you to specify a domain controller for Get-ADDomain/DirectoryServices. I'll work on that and get back to you.

It's always DNS ☠️

[Mayyhem]

@Zamanry I just added a -DomainController command line option and updated all the DNS resolution functions to use it. Please let me know if this resolves the issue. Thanks!

[Mayyhem]

@Zamanry Could you please let me know if you've had a chance to test this fix or if you'd like me to mark this as resolved?

[Zamanry]

I can test it next week!

[Zamanry]

It worked! But only when the -ServerFileList systems were FQDNs, not IPv4 addresses. Probably a good idea to require FQDNs or just resolve the IPv4s. -DomainController worked with IPv4 and FQDN. (the README needs updated to have -DomainController too 😊)

I cannot say enough how appreciative my coworkers and I are for you dedication in resolving this! Thank you!

[Mayyhem]

Awesome! And you're welcome! Thank you for coming back to this to retest. I updated the README with that option -- good catch. I'm going to leave this open until I have a chance to add reverse DNS lookups for IPs. Really appreciate your feedback!