Sharphound versions past 2.4.1 not working when running in shell using runas /netonly

Start by reproducing the failure with SharpHound 2.4.1 and 2.5.1 from a non-domain-joined system using a shell launched with runas /netonly, then compare the behavior with a domain-joined machine. Use the documented command variants, net view, and nslookup checks described in the issue; done means a current SharpHound version resolves the domain and produces files that import into BloodHound CE.

I have been trying to use Sharphound to collect from a non-domain joined system (which is the way that I have always previously collected) when running from a shell launched using the runas /netonly command as is documented.

I am able to use this method successfully when using version 2.4.1, but that version only works with older versions of Bloodhound. Even though version 2.4.1 says that it works with version 5.0.0 release of Bloodhound the files fail to ingest into Bloodhound CE (version 2.5.7 and 2.5.8 both give the same message about Bloodhound compatibility yet those files do import into BH CE).

The error message that I get when attempting to use any Sharphound past version 2.4.1 is:

Unable to resolve a domain to use, manually specify one or check spelling

I have tried numerous command line iterations to try and get a current version of Sharphound to work. Examples:

.\SharpHound.exe --CollectionMethods All -d <domain>.ad.<domain>.local --disablecertverification --overrideusername pentest01@<domain>.ad.<domain>.local --domaincontroller <domain controller>.<domain>.ad.<domain>.local

.\SharpHound.exe -d "<domain>.ad.<domain>.local" --disablecertverification --overrideusername "<domain>\pentest01" --domaincontroller "<domain controller>.<domain>.ad.<domain>.local"

.\SharpHound.exe -d <domain>.ad.<domain>.local --disablecertverification --overrideusername pentest01@<domain>.ad.<domain>.local --domaincontroller <domain controller>.<domain>.ad.<domain>.local

.\SharpHound.exe --CollectionMethods All -d <domain>.ad.<domain>.local --overrideusername pentest01@<domain>.ad.<domain>.local --domaincontroller <IP Address>

.\SharpHound.exe --CollectionMethods All -d <domain>.ad.<domain>.local --disablecertverification --overrideusername pentest01@<domain>.ad.<domain>.local --domaincontroller <IP Address>

I have also tried using --domain insted of -d and that made no difference

I have validated that the authentication within the shell launched using the runas command is valid by using the net view command:

net view \\<Domain FQDN>\

When doing this I see the NETLOGON and SYSVOL shares so I know that I am authenticated to the domain. I know that DNS resolution is working. I can use nslookup to query for the Domain FQDN and get back a list of domain controllers

nslookup <Domain FQDN>

returns list of domain controller IP addresses

I am also able to use nslookup to query the domain controller used in the Sharphound commands.

The screenshot below shows the net view command showing successful authentication of the user against the domain by returning the domain controller shares, NETLOGON and SYSVOL (I have executed the same net view command on the same system in a shell the was not launched using the runas /netonly command and it returns access denied

The screenshot also shows the command run and the returned error message

I have used Sharphound version 2.5.1 successfully on a domain joined machine (but it is a royal PITA because Defender EDR is running on the domain joined machine) using the same commands and it works, so there definitely appears to be an issue with seeing the domain when launched from a shell running on a machine that is not domain joined.

Given the issues with running Sharphound on a domain joined machine that has Defender EDR running on it I would much rather run Sharphound from my non-domain joined Commando VM that does not have Defender EDR running on it.

Am I doing something wrong? Am I missing something? Is there a way to get the current versions of Sharphound to work from a non-domain joined machine?

If not, please, please fix this.

Thanks!