Active Directory Certificate Services (AD CS) is a Microsoft product that performs public key infrastructure (PKI) functionality that provides for encrypting file systems and user authentication. AD CS integrates with Active Directory (AD) and enables the issuing of certificates, which can be use for authentication purposes. The information that is included in a certificate correlates with an identity, or subject, to a public/private key pair. An application can then use the keys to validate the identity of a user. Certificate Authorities (CAs) are responsible for issuing certificates.
As SpectreOps noted in their original post,
At a high level, clients generate a public-private key pair, and the public key is placed in a certificate signing request (CSR) message along with other details such as the subject of the certificate and the certificate template name. Clients then send the CSR to the Enterprise Certificate Authority (CA) server. The CA server then checks if the client can request certificates. If so, it determines if it will issue a certificate by looking up the certificate template Active Directory (AD) object specified in the CSR. The CA will check if the certificate template Active Directory object’s permissions allow the authenticating account to obtain a certificate. If so, the CA generates a certificate using the “blueprint” settings defined by the certificate template and using the other information supplied in the CSR, if allowed by the certificate’s template settings. The CA signs the certificate using its private key and then returns it to the client. The CAs issue certificates with settings defined by AD objects known as certificate templates. These templates are collections of enrollment policies and predefined certificate settings and contain things like:
How long is this certificate valid for?
What is the certificate used for?
How is the subject specified? and
Who is allowed to request a certificate?
There are several escalation, or ESC, attacks that are known today. The most common ESC attacks that RSM testers exploit are ESC1, ESC4 and ESC8.
For ESC1, “Misconfigured Certificate Templates”, an attacker can specify a different Subject Alternative Name (SAN). By default, during certificate-based authentication, certificates are mapped to AD accounts based on a user principal name (UPN) specified in the SAN. If an attacker can specify an arbitrary SAN when requesting a certificate that enables domain 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, an attacker with a valid domain account can target a Domain Administrator account for the attack. The attacker requests a certificate and specifies the SAN as a Domain Administrator account and retrieves a certificate for that account. With the certificate, the attacker can then request the Domain Administrators Ticket Granting Ticket and subsequently, the NT hash of the account. The NT hash can be used to successfully authenticate to the domain controller.
ESC4 refers to misconfigured ACL’s (Access Control Lists) which grant members of Authenticated or Domain Users groups Full Control permissions over a certificate template. When users have full control over a certificate template, the users can change the properties of the certificate and make it vulnerable to ESC1. As seen above, if a certificate template is vulnerable to ESC1, an attacker can request a certificate as a Domain Administrator and authenticate to the Domain Controller with those Domain Administrator privileges.
For ESC8, “NTLM Relay to AD CS HTTP Endpoints”, an attacker identifies a CA that supports HTTP-based web enrollment to request a certificate. Like other NTLM relay attacks, an attacker needs to relay authentication from one system to the CA. For instance, an attacker can coerce a Domain Controller’s authentication and relay the authentication to the exposed HTTP endpoint on the CA to request a client authentication certificate. The attacker can then use the certificate to request the TGT for the Domain Controller’s computer account and subsequently, request the NT hash to successfully authenticate against itself.
There are several other ESC techniques, but the two listed above are the most common attacks we have exploited. With the above mentioned misconfigurations, an attacker only needs to have a valid account on the environment to essential impersonate any domain account, such as a Domain Administrator, to compromise the environment. With most Domain Administrator accounts having unlimited access on an environment, an attacker can then search for sensitive information, such as Social Security Numbers, Personal Identifiable Information, or documents containing account information, or cause disruption to systems within the environment.
This article was written by Miguel Silvestre, an RSM Cyber Testing Senior Associate with five years of experience in penetration testing.
