You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since then, on up-to-date machines, typically trying to exploit ESC8 or ESC11, either I use certipy relay to replay a DC (-template DomainController) or a normal server (-template Machine), I obtain the pfx, but I get a warning Certificate has no object SID. Then trying to use this pfx with certipy auth I get 2 errors: Name mismatch between certificate and user 'edited$' and Verify that the username 'edited$' matches the certificate DNS Host Name: EDITED.acme.local.
Looking at the source code of certipy it's mapped to the error code KDC_ERR_CLIENT_NAME_MISMATCH.
("Name mismatch between certificate and user %s"%repr(username))
Which is also the same error code I get if I directly use gettgtpkinit from impacket (cf. #34 (comment)).
I tried forcing the SID with -sid for certipy relay, I saw it's embedded in the CSR, but still have the same issue with the resulting PFX.
In the Microsoft KB they say that before this KB:
certificate-based authentication would not account for a dollar sign ($) at the end of a machine name.
So as far as I understand it seems focus to prevent machine account being relayed to AD CS for various abuse.
Since it was enforced 5 months ago and certipy was last updated 7 months ago, I wanted to know if someone was successfully able to bypass this restriction since November 2023 using certipy to exploit ESC8 or ESC11 successfully?
I also noticed that the following call to create_csr() was missing alt_sid=self.adcs_relay.sid, I don't know if it's intentional or not.
In the 2nd part, as we generated the certificate after the KB was installed, the SID in the certificate must correspond to the SID of the requested user, except that the SID is empty in the certificate we retrieved from certipy relay.
The Continued Attack Vectors Post KB5014754 chapter is interesting too.
More details here: How to Add the objectSID Attribute to a Certificate Manually.
Since then, on up-to-date machines, typically trying to exploit ESC8 or ESC11, either I use
certipy relay
to replay a DC (-template DomainController
) or a normal server (-template Machine
), I obtain the pfx, but I get a warningCertificate has no object SID
. Then trying to use this pfx withcertipy auth
I get 2 errors:Name mismatch between certificate and user 'edited$'
andVerify that the username 'edited$' matches the certificate DNS Host Name: EDITED.acme.local
.Looking at the source code of certipy it's mapped to the error code
KDC_ERR_CLIENT_NAME_MISMATCH
.Certipy/certipy/commands/auth.py
Lines 366 to 368 in 2780d53
Which is also the same error code I get if I directly use
gettgtpkinit
from impacket (cf. #34 (comment)).I tried forcing the SID with
-sid
forcertipy relay
, I saw it's embedded in the CSR, but still have the same issue with the resulting PFX.In the Microsoft KB they say that before this KB:
So as far as I understand it seems focus to prevent machine account being relayed to AD CS for various abuse.
Since it was enforced 5 months ago and certipy was last updated 7 months ago, I wanted to know if someone was successfully able to bypass this restriction since November 2023 using certipy to exploit ESC8 or ESC11 successfully?
I also noticed that the following call to
create_csr()
was missingalt_sid=self.adcs_relay.sid
, I don't know if it's intentional or not.Certipy/certipy/commands/relay.py
Lines 556 to 560 in 2780d53
As AD CS is very complex, and I'm far for mastering it, I would appreciate any pointer.
The text was updated successfully, but these errors were encountered: