CravateRouge / bloodyAD

BloodyAD is an Active Directory Privilege Escalation Framework
MIT License
1.12k stars 112 forks source link

Cannot add, remove, or modify SPNs #44

Closed Alh4zr3d closed 6 months ago

Alh4zr3d commented 7 months ago

Hi there! I love this tool and recently showcased it on my livestream but we ran into a little issue while in the demo. I was using it to demonstrate the exploitation of CVE-2022–26923, discussed in this blog post by Oliver Lyak. This exploitation chain requires the following:

1.) Check ms-DS-MachineAccountQuota to verify it is not 0. 2.) Use low-priv credentials to create a new machine account. 3.) Remove SPNs from new machine account which represent a full DNS name (eg. "computer.domain.local" rather than just "computer"). 4.) Change dnsHostName property of machine account to match domain controller. 5.) Request certificate and authenticate as domain controller account.

The first four of these I was hoping to do entirely with BloodyAD, but only 1, 2, and 4 seemed possible. I tried many variants of the "set" command with BloodyAD trying to clear SPNs, add SPNs, and so on but all of them met errors: image image

Some of the errors are LDAP errors and some are Python-related; the latter arose when I tried -v '' or left -v off entirely and appear to be related to trying to convert a null value to unicode. These were attempts to remove all SPNs, but I also failed to add SPNs as seen in the top. I was able to add these SPNs (example: HOST\test) while logged into the Domain Controller normally (like a sysadmin would be) but BloodyAD would not add or remove any SPNs at any point. There was always either an LDAP or Python error.

Eventually, I was able to clear the SPNs with addspn.py from the "krbrelayx" repo: image

After this, BloodyAD was able to modify the dnsHostname property without an issue and exploitation was completed. It was only with the "serviceprincipalname" property that I encountered issues.

This may or may not be a problem with BloodyAD, but I figured you could at least show me the correct syntax for removing/changing/adding SPNs with the tool. There are multiple tutorials in existence online that exploit this CVE with BloodyAD (using an apparently old syntax involving "setAttribute" instead of "set"), so it seems like either no one has documented the correct new syntax or at some point, an issue was introduced.

Thanks for your time! Love the tool and was consistently impressed with it outside this one small issue!

CravateRouge commented 7 months ago

Hello Alh4zr3d, thanks for the interest you have for the tool!

Indeed it's a good catch! When no -v is provided the value sent to ldap3 is None which is not supported by the library, instead 217e7f2 will fix this by sending an empty list instead if no value is provided. Also note that when using set it will replace the old values of ServicePrincipalName with only the new ones provided so you can directly provide only the SPNs you're interested in (-v HOST/cthulhu-pc -v RPC/cthulu-pc ...).

PS: If you want you can send a PR on the wiki for CVE-2022–26923 on CVE exploit page with your commands and outputs so other will be able to reproduce it.

dkjajhqu2h3j commented 6 months ago

I also stumbled on this issue today. I am however trying to perform an attack on a RODC by editing the attributes msDS-RevealOnDemandGroup and msDS-RevealOnDemandGroup. In my test adlab1_domainadmin1 have GenericAll rights so that cannot be the problem. As above, I can clear the attributes but I cannot restore them (as in writing the original values back):

bloodyad1

CravateRouge commented 6 months ago

@dkjajhqu2h3j Can you try the following and send me a screenshot of it:

$ get object 'rodc1$' --attr msDS-RevealOnDemandGroup
# Copy paste the values from the output
$ set object 'rodc1$' msDS-RevealOnDemandGroup -v "Value1 from previous output" -v "Value2" ...
dkjajhqu2h3j commented 6 months ago

The attribute msDS-RevealOnDemandGroup was cleared above so currently it is empty. However, I saved the original value and when getting you the screenshot I noticed an error. The DN I used, "'CN=Allowed RODC Password Replication'", was incorrect. It should be "'CN=Allowed RODC Password Replication Group,CN=Users,DC=adlab1,DC=local'". This works.

bloodyad2

dkjajhqu2h3j commented 6 months ago

However...

After attempting the attack again, adding Administrator to the attribute then listing the attribute again, I only see the first DN: bloodyad3

Nerver mind! Turns out I was faster than the DC :) A moment later it appeared.

CravateRouge commented 6 months ago

Good to know! I think I will close the issue now