[Feature Request] Username/Password options for SharpHound/Invoke-Bloodhound

[aconite33]

Scenario:

During pentest, sometimes you get user credentials to other domains that are trusted by the current context (E.g., you land in Domain 123, but have access to users in Domain 321, and can interact with their DC). Or you just want to run Bloodhound under a different user.

Additionally, if you are trying to do crossdomain Bloodhound, you may need another DNS server to request data from instead of the inherent System DNS you're executing from.

Problem:

Currently SharpHound/Invoke-Bloodhound cannot use credentials. Currently SharpHound/Invoke-Bloodhound does not support specifying a DNS server.

Solution:

Add options for SharpHound/Bloodhound so that a user can pass Username/Credentials to the ingestor, so that when it contacts the hosts, it uses a different credential to request the information.

E.g.:

Invoke-Bloodhound -Domain 321 -User User321 -Password SuperAwesomePassword321 -DomainController 3.2.1.1 -DNSServer 3.2.1.1

This way, Bloodhound can be run against the specific Domain with credentials that are not within the context of the current user/shell, and if you need DNS from another system, you can define to use another server.

Reference: Fox-It Bloodhound's implementation can do this, as it written in python and doesn't assume you can run this from a Windows PC that is connected to the domain. https://github.com/fox-it/BloodHound.py

[rvazarkar]

You can just use runas /netonly

On Tue, Jun 12, 2018, 12:44 AM aconite33 notifications@github.com wrote:

Scenario:

During pentest, sometimes you get user credentials to other domains that are trusted by the current context (E.g., you land in Domain 123, but have access to users in Domain 321, and can interact with their DC). Or you just want to run Bloodhound under a different user. Problem:

Currently SharpHound/Invoke-Bloodhound cannot use credentials Solution:

Add options for SharpHound/Bloodhound so that a user can pass Username/Credentials to the ingestor, so that when it contacts the hosts, it uses a different credential to request the information.

E.g.:

Invoke-Bloodhound -Domain 321 -User User321 -Password SuperAwesomePassword321 -DomainController 3.2.1.1

This way, Bloodhound can be run against the specific Domain with credentials that are not within the context of the current user/shell.

Reference: Fox-It Bloodhound's implementation can do this, as it written in python and doesn't assume you can run this from a Windows PC that is connected to the domain. https://github.com/fox-it/BloodHound.py

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BloodHoundAD/BloodHound/issues/183, or mute the thread https://github.com/notifications/unsubscribe-auth/AFdJfmtIz53pk5ykm9yJPpmkziVKxamVks5t7pBUgaJpZM4Ui8CM .

[aconite33]

So, this does not work if you are within a Meterpreter shell (I'd assume just as much with Empire).

I recently ran into this where I had a user/pass and could contact a foreign Domain. I couldn't not accomplish this via Meterpreter (Using their runas auxilliary module). I could however get the Fox-It Bloodhound working just fine (Using Proxychains and a Linux System to run Bloodhound.py).

Trying to get a runas with a user in a foreign domain, didn't work for me. I'd be interested if others have gotten this to work.

[rvazarkar]

So the limitation of this would be that you could query LDAP, but not query systems for sessions/local admins because those API calls do not take a credential as far as I can tell. You would be missing pretty much all session info, as well as accurate local admin info.

[aconite33]

Sure, but if you're trying to enumerate a foreign domain, at least you would get something. The best option would be to have execution inside the domain you want to enumerate, but in this use case, I wasn't able to achieve that, yet I was able to query the Foreign LDAP system.

[rvazarkar]

This is in 2.0, with the caveat that it only works for LDAP, since API calls do not accept a credential