GitHubPsMapExec

ESC7

Finishing adding windows command for appending Manger rights

Add mitigations

Description

ESC7 occurs when access is obtained to a principal within the domain that has either of the following rights:

  • ManageCA (CA Manager)

  • ManageCertificates (CA Officer)

ManageCA

The ManageCA right grants a principal the ability to modify a CA's configuration, primarily through the ICertAdminD2::SetConfigEntry method. This method enables changes to the CA's persisted data, including the Config_CA_Accept_Request_Attributes_SAN setting. This setting, a boolean value, controls whether the CA accepts request attributes, particularly those defining the Subject Alternative Name (SAN) for issued certificates.

Having this capability means an attacker could manipulate the EDITF_ATTRIBUTESUBJECTALTNAME2 flag, potentially enabling ESC6 attacks.

Manage Certificates

If we gain control over a principal with the ManageCertificates right on the CA, we can remotely approve pending certificate requests, effectively bypassing the CA certificate manager approval requirement.

This enables abuse of the default SubCA template, which has the EnrolleeSuppliesSubject flag enabled. While this template is typically restricted to Domain and Enterprise Administrators, leveraging the ManageCertificates right allows us to force approval of certificate requests from any user. This, in turn, facilitates escalation via ESC1.

Requirements for attack path (Manage CA)

  • Access to a principal with ManageCA rights

Requirements for attack path (ManageCertificates)

  • Access to a principal with ManageCertificates rights

Manage CA

If pursuing the Manage CA attack path we can remotely flip the value of the flag EDITF_ATTRIBUTESUBJECTALTNAME2 in order to make the Certificate Authority vulnerable to ESC6 attacks. However, this requires the ability to stop and restart the certsvc service on the Certificate Authority which would indicate generally that we would also need to have compromised the Certificate Authority with a privileged or local administrator user.

If this attack path is viable the following command can be used to flip the EDITF_ATTRIBUTESUBJECTALTNAME2 flag to make the CA vulnerable.

Then stop and restart the service.

At which point follow the steps provided in ESC6.

ESC6

If we have access to a principal which has "Manage CA" rights but does NOT have "Manage Certificate" rights, we can simply use "Manage CA" to add the "Manage Certificate" to the same principal where we can then prform the "Manage Certificates" attacks described further within this document.

Linux

Windows

Linux - Manage Certificates

In this given scenario the following are true;

  • We have "Manage Certificate" rights over the CA

  • We do NOT have "Manage CA" rights over the CA (attack is still valid if we do have this)

  • There is an ESC1 template which requires Manager Approval

  • We have enrollement rights to the template

Under normal circumstances templates vulnerable to ESC1 can simply be issued and expoited by any user that has enrollement permissions. In this scenario, the organization has enabled Manager Approval on the certificate to mitigate ESC1 attacks. However, as we have access to a user with "Manage Certificate" rights over the CA we can simply approve these requests.

This example shows how ESC1 could be exploited when Manager approval is required. This attack is not limited to ESC1 and can be used on any certificate based attack which is vulnerable but requires manager approval.

Issue a request for the ESC1 template as shown below. In the example below we are using an unprivileged user to perform the request, ensuring we save the private key.

As expected, the request is denied and put on "hold" due to requiring manager approval before being issued. Using Moe, our user with "Manage Certificate" rights we can approve the certificate request.

Once approved, we can use this to authenticate with the certificate and obtain the domain administrator NTLM hash.

Windows - Manage Certificates

In this given scenario the following are true;

  • We have "Manage Certificate" rights over the CA

  • We do NOT have "Manage CA" rights over the CA (attack is still valid if we do have this)

  • There is an ESC1 template which requires Manager Approval

  • We have enrollement rights to the template

These are some additional requirements needed for when performing this attack from Windows;

  • Local administrator rights are required if RSAT is not installed

Install RSAT if not installed

Then install the PSPKI PowerShell module.

Under normal circumstances templates vulnerable to ESC1 can simply be issued and expoited by any user that has enrollement permissions. In this scenario, the organization has enabled Manager Approval on the certificate to mitigate ESC1 attacks. However, as we have access to a user with "Manage Certificate" rights over the CA we can simply approve these requests.

This example shows how ESC1 could be exploited when Manager approval is required. This attack is not limited to ESC1 and can be used on any certificate based attack which is vulnerable but requires manager approval.

Issue a request for the ESC1 template as shown below. In the example below we are using an unprivileged user to perform the request, ensuring we save the private key.

Using Certify, conduct the initial request

From the request output we can see the certificate has been set to "Pending" with a request ID of 65. Same the Private key output into cert.pem.

Whilst operating as a user that possess the "Manage Certificates" right, We can use PSPKI to approve the certificate.

Next, we download the certificate with Certify, ensuring we specify the correct request ID.

Take the private key and certificate output and place them into seperate files.

Then merge them together with certutil to create a .pfx file.

Use the converted certificate file with Rubeus to either request a NTLM hash or a Kerberos TGT.

Last updated