Certificates
Last updated
Last updated
Active Directory Certificate Services (AD CS) is a customizable service for issuing and managing digital certificates. These digital certificates can be used for the authentication of computer, user, or device accounts on a network.
This configuration allows any domain user to request a certificate for any other domain user and use it for authentication.
To check if there is any vulnerable template, you can execute the following command.
If "<DOMAIN>\Domain Users" have enrollment rights, it means any domain user may request a certificate from this template.
These are the steps to exploit this vulnerability.
1. Request a certificate for a user with high privileges on the domain, then save the private key and certificate into a file like cert.pem.
2. Convert the cert.pem into pdf format.
3. Base64 encode the certificate to use it with Rubeus.
4. Request a TGT using the encoded certificate.
Useful for when you have the CA running on a web service and authentication via NTLM. In this case you can force a DC to authenticate to an attacker's machine and then use it to obtain a TGT.
AD CS services support HTTP enrolment methods and even includes a GUI. This endpoint is usually found at http[s]://<hostname>/certsrv
You cannot relay NTLM authentication back to the originating machine. We therefore wouldn't be able to relay a DC to a CA if those services were running on the same machine.
Another good way to abuse this primitive is by gaining access to a machine configured for unconstrained delegation.
These are the steps to exploit this vulnerability.
1. Execute ntlmrelayx pointing to the web CA on the attacker machine.
2. Force the DC to authenticate against the attacker machine. The certificate will appear on the ntlmrelayx tool.
You can use any of the programs on Unconstrained Delegation.
3. Use the S4U2Self to obtain the TGT.