Help understanding limitations of "KDC_ERR_PADATA_TYPE_NOSUPP"
See original GitHub issueHello!
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?
Issue Analytics
- State:
- Created a year ago
- Comments:14 (3 by maintainers)
Top GitHub Comments
Sure, thanks!
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?