This repository has been archived by the owner on Sep 2, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 113
Sharphound never completes #73
Comments
Actually, I just ran into this on a domain that I'm on. The issue is actually because if an OU has a large number of objects, it can actually take a long time for SharpHound to process the computer objects inside. I have a fix for this in place that I'll be deploying. If you eliminate the Container collection method, the rest of it should work (in theory) |
Excellent and thank you! |
we have the same issue as described in the first post. hoping for a fix... |
with the latest source code updates this seems to be fixed now. thank you! |
Should be closed in BloodHoundAD/SharpHound@c6f43e3 |
It's obviously entirely possible that my current working environment is unique, but I pulled the latest BH content from GitHub as of 7/2 and the following command has been running for seven days, with repeated status of "395 objects enumerated" for the duration. Happy to test something else/different and any input is appreciated!
"SharpHound.exe -v -d mydomain.com --domainctonroller mydc1 --ou ou=servers,dc=mydomain,dc=com -c group,localgroup,localadmin,trusts"
[cid:57d19f60-4cca-47b8-b30b-c9fda7a16858]
Thank you!
Patterson Cake
Haven Information Security, LLC
360.713.2011
…________________________________
From: Jeff McJunkin <[email protected]>
Sent: Tuesday, July 2, 2019 9:00 AM
To: BloodHoundAD/SharpHound
Cc: Patterson Cake; Author
Subject: Re: [BloodHoundAD/SharpHound] Sharphound never completes (#73)
Should be closed in c6f43e3<BloodHoundAD/SharpHound@c6f43e3>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<BloodHoundAD/SharpHound#73?email_source=notifications&email_token=AL425J62SDYBFZMF2JIPQ73P5N3RTA5CNFSM4HIFCAH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZBYB4I#issuecomment-507740401>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AL425J5WWNTDZVGRRSTTXX3P5N3RTANCNFSM4HIFCAHQ>.
|
Can you run individual collection methods to figure out if one of them in particular is causing the lockup? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm doubtful this is an "issue" with the ingestor, I just can't figure out a solution for the current environment. I've tried multiple variations, from specifying OU, domain and DC; increasing threads; different collection modes; increasing verbosity just to get some insight; and it runs with a repetitive "status nnn objects enumerated" message, which seems to indicate it's working! I've let it run for more than 72 hours for a single OU (recognizing that isn't terribly descriptive). If I hit Ctrl+C, I get a "waiting for cleanup" message, followed by status messages that also never seem to end (waited several hours). For the environment in question, my only successfully completed runs were limited to collection of groups and trusts. Any ideas/suggestions are much appreciated!
The text was updated successfully, but these errors were encountered: