This attack vector leverages excessive permissions on the CA object directly by abusing the combination of two specific security roles within the CA
Manage CA
This permission grants an excessive control over the CA object. A principal assigned this role can perform the following actions →
Modify the CA Configuration
e.g. Enable/Disable Templates, Set Policy Flags…
Assign CA Roles
Including Certificate Manager/Officer
Start/Stop the CA Service
Manage CA Security
Manage Certificates
Also known as Certificate Manager/Officer
Any principal assigned this role can approve or deny pending certificate requests and revoke issued certificates
The main point of this attack vector is that if an operator compromises a domain account with the Manage CA role assigned to it, it can grant itself the Manage Certificates permission/security role, so it becomes a new Certificate Manager/Officer in the CA
Having both permissions ( Manage CA and Manage Certificates), an operator can enable a Certificate Template that allows enrollee-supplied subjects and has a very broad Extended Key Usage ( EKU )( i.e. Including Client Authentication ), such as the SubCA certificate template
Then, we can request a certificate for the given template by providing a Certificate Signing Request ( CRS ) whose Subject Alternative Name ( SAN ) contains the UPN of the principal we want to impersonate
Since, by default, this template does not allow any enrollment from non-privileged users, we will have to approve our own certificate request by leveraging the recently assigned Manage Certificates security Role
This process basically allows an attacker to obtain a valid certificate for any existing domain principal
Let’s suppose that we compromise a domain user account which has excessive permissions over the CA object directly
We use certipy to enumerate this permissions and we see that the user account has been assigned the Manage CA security role
From here, we can leverage the given security role to grant ourselves the Manage Certificates permission
The latter make us a Certificate Manager/Officer, therefore we can approve or deny any certificate request, as well as revoke existing ones
Then, we have to look for a Certificate Template that has a broad EKU, which includes Client Authentication, and allows enrollee-supplied subjects, so we can specifiy the UPN of the principal we want to impersonate within the CSR’s SAN attribute( ESC1 )
To do so, we can leverage the Sub CA template, which is usually enabled by default. If not, since we have been assigned the Manage CA security role, we can enable it
Once we carry out the request submission, it will be denied but will generate a request ID
As mentioned, since we have the Manage Certificates security rol, we can approve our own certificate request and subsequently retrieve the certificate
To do so, we must save both the private key associated with the CSR and the Request ID
With the issued certificate, we can carry out several actions →
[*] Requesting certificate via RPC[*] Request ID is 22[-] Got error while requesting certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.Would you like to save the private key? (y/N): y[*] Saving private key to '22.key'[*] Wrote private key to '22.key'[-] Failed to request certificate
Important
Keep both the Request ID and the Private Key associated with the submitted CSR for further steps
[*] Retrieving certificate with ID 22[*] Successfully retrieved certificate[*] Got certificate with UPN 'administrator@DOMAIN.INTERNAL'[*] Certificate object SID is 'S-1-5-21-4078382237-1492182817-2568127209-500'[*] Loaded private key from '22.key'[*] Saving certificate and private key to 'administrator.pfx'[*] Wrote certificate and private key to 'administrator.pfx'
If the DC in question does not support PKINIT due to the absence of the Smart Card Logon Extended Key Usage ( EKU ) in its certificate, an operator could use the issued certificate to authenticate against LDAPs or LDAP with STARTTLS
Then, we could carry out specific actions depending on the privileges the principal in question has over the domain
For instance, if we leverage an ESC1 vector to obtain an arbitraty certificate whose SAN corresponds to the identity of a privileged domain user, such as the administrator account, we could grant ourselves FullControl over the latter