Help understanding limitations of "KDC_ERR_PADATA_TYPE_NOSUPP"

[7MinSec]

Hello!

Certipy has identified a number of templates in this environment vulnerable to ESC1. I've done:

certipy req 'victim.domain/myuser@fqdn.of.ca.server' -ca 'CA-NAME' -template 'VULNERABLETEMPLATE' -k -no-pass -alt 'domainadmin@victim.domain'

I got a domainadmin.pfx and I'm ready to test it out.

When I do certipy auth -pfx domainadmin.pfx -dc-ip ip.of.domain.controller I get:

[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

Upon checking this repo's issues, I came across this one leading me to believe I can use this blog/tool to abuse this path via Linux, but from your blog it's my understanding that if the CA is fully patched, this is a dead end.

To further confuse me, this blog makes me think abuse still is possible, but this content looks to be specifically about abuse when you've obtained the cert for a domain controller (which I have not).

Would you point me in the right direction - just so I'm not chasing a dead end?

[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 domainadmin@victim.domain, 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

[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

[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.

[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.

[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]

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!

[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.