Introducing Active Directory Certificate Services
Table of Contents
This post introduces Active Directory Certificate Services (AD CS) topics: public key infrastructure (PKI), the Kerberos pre-authentication protocol PKINIT, Certificate Signing Requests (CSR), and templates. This overview provides a baseline for learning AD CS penetration testing.
PKI Review
AD CS is Active Directory’s public key infrastructure (PKI) implementation. A familiar PKI implementation is the HTTPS protocol and the trust established between a client browser and web server using SSL certificates. SSL certificates are signed by a Certificate Authority’s private key and include the web domain’s public key and information. Web browsers store most major CA public keys. A web browser can verify SSL certificates and CA private keys by checking against CA public keys stored in the browser. The SSL certificate also includes the web domain’s public key. The web domain’s public key is then used by the client browser to send a new client symmetric key to the web server and establish the HTTPS connection.
This common PKI example shows how PKI certificates can be used to establish trust and secure communications. AD CS uses PKI in a similar way. AD CS is a server role in Active Directory that can delegate and prove trust through certificates. AD CS provides a CA (root or subordinate) and many other features like Web Enrollment, for accessing the CA via a web browser, and Certificate Enrollment Web Service, which allows for users and computers to perform certificate enrollment. Certificates can be used in various ways, examples include client authentication, code signing, and smart card logon. Like SSL Certificates, AD CS certificates are X.509 certificates approved by a CA, signed by the CA’s private key, and include the public key of the certificate’s owner.
Kerberos Review
Before reviewing PKINIT, the pre-authentication mechanism for Kerberos’s PKI implementation, it is helpful to review the standard Kerberos authentication steps without certificates.
Kerberos’s has three principals- the Client, Server, and KDC- each have a long-term secret key which is shared with the Key Distribution Center (KDC):
Green: C- Client Secret Key (derived in part from the client’s username and password)
Yellow: S- Server Secret Key (for the Application Service the Client is requesting)
Blue: TGS- Ticket Granting Server (TGS) Secret Key
First, the client starts by sending an unencrypted request for a TGT (AS_REQ) to the Authentication Server, which is part of the KDC.
The Authentication Server verifies client/computer authentication and uses both the TGS secret key (blue) and client secret key (green) in its reply. The Authentication Server looks up the User ID from the cleartext AS_REQ and checks its own list of known users. If it is a valid known user, the KDC can use the corresponding client secret key (C, Green) to encrypt a session key (red R-1). The client can decrypt its own client secret key and access the session key (R-1). The client also receives the TGT that is encrypted by the TGS secret key (TGS, blue).
The client has now confirmed its identity to KDC and can use the TGT to request access to different services (requiring a new session key (R-2) and tickets (TGS tickets)). The initial authentication with PKINIT is a bit different.
PKINIT Overview
In the AS_REQ, the client sends a X.509 certificate that is signed by the CA, and includes the client’s public key, pk(C). The KDC trusts the certificate, verifies the client’s information and accesses the client’s public key, pk(C). The KDC can now use the client’s public key to see a list of the client’s requested encryption method options, like Diffie-Hellman or RSA.
The KDC responds back to the client using the agreed upon encryption method(Diffie-Hellman in the example below) and a TGT:
The session key (red, R-1) is encrypted with the public-key encryption algorithm (DH) and the TGS secret key encrypts the TGT (blue).
These initial PKINIT steps highlight the certificate exchange between a client and the KDC. Penetration testing AD CS typically centers around submitting X.509 certificates to the KDC to authenticate as a new elevated user.
Certificate Signing Request
AD CS normally runs on select domain controllers, but clients can also often use templates to request their own certificates. Clients send certificate signing requests (CSRs) to an enterprise CA. The Enterprise CA has a self-signed CA certificate that enables authentication and acts as the root of domain-based certificate authentication. After the CA receives the CSR it can then sign the issued certificates using the CA private key. This diagram from SpecterOps outlines the process for requesting a certificate:
1) Client generates public/private key pair
2) Client generates a CSR: This includes information about the Subject, who is requesting the certificate, and includes the certificate template.
3) The CA looks at the CSR and the template specified. The template is a blueprint of settings that the certificate will have when it is issued. The CA compares the CSR to what is on template.
4) If it is approved, the CA generates and signs the certificate using the CA private key.
5) The client can then put the certificate in the Windows Certificate store and use it.
Certificate Templates are AD objects. They are a blueprint of settings for a certificate. These templates include its lifetime, what it is used for, who can request it and key settings called Enhanced Key Usage (EKU). EKU define what the certificate can be used for. Some examples include Client Authentication, Code Signing, and Smart Card Logon. Certain EKUs can allow for Domain Authentication. Certificates also include a Subject Alternative Names (SANs) which allow additional identities to be bound to a certificate beyond the subject. SANs can be useful for binding one certificate to multiple identities. One example of this is using one SSL certificate for multiple web domains.
Targeting Templates
The SAN setting can be dangerous for domain authentication since Active Directory maps certificates to user accounts using SAN. In June 2021 Will Schroeder and Lee Christensen from SpecterOps released their whitepaper “Certified Pre-Owned: Abusing Active Directory Certificate Services”. Their whitepaper recognized that weak AD CS template configurations were a common issue in enterprise environments and could be exploited to elevate a Domain User to Domain Admin. They noted three requirements and misconfigurations to exploit certificate templates:
Requirements:
1) Low privilege user has to be able request a certificate (enrollment rights)
2) Manager approval is disabled
3) No “authorized signatures” are required
Key Misconfigurations:
1) An attacker can specify an arbitrary SAN when requesting a certificate
2) Certificate enables domain authentication
3) CA needs to create and sign a certificate using the attacker-supplied SAN
If these misconfiguration and requirements are met, an attacker can attempt to escalate privileges through various escalation scenarios described by Will Schroeder and Lee Christensen. Following their BlackHat talk, they released various AD CS tools including the defensive toolkit PSPKIaudit, along with offensive tools Certify and ForgeCert. Other common tools include Windows command-line tool certutil, Olive Lyak’s certipy, and dirkjanm’s PKINITtools.
Secured’s Targeting AD CS post will review key resources for targeting ADCS and demonstrate the ADCS privilege escalation attack ESC1.