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

[robertstrom]

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!

[robertstrom]

I just reviewed the post below - "Error in consumer" when connecting to LDAP server with SH v2.5.x - in more detail and, even though the error is not the same, the LDAP failure was similar enough it made me retry version 2.5.8 using the --ldapusername and --ldappassword arguments that it looks like it is going to work.

If I run the command without those parameters I get the same error as before:

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

When I run the command using the two ldap arguments I can see Sharphound start to talk to AD. I don't want to let it rip right now since it is outside of business hours and and a weekend and I don't want to bug the on call SOC person with a high priority ticket ;-)

I will fully test on Monday and validate for sure, but it does look like v2.5.8 fixes the issue as long as you use the two ldap arguments for user name and password.

[robertstrom]

UPDATE: While it looks like it is working when pointed to a Server 2022 domain running at the Server 2016 Forest and Domain functional levels, it looks like there are issues when pointing it to a Server 2025 Forest / test forest running at the default forest and domain functional modes

Windows2025Forest
Windows2025Domain

Again, the Sharphound v2.4.1 works from a non-domain joined machine running from a shell launched using the runas /netonly but the v2.5.8 fails to work

The two screenshots below show v2.4.1 working

This screenshot shows v2.5.8 not working

Here is a portion of the error text. What I captured was too large to post directly. I have saved the copied error text to a text file and attached it below.

PS C:\users\rstrom\Desktop\SharpHound-v2.5.8> .\SharpHound.exe --CollectionMethods All -d server2025root.local --disablecertverification --overrideusername [email protected] --ldapusername '[email protected]' --ldappassword 'P@ssw0rd!' --domaincontroller dc-1.server2025root.local
2024-10-19T20:11:19.8131739-07:00|INFORMATION|This version of SharpHound is compatible with the 5.0.0 Release of BloodHound
2024-10-19T20:11:20.0880898-07:00|INFORMATION|Resolved Collection Methods: Group, LocalAdmin, GPOLocalGroup, Session, LoggedOn, Trusts, ACL, Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote, UserRights, CARegistry, DCRegistry, CertServices
2024-10-19T20:11:20.1315803-07:00|INFORMATION|Initializing SharpHound at 8:11 PM on 10/19/2024
2024-10-19T20:11:20.6048884-07:00|INFORMATION|Flags: Group, LocalAdmin, GPOLocalGroup, Session, LoggedOn, Trusts, ACL, Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote, UserRights, CARegistry, DCRegistry, CertServices
2024-10-19T20:11:20.7684429-07:00|INFORMATION|Beginning LDAP search for Server2025Root.local
2024-10-19T20:11:21.0137916-07:00|INFORMATION|Beginning LDAP search for Server2025Root.local Configuration NC
2024-10-19T20:11:21.0607445-07:00|INFORMATION|[CommonLib ACLProc]Building GUID Cache for SERVER2025ROOT.LOCAL
2024-10-19T20:11:21.0607445-07:00|INFORMATION|[CommonLib ACLProc]Building GUID Cache for SERVER2025ROOT.LOCAL
2024-10-19T20:11:21.1355600-07:00|INFORMATION|Producer has finished, closing LDAP channel
2024-10-19T20:11:21.1494893-07:00|INFORMATION|LDAP channel closed, waiting for consumers
2024-10-19T20:11:21.3286971-07:00|ERROR|error in consumer
System.DirectoryServices.AccountManagement.PrincipalServerDownException: The server could not be contacted. ---> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
   at System.DirectoryServices.Protocols.LdapConnection.Connect()
   at System.DirectoryServices.Protocols.LdapConnection.SendRequestHelper(DirectoryRequest request, Int32& messageID)
   at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
   at System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(String serverName, ServerProperties& properties)
   --- End of inner exception stack trace ---
   at System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(String serverName, ServerProperties& properties)
   at System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
   at System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, String name, String container, ContextOptions options, String userName, String password)
   at System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType)
   at SharpHoundCommonLib.LdapUtils.<GetDomainNameFromSid>d__30.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at SharpHoundCommonLib.LdapUtils.<LookupSidType>d__24.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at SharpHoundCommonLib.LdapUtils.<ResolveIDAndType>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at SharpHoundCommonLib.Processors.ACLProcessor.<ProcessACL>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Threading.Tasks.Sources.ManualResetValueTaskSourceCore`1.GetResult(Int16 token)
   at Sharphound.Extensions.<ToArrayAsync>d__6`1.MoveNext() in D:\a\SharpHound\SharpHound\src\Extensions.cs:line 96
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Sharphound.Extensions.<ToArrayAsync>d__6`1.MoveNext() in D:\a\SharpHound\SharpHound\src\Extensions.cs:line 96
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Sharphound.Runtime.ObjectProcessors.<ProcessComputerObject>d__22.MoveNext() in D:\a\SharpHound\SharpHound\src\Runtime\ObjectProcessors.cs:line 190
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Sharphound.Runtime.ObjectProcessors.<ProcessObject>d__19.MoveNext() in D:\a\SharpHound\SharpHound\src\Runtime\ObjectProcessors.cs:line 69
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Sharphound.Runtime.LDAPConsumer.<ConsumeSearchResults>d__0.MoveNext() in D:\a\SharpHound\SharpHound\src\Runtime\LDAPConsumer.cs:line 37
2024-10-19T20:11:21.3321735-07:00|ERROR|error in consumer

I am able to run v2.5.8 successfully on the Server 2025 domain controller even with Domain controller: LDAP server Enforce signing requirements enabled (I had to disable this to have any success when running remotely from a non-domain joined machine)

sharphound_v2.5.8_error_server2025_domain.txt

[rvazarkar]

This is really interesting information. First of all, we actually sign and seal our LDAP traffic on non-ssl. As far as I've been able to tell, enabling signing on SSL connections actually causes the connections to fail, but I'll have to retest that.

The exception on PrincipalContext is definitely a problem that I'll add a ticket to fix. If anything I would have expected 2.5.X versions to work better in a netonly environment since it implements lots of extra checks and connection attempts, so this is surprising to me. The fact that the behavior changes based on functional level is also pretty strange. I'm wondering if fixing the principalcontext exceptions will allow things to continue as expected

[robertstrom]

UPDATE: Using version 2.5.8

Over the weekend I kicked off an initial test from a Windows 10 Commando VM using runas /netonly. I did not want the test to run to completion because I did not want to trigger a security alert. From the short test it looked like v2.5.8 was conencting to the LDAP server when using the --ldapusername and --ldappassword arguments.

Well, it's no longer the weekend and I have kicked off the full run of Sharphound v2.5.8 from the Command VM and it looks like it is running and collecting data, but it is also throwing a LOT of errors.

Text file with error information attached.

The first run you see in the attached file shows the results when not using the --ldapusername and --ldappassword arguments.

The second run when using the arguments does appear to be collecting data. You can see lines like the lines below splattered in with all the error messages:

2024-10-21T08:30:15.1781189-07:00|INFORMATION|Status: 321 objects finished (+321 10.7)/s -- Using 100 MB RAM
2024-10-21T08:30:50.8818714-07:00|INFORMATION|Status: 927 objects finished (+465 14.26154)/s -- Using 150 MB RAM

2024-10-21T08:42:47.4984970-07:00|INFORMATION|Status: 32199 objects finished (+3396 41.17519)/s -- Using 147 MB RAM
2024-10-21T08:43:17.5169286-07:00|INFORMATION|Status: 32301 objects finished (+3498 39.77956)/s -- Using 147 MB RAM

I'm going to let it run until it finishes and see what I end up with.

sharphound_v2.5.8_error_in_consumer.txt

[rvazarkar]

Yeah the errors all generally appear to be related to the same thing: .net is throwing exceptions on the using statement (which is unexpected). In the linked MR, I've elevated the try/catch statements to better catch those exceptions

[robertstrom]

I let the Sharphound run to completion and it did generate what looks like a complete result set and zip it up. I was able to ingest the zip file into Bloodhound CE. It looks good. Have performed some basic queries.

2024-10-21T09:13:26.5255950-07:00|INFORMATION|Consumers finished, closing output channel
2024-10-21T09:13:26.6416356-07:00|INFORMATION|Output channel closed, waiting for output task to complete
Closing writers
2024-10-21T09:13:27.3127335-07:00|INFORMATION|Status: 234260 objects finished (+639 89.34401)/s -- Using 238 MB RAM
2024-10-21T09:13:27.3127335-07:00|INFORMATION|Enumeration finished in 00:43:42.1581925
2024-10-21T09:14:22.2050452-07:00|INFORMATION|Saving cache with stats: 18046 ID to type mappings.
126 name to SID mappings.
3246 machine sid mappings.
9 sid to domain mappings.
0 global catalog mappings.
2024-10-21T09:14:22.3891971-07:00|INFORMATION|SharpHound Enumeration Completed at 9:14 AM on 10/21/2024! Happy Graphing!
COMMANDO 10/21/2024 9:14:22 AM

[rvazarkar]

The newest build has the updated commonlib version with the linked MR. Give it a whirl