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
"setDCSync" fails #6
Comments
You give me ideas to improve the tool and I thank you for that :) When you want to give DCSync rights, you add ACL entries to the Domain object. So the user BIR-ADFS-GMSA$ must have setDCsync right because it is the one that you use to connect (With NTLM auth in your case) to the AD to perform your modifications. If BIR-ADFS-GMSA$t owns the domain object or has GenericAll right on the domain object, you can use autobloody to automate those steps in order to obtain DCSync right. If you don't know what to do with a right on an object, right click on the edge in BloodHound and click on help, you'll have details on it. |
Great! I assumed having the GenericAll right included being able to add the DCSync right but that is obviously not the case. When I reverse the command above, targeting "BIR-ADFS-GMSA$" using tristan.davies (domain admin), this works. However, when I try to use autobloody to automate this as you suggest I get an error. |
I think you found a bug! |
Can you add |
My bad, I forgot the case, try the latest commit c82bca8, it should work now. |
It should be fixed with eb108a9 |
And this error should be fixed with 54f1ea7 ! |
Now I no longer get a functional error but it seems tristan.davies is not allowed to change the password of bir-adfs-gmsa despite being a domain administrator. If I try to change the password manually using bloodyAD.py or even more manually using RPCClient (which you use too I think) I get the same result. Is that expected? Perhaps this is the case only for GMSA accounts? I also have a related question. In actual engagements I would rarely opt to change the password of an existing account. I would instead consider for example setting the "DONT_REQ_PREAUTH" flag on the account and then AS-REP roast it hoping to crack it's password. Is there a way to control the end result of the automation? I know I can do this manually but if the automation can help me with more complex exploit chains that would help. |
bloodyAD use the SAMR call The automation doesn't aim for actual engagements but I plan to implement shadowCredentials and use of CVE-2021-42287/CVE-2021-42278 as an alternative to the password change. |
The domain search.htb actually belongs to Hack The Box. I sometimes use their machines to test things on :) Therefore I do not have access to ADCS in that domain. I do have ADCS in my private lab and I have tested CVE-2021-42287/CVE-2021-42278 (SAM-The-Admin, "https://github.com/WazeHell/sam-the-admin") in that which works. However, these vulnerabilities will likely be patched, if that hasn't been done already. Thanks for you help! I will keep an eye on your tool. |
Just a comment for those who read this. What you need in order to use the "setDCSync" command is access to a domain user object or a domain computer object that has WriteDACL rights on the domain root or on a domain controller. For example. By default, unless patched or if the Active Directory Split Permissions model is used, Exchange servers have this right. See "https://support.microsoft.com/en-us/topic/reducing-permissions-required-to-run-exchange-server-when-you-use-the-shared-permissions-model-e1972d47-d714-fd76-1fd5-7cdcb85408ed". BloodyAD actually grants GenericAll rights to the target object which is more than is needed in order to DCSync. This is good to know if for example Bloodhound is used to verify this. |
Hi. Me again :) This time I am trying to add DCSync rights to the account "tristan.davies" using the same environment as in my first ticket in which "BIR-ADFS-GMSA$" has GenericAll rights on "tristan.davies".
It seems the targeted account is successfully identified since its SID is outputted but then something happens. In my test environment "tristan.davies" is a domain admin and thus already has this right if that is the problem?
The text was updated successfully, but these errors were encountered: