-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added option to do Session Enumeration as local Admin User #47
Conversation
Currently hardcoded local Admin that is used for the privileged session enumeration.
fix option parsing
Fix tests, add local admin impersonation for netsessionenum
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
I have read the CLA Document and I hereby sign the CLA |
recheck |
This is an awesome PR, I've gotta dig into this a bit |
Thanks Rohan. This ofcourse could now be wrapped too, as the library is there. Accordingly every function that would need it as well. |
Hi @phillipharding, I noticed you have been given credit for creating the Impersonate.cs file in this PR: https://github.com/BloodHoundAD/SharpHoundCommon/pull/47/files#diff-4121b9ee7af13bcce5901c1278346c5985d7964db39d80f718b0ffb2ff35a81b Can you confirm that you are ok with your work being used in this project? :) BR Jonas |
To add to this for the sake of completeness it was found here: Which linked to here: |
This is the needed PR to SharpHoundCommon that allows to set an option to do session enumeration with a dedicated local (admin) user.
Credits to @eversinc33 how helped me a lot with this.
The situation with more recent pentests and red-team engagements is most likely that you see higher numbers of Windows Server 2016 + as well as Windows 10 1607 +. So the privileged session enumeration via NetWkstaUserEnum needs to be with a user that has local admin rights. Once gaining a foothold or in an assumed breach scenario we will most likely do not have these rights.
But, and that is very common, we do local priv esc on the client, fetch the local admin's credentials, and it happens to be some lame password that is reused accross a large scope of systems - worst case even servers. Same applies to once we get a server's local admin password, and this one is reused.
SharpHound was not able to do this, because it would run the session checks in the context of the user that runs the collector.
What we did was to add 3 new flags:
-DoLocalAdminSessionEnum
-LocalAdminUsername
-LocalAdminPassword
We added a new library (Impersonate.cs ) that allows us to impersonate another remote local user in the current user's context via the LOGON32_PROVIDER_WINNT50 option from the advapi32.dll.
That allows us to wrap the session enumeration stuff inside an impersonated user's context and overcome the limitations mentioned above.
Credits to @phillipharding for this library.
Everything else is done as the running user, so no impact on the rest of what SharpHound is doing.
I created a POC video demonsrating how it works:
https://www.youtube.com/watch?v=mMpNs3MXISM
BloodHound documentation was extended accordingly as well as the SharpHound project itself. Accordings PRs were opened.
SpecterOps/SharpHound#40
SpecterOps/BloodHound-Legacy#646