Help understanding limitations of "KDC_ERR_PADATA_TYPE_NOSUPP"

[ly4k]

Help understanding limitations of "KDC_ERR_PADATA_TYPE_NOSUPP"

[ly4k]

Hello @braimee and @the-useless-one

The error "KDC_ERR_PADATA_TYPE_NOSUPP" simply means that the KDC is not set up for Kerberos authentication. If this is your own domain and you want to do some more testing, you can log on to a domain controller, open the search, search for "Manager Computer Certificates" (or mmc.exe -> add snap-in "Certificates" -> "For this computer") and then request a new certificate by going to the "Personal" folder. It should appear if you expand the first folder in the listing (can't remember the name). Once you're there, right click on the right pane (probably empty) and request a new certificate. This should any certificate that supports "Server Authentication", most likely "KerberosAuthentication" or "DomainController".

And thank you @the-useless-one for commenting on this. It's correct what you say. From my experience, it seems that you will need the same sort of certificate with Server Authentication for the DC in order to connect via LDAPS, right?

Best regards
Oliver

[7MinSec]

HOLY SCHNIKES IT WORKED!!!!!

Oh my gosh thank you @the-useless-one and @ly4k so, so much for sharing your great expertise and tooling. I have been on this pentest for weeks, picking at all sorts of things that led to dead ends. I initially thought this whole KDC_ERR_PADATA_TYPE_NOSUPP was something to do with the cert configuration being protected with defensive measures (according to a colleague), so I went right past it early in the engagement. It was so fun to circle back to the issue, get outstanding support from the two of you, and finally find a path to DA!

Are you both ok with me giving you a shoutout in an upcoming podcast episode?

[the-useless-one]

Sure, thanks!

[the-useless-one]

Hi @braimee,

Yannick here, I'm the author of the last blog post you link to, and of PassTheCert (the corresponding tool). PassTheCert is not specifically about abuse with a Domain Controller cert, though it's the example given in the blog post. With a Domain Admin cert, I think you have the following valid attack paths:

1. Use the elevate user attack, to grand DCsync rights to an account you control (and you can authenticate with without a cert). If you don't have any account you know the password of, you can add a computer account in the domain. This should work since Domain Admins can modify the domain object's ACL.
2. Use the reset password attack, to reset the password of an account (since you're DA, it should be any account). I think nothing technically stops you from resetting the password of [email protected], so that you can authenticate with a password and not a cert.

Let me know how it goes, and don't hesitate to open an issue in PassTheCert if you encounter any trouble.

Cheers,

Y

[7MinSec]

Awesome thank you @the-useless-one, I'm going to hold my breath and get remoted back into this environment, get a fresh pfx and try this out. Will report back.

[Barneee]

Thanks the @the-useless-one already send me the blog post on how to abuse our blog post presenting PassTheCert:

[the-useless-one]

Hi @ly4k, I'm actually not sure what EKUs must be present in the DC certificate to support Schannel authentication. If you figure it out, please share the knowledge 😉

[7MinSec]

Wow wow wow! Thanks both of you SO MUCH for your incredibly thorough and helpful replies!

@the-useless-one I'm so excited because I think passthecert.exe is just the tool I need for the job. I can open a thread in your repo instead, but just a quick syntax question for you. I have compromised one account that I control on the target domain (lets call it pwnedacct) and I have that account SID of XXX. I used that account to grabbed the .pfx for domainadmin@victim. If I'm understanding right, the syntax I can use to give pwnedacct DCSync privs are:

PassTheCert.exe --server FQDN.OF.A.DOMAINCONTROLLER --cert-path domainadmin.pfx --elevate --target "DC=victim,DC=domain" --sid XXX

If that's right, the only part that makes me nervous is the changing of the msDS-nTSecurityDescriptor. This change only adds me the ability to DCSync, it doesn't take away any permissions or anything like that? I'm sure I'm (hopefully) being overly paranoid, but I've never used the tool before and definitely don't want to break things!

[the-useless-one]

The syntax is correct! The ntSecurityDescriptor is modified to add the necessary ACLs to grant rights to pwnedacct, the other rights are preserved. The old value of ntSecurityDescriptor is also saved to disk, and you can use the --restore flag to restore the previous value once you've done your DCsync.

[ly4k]

@the-useless-one From my testing it seems that any certificate with the Server Authentication EKU. I'm setting up a new environment to test this :)

[7MinSec]

Quick update - I tried passthecert but got an error. @the-useless-one I'll open an issue in your repo, and circle back to this thread once I know if the attack was successful.

[7MinSec]

@the-useless-one sorry one more question...I can see when I look at the domain properties in the ADUC tool that my user has specifically been added there with DCSYNC privs. Will just deleting that permission out of the config be the same as restoring the ACL via passthecert?

[ly4k]

Glad you figured it out @braimee and yes, you can! :)

[the-useless-one]

@braimee, I just noticed I didn't answer your question. It might be too late, but here goes: in elevate mode, PassTheCert adds the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All rights on the domain object to the target SID. Removing these rights via PassTheCert or any other tool should yield the same results.

[7MinSec]

Wonderful thank you so much!

And just FYI @the-useless-one / @ly4k I gave you a shout-out in the latest episode of 7MS here: https://7ms.us/7ms-532-tales-of-pentest-pwnage-part-39/.

Have a great weekend and thank you again for being so generous with your time, tools and expertise.

[Barneee]

Hi @ly4k @the-useless-one and @7MinSec ,
I'm currently in a pentest and ran into the same situation where I received the error message "KDC-ERR_PDATA_TYPE-NOSUPP". However, I received a certificate for a domain controller with the ESC8 vulnerability. Normally I would now use the secretsdump tool to carry out a DcSync attack, which is not possible due to the lack of PKINIT. Is there another way I can take over the domain with the DomainController Computer Account permissions? @the-useless-one I already checked the tool PassTheCert, but could not find a usefull command to takeover the domain with der DC computer account permissions or is it a dead end?