"setDCSync" fails about bloodyad HOT 15 CLOSED

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 I remember correctly you can duplicates ACE, so I don't think that tristan.davies already having those rights is the problem here.

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.

from bloodyad.

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.

from bloodyad.

I think you found a bug!
Try with the latest commit c166caa and tell me if it works.

from bloodyad.

There is some progress but now I get a different error.

from bloodyad.

Can you add print('I've been here') at line 173 and print(sAMAccountName) at line 177 of bloodyAD/modules.py and show me the output please?

from bloodyad.

I updated the code but I do not see the added print statements when running it.

from bloodyad.

My bad, I forgot the case, try the latest commit c82bca8, it should work now.

from bloodyad.

New error :)

from bloodyad.

It should be fixed with eb108a9

from bloodyad.

from bloodyad.

And this error should be fixed with 54f1ea7 !

from bloodyad.

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.

from bloodyad.

bloodyAD use the SAMR call SamrSetInformationUser2, that is slightly different from the one of rpcclient if I remember correclty. In the documentation, it's written that it can modify a user object and maybe GMSA accounts like machine accounts are not considered as user objects.
You can still try using LDAPS (if you have an ADCS for your domain) or kerberos (unfortunately you can't use kerberos because ldap3 only supports kerberos authentication and not encryption). Using LDAPS to change the password could be allowed.

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.

from bloodyad.

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.

from bloodyad.

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.

from bloodyad.