Intro

Active Directory Certificate Services (AD CS) is used for public key infrastructure in AD environment. Although it isn’t installed by default, it is widely deployed when using this type of environment, as it provides many additional features to it, such as digital signatures, user authentication and even encrypting file systems.

As we can imagine, in order to manage all these certificates, this component integrates a Certificate Authority (CA), which is responsible for issuing, signing, managing and revoking certificates for systems, users, apps and more.

One interesting thing here is that these Enterprise CAs also provide certificate templates, which contain the default settings for the certificates issued. Examples of things set in these configurations are the certificate subject, validity, purpose, and its Extended Key Usage (EKU), authorizing certificate-based authentication to the AD for example.

This article will focus primarily on certificates that enable AD authentication, but keep in mind that there are attacks that go beyond just authentication.

Just a heads up:

  • This article will cover mostly the theory behind how AD CS works, for details over AD CS attacks, go to the next article;
  • A looot of the content that we’ll talk about here will be a direct or indirect quote from the SpecterOps paper about AD CS (link here).

Certificates

A certificate is an X.509-formatted digitally signed document used for encryption, message signing, and/or authentication. The dropdown below contains some of the various fields a certificate typically contains.

Some of the main certificate fields:

  • Subject - The owner of the certificate.
  • Public Key - Associates the Subject with a private key stored separately.
  • NotBefore and NotAfter dates - Define the duration that the certificate is valid.
  • Serial Number - An identifier for the certificate assigned by the CA.
  • Issuer - Identifies who issued the certificate (commonly a CA).
  • SubjectAlternativeName - Defines one or more alternate names that the Subject may go by.
  • Basic Constraints - Identifies if the certificate is a CA or an end entity, and if there are any constraints when using the certificate.
  • Extended Key Usages (EKUs) - Object identifiers (OIDs) that describe how the certificate will be used. Also known as Enhanced Key Usage in Microsoft parlance. Common EKU OIDs include:
    • Code Signing (OID 1.3.6.1.5.5.7.3.3) - The certificate is for signing executable code.
    • Encrypting File System (OID 1.3.6.1.4.1.311.10.3.4) - The certificate is for encrypting file systems.
    • Secure Email (1.3.6.1.5.5.7.3.4) - The certificate is for encrypting email.
    • Client Authentication (OID 1.3.6.1.5.5.7.3.2) - The certificate is for authentication to another server (e.g., to AD).
    • Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) - The certificate is for use in smart card authentication.
    • Server Authentication (OID 1.3.6.1.5.5.7.3.1) - The certificate is for identifying servers (e.g., HTTPS certificates).
  • Signature Algorithm - Specifies the algorithm used to sign the certificate.
  • Signature - The signature of the certificates body made using the issuer’s (e.g., a CA’s) private key.

The information included in a certificate binds an identity - the Subject - to the key pair. An application can then use the key pair in operations as proof of the identity of the user.

The Certificate Authority

CAs are responsible for issuing certificates. Upon its creation, the CA first needs to create its own private-public key pair and certificate that it will use when issuing certificates. The CA generates its own root CA certificate by signing a new certificate using its private key (that is, the root CA certificate is self-signed).

AD CS will set the certificate’s Subject and Issuer fields to the CA’s name, the Basic Constraints to Subject Type=CA, and the NotBefore/NotAfter fields to five years (by default). Hosts then add the root CA certificate to their trust store to build a trust relationship with the CA.

AD CS defines CA certificates the AD forest trusts in four locations under the container CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>, each differing by their purpose. We’ll take a look on the interesting things in the enumeration process, but for now it’s enough to know that we can enumerate a bunch of stuff via LDAP, including the environment’s enterprise CAs, root CA certificates, enabled certificate templates, certificates enabled for AD authentication…

Certificate Templates

AD CS Enterprise CAs issue certificates with settings defined by certificate templates. These templates are collections of enrollment policies and predefined certificate settings, containing things like the subject, validity, purpose, enrollment rights and a bunch of other things. Here is an example of available configurations for a template:

AD CS stores available certificate templates as AD objects with an objectClass of pKICertificateTemplate located in the CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM> container.

The pKIExtendedKeyUsage attribute on an AD certificate template object contains an array of OIDs enabled in the template. These EKU OIDs affect what the certificate can be used for and include things like the Encrypting File System (OID 1.3.6.1.4.1.311.10.3.4), Code Signing (OID 1.3.6.1.5.5.7.3.3), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Client Authentication (OID 1.3.6.1.5.5.7.3.2), and many more.

Here are the ones that enable certificate authentication (our abuse focus):

  • Client Authentication: 1.3.6.1.5.5.7.3.2
  • PKINIT Client Authentication: 1.3.6.1.5.2.3.4 - Not present in AD CS deployments by default and needs to be added manually, but it does work for client authentication too.
  • Smart Card Logon: 1.3.6.1.4.1.311.20.2.2
  • Any Purpose: 2.5.29.37.0

The Certificate Enrollment Process

To obtain a certificate from AD CS, clients go through a process called enrollment. Of course, not all users can enroll to any template they want, they need to have permission to do so, which is specified in the template’s configuration, or in the Enterprise CA itself. But if both the Enterprise CA’s and the certificate template’s security descriptors grant the client certificate enrollment privileges, the client can then request a certificate!

Here is an overview of how the process works:

certificate-enrollment-process

  1. The client first generates a public key and associated private key. The client creates a Certificate Signing Request (CSR) in which it specifies the public key and the name of the certificate template to be used.
  2. The client then signs the CSR with the private key and sends the CSR to the Enterprise CA using one of the enrollment protocols or interfaces (e.g., MS-WCCE, MS-ICPR, the certificate enrollment web service, etc.).
  3. The Enterprise CA then checks if the client has enrollment privileges at the CA level. If so, the CA looks at the certificate template specified in the CSR and verifies that the client can enroll in the given template by examining the certificate template AD object’s DACL. If the DACL grants the user the enrollment privileges, the user can enroll.
  4. The CA will create and sign a certificate based on the certificate template’s settings and return the signed certificate to the user.
  5. The client can now use the certificate within the purpose it’s allowed. If the certificate allows usage for client authentication for example, the user can start the Kerberos authentication flow using the certificate as the pre-authentication data, instead of its password hash. More on that in the following section.

One more detail worth mentioning here is that even if we have permissions to enroll, that doesn’t mean we will get the certificate right away. There are two main other issuance requirements that may be in place here.

  • The first is the “CA certificate manager approval” restriction, which will place our requests into the “Pending” list to be approved or denied before it is issued.
  • The second set of restrictions are the settings “This number of authorized signatures” and the “Application policy”. The former controls the number of signatures required in the CSR for the CA to accept it. The latter defines the EKU OIDs that that the CSR signing certificate must have.

So usually we’ll be looking to abuse certificates which do not have these restrictions in place either.

Subject Alternative Names (SANs)

A Subject Alternative Name (SAN) is an X.509v3 extension. When added to a certificate, it allows additional identities to be bound to a certificate beyond just the subject of the certificate. A common use for SANs is supplying additional host names for HTTPS certificates. For example, if a web server hosts content for multiple domains, each applicable domain could be included in the SAN so that the web server only needs a single HTTPS certificate instead of one for each domain.

This is all well and good for HTTPS certificates, but when combined with certificates that allow for domain authentication, a dangerous scenario can arise.

If an attacker can specify an arbitrary SAN when requesting a certificate that has an EKU enabling client authentication, and the CA creates and signs a certificate using the attacker supplied SAN, the attacker can become any user in the domain. For example, if an attacker can request a client authentication certificate that has a domain administrator SAN field, and the CA issues the certificate, the attacker can authenticate as that domain admin.

Using Certificates for Authentication

AD supports certificate authentication over two protocols by default: Kerberos and Secure Channel (Schannel). Because SChannel is rarely used and supported by tools, even inside Windows environments, we’ll be focusing on Kerberos in this article, for which the technical specification is defined in “[MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol”.

Okay, so the beginning of the flow was already explained, the user has a valid certificate issued and signed by the trusted CA that contains his public key, then it decides to use that for authentication. From that on it can start the PKINIT flow:

pkinit-comparison

What happens here is that the AS-REQ’s data will contain the user’s certificate, and the authenticator part of the request will be encrypted with the user’s private key. With that, the DC will perform a number of verification steps and if everything passes it issues the TGT!

Some of the verification steps done by the KDC. The KDC validates the user’s certificate (time, path, and revocation status) to ensure that the certificate is from a trusted source. The KDC uses CryptoAPI to build a certification path from the user’s certificate to a root certification authority (CA) certificate that resides in the root store on the domain controller. The KDC then uses CryptoAPI to verify the digital signature on the signed authenticator that was included in the preauthentication data fields. The domain controller verifies the signature and uses the public key from the user’s certificate to prove that the request originated from the owner of the private key that corresponds to the public key. The KDC also verifies that the issuer is trusted and appears in the NTAUTH certificate store.

With that in hand, we can go ahead and use this information to request a U2U TGS, which will contain the user’s NTLM hash.

Btw, I’m just doing a recap here, as the full explanation was already done in the Kerberos PKINIT article.

But you get the picture… if we abuse a certain vulnerability in AD CS and are able to retrieve a valid certificate for an arbitrary user… because of this flow, this means we can also use that to get his NTLM hash!!!! Getting a TGT for a user is something that might be useful, but his hash… things get a lot easier 😉.

References