-
Notifications
You must be signed in to change notification settings - Fork 13.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Issuing Certificates With NTDS_CA_SECURITY_EXT #18078
Conversation
Luckily we can also do this with the `icpr_cert` module. We just need to also set the `ALT_SID` and `ALT_UPN` options to | ||
specify who we would like to authenticate as instead. Note that this only works with certificate templates that are | ||
vulnerable to ESC1 due to having the `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` flag set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically setting ALT_SID isn't always required. It's required today on fully patched servers with the registry key set to require the strong mapping and will be required by default in the future. To avoid providing an abundance of details, this simply mentions that it should be set. If the SID isn't required because the server isn't patched, then including it is harmless.
346bc31
to
238118e
Compare
Neat! Thank you sir. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of small suggestions!
66d2477
to
1823801
Compare
Looks good to me! Testing with ALT_SID set
Testing without ALT_SID
|
Release NotesThis adds support to the |
This adds support to the
icpr_cert
module to issue certificates for an explicit SID by specifying it within the NTDS_CA_SECURITY_EXT. Prior to this PR, if the server added this extension, it would be parsed using#get_cert_ext_property
but it couldn't be included in the request. Including it in the request is required now when targeting servers with the KB5014754 patch applied and theStrongCertificateBindingEnforcement
REG_DWORD value set to 2. Including it in the request will be required by default in November of this year when Microsoft changes the default value of this from 1 to 2. The default value is used when the item is not present in the registry.Making these changes now ensures that Metasploit is ready for this change and that users will continue to be able to exploit ESC1 just with the extra step of needing to find and set the SID. Users can get the SID using the ldap_query module. Metasploit also currently supports exploit ESC2, ESC3 and ESC4. When I tested my fully patched Server 2019 instance, certificates that were requested using
ON_BEHALF_OF
andPFX
would include the SID in their response. ESC4 makes a certificate template vulnerable to ESC1 which will also continue to work. This means our currently supported attacks of ESC1-4 will continue to work by default after November.For additional context on these changes, see the following references which I found helpful:
PKINIT Changes
The AS-REQ request used as part of PKINIT functionality had to be updated in order to work with the new certificate. The underlying issue was in the data that was being signed which caused the signature validation to fail and an integrity error to be raised.
Verification
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\Kdc /v StrongCertificateBindingEnforcement /t REG_DWORD /d 2
ALT_SID
datastore option to the SID of the target accountauxiliary/admin/kerberos/get_ticket
moduleKDC_ERR_CERTIFICATE_MISMATCH
auxiliary/admin/kerberos/get_ticket
moduleDemo