As the core of Windows enterprise networks, Active Directory, the service that handles user and computer authentication and authorization, has been well studied and probed by security researchers for decades. Its public key infrastructure (PKI) component, however, has not received the same level of scrutiny and, according to a team of researchers, deployments are rife with serious configuration mistakes that can lead to account and domain-level privilege escalation and compromise.
“AD CS [Active Directory Certificate Services] is Microsoft’s PKI implementation that provides everything from encrypting file systems, to digital signatures, to user authentication (a large focus of our research), and more,” researchers Will Schroeder and Lee Christensen from security firm SpecterOps said in a new report. “While AD CS is not installed by default for Active Directory environments, from our experience in enterprise environments it is widely deployed, and the security ramifications of misconfigured certificate service instances are enormous.”
How AD CS works
AD CS is used to set up a private enterprise certificate authority (CA), which is then used to issue certificates that tie a user or machine identity or account to a public-private key pair, allowing that key pair to be used for different operations, such as file encryption, signing files or documents and authentication. AD CS administrators define certificate templates that serve as blueprints to how certificates are issued, to whom, for what operations, for how long and what cryptographic settings they have.
In other words, like in HTTPS, a certificate that is signed by the CA is proof that the AD infrastructure will trust a particular public-private key pair. So, to obtain a certificate from AD CS, an authenticated user or computer, generate a key pair and send the public key along with various desired settings to the CA as part of a certificate signing request (CSR). The CSR will indicate the user identity in the form of a domain account in the subject field, the template to be used to generate the certificate, and the type of actions for which the certificate is desired, which is defined in a field called pKIExtendedKeyUsage (EKU).
After performing a variety of checks, including whether the user is allowed to request a certificate and under which conditions, the AD CS server will return the certificate signed by the enterprise CA. Even at first glance, it becomes clear that the checks and validations performed by the server are critical. Otherwise, an attacker who gains code execution with the privileges of a local account by exploiting some vulnerability or through malware can just request a certificate that allows authentication instead of dumping LSASS memory to extract account credentials. This is a common attack technique that defenders know well. Even worse, a certificate will remain valid even if the account password is later changed because an account compromise is detected or suspected. This means authentication certificates can offer attackers much better persistence than credential theft.
Abusing AD CS misconfigurations
While this type of abuse of AD CS can be obvious to defenders, more subtle attacks stem from various certificate template configuration options or combinations of options and are quite common based on SpecterOps’ findings. “Since beginning this research, we have analyzed many networks for these AD CS misconfigurations,” Schroeder and Christensen said in a newly released white paper. “In nearly every network so far, AD privilege escalation has been possible using this technique, and low-privileged users (e.g., members of the “Domain Users” group) have almost always had the ability to immediately compromise the Active Directory forest.”
The researchers have developed both AD CS auditing and attack toolkits based on their findings. The audit toolkit, written in PowerShell and dubbed PSPKIAudit, is already available, but the their two offensive tools, Certify and ForgeCert, will be released in early August during the upcoming Black Hat USA 2021 conference, to give enterprise security teams some time to prepare. It’s also worth noting that the SpecterOps paper does not cover only novel techniques or findings but is rather meant as a comprehensive collection of attacks against AD CS, some of which have been documented by other researchers in the past in specific contexts but which have now been expanded or automated.
Theft of existing certificates
“Setting up working Windows PKI infrastructure in an organization of any size is not the simplest task,” Schroeder and Christensen said. “If an organization has AD CS installed and configured (and they probably do), they had a reason to undergo the engineering effort. This means that if an enterprise CA exists, at least some AD users and/or computers likely have certificates issued to them, and some of these certificates likely will have an EKU permitting domain authentication.”
The two researchers document several locations where existing user or machine certificates are stored and the techniques that can be used to potentially extract them via the Microsoft Crypto APIs (CAPI and CNG) or the Data Protection Application Programming Interface (DPAPI). Sometimes certificate files can also be found directly on filesystems, as opposed to system stores, because they have been exported by administrators or users. The researchers found such certificates on network file shares, in administrators’ Downloads folders, in source-code repositories, on servers, and many other places.
The abuse can go both ways. Access to a user account can result in their certificate being stolen, but there is also a documented way to obtain a user’s NTLM hash by using a certificate via Microsoft’s implementation of the Kerberos protocol’s PKINIT. These certificate or credential theft attacks along with technical details for their implementation have been documented in the SpecterOps paper as THEFT1, THEFT2, THEFT3, THEFT4 and THEFT5.
Account persistence through certificates
As previously mentioned, a user or a computer can request a certificate that allows domain authentication from an enterprise CA if they have the permission to enroll and if a certificate template exists that provides such privileges. A template vulnerable to abuse would have the following properties:
- Is published for enrollment.
- Domain Users or another group the victim user is a member of are allowed to enroll. For computers or SYSTEM accounts the group is Domain Computers.
- Has any of the following EKUs which enable domain authentication or more: Smart Card Logon (1.3.6.1.4.1.311.20.2.2), Client Authentication (1.3.6.1.5.5.7.3.2), Any Purpose EKU (2.5.29.37.0), or has no EKU set which means the resulting certificate is treated as a subordinate CA certificate and can be used to issue certificates and impersonate any user and computer.
- Does not require manager approval or “authorized signatures” issuance requirements.
Two default certificate templates in AD CS called User and Machine meet these requirements. Furthermore, the enrollment privileges—who can request certificates—can be defined using two security descriptors, one per template and one for the enterprise CA itself, with the enterprise CA one superseding the template-specific ones. To complicate matters further, several enrollment settings can allow a user to request certificates: the Certificate-Enrollment extended right, the Certificate-AutoEnrollment extended right, all ExtendedRights and FullControl/GenericAll.
The CA certificate manager approval setting forces all certificate signing requests to be placed in a pending state for a certificate manager to approve them before issuance, while the authorized signatures setting requires secondary signatures to be present on the CSR before a certificate is issued based on it. This is to accommodate another functionality called enrollment agents, which are entities or processes that can request certificates on behalf of other users.
An attacker who obtains a certificate, either through theft or malicious enrollment, is limited by the validity period of that certificate. However, they can always issue a renewal request to extend the life of the certificate, which would not leave enrollment records on the server, in case such artifacts are being monitored. The SpecterOps researchers document these three certificate-based persistence techniques as: PERSIST1, PERSIST2 and PERSIST3 in their paper.
Domain escalation and persistence
The most severe certificate template misconfigurations are those that allow regular users to escalate their privileges and potentially become domain administrators. One such misconfiguration is if the template allows the use of subjectAltName (SAN) fields in CSRs.
SANs are common in HTTPS certificates, which AD CS supports, to have a single certificate that works for several domain names or subdomains of the same domain. That’s because in HTTPs the goal is to authenticate the server, which can host multiple domains, to the client. However, in certificates that allow client authentication, the subjects are users or computer accounts, so if arbitrary SANs are allowed, a requester can ask for a certificate that would allow them to impersonate any other user. There is a warning that appears when administrators try to enable such a vulnerable configuration, but it’s easy to overlook.
“If an administrator is unfamiliar with PKI, they very likely could click through this warning as they are battling to get things working,” the researchers said. “Duplicating a template that already exhibits the vulnerable settings also does not result in a warning. In addition, we suspect that when IT administrators create their own certificate templates, they may duplicate the default WebServer template that comes with AD CS. The WebServer template has the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag enabled and then if IT administrators add the “Client Authentication” or “Smart Card Logon” EKUs, the vulnerable scenario occurs without a warning from the GUI.”
Another issue related to the SAN use is the use of the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on the CA itself, which will allow all CSRs to have user-defined values in the subject alternative name field. It might also be possible for an attacker to abuse the ManageCA and the ManageCertificates rights, which correspond to the the “CA administrator” and “Certificate Manager” roles to enable this flag.
A separate misconfiguration that can lead to privilege escalation is when the template defines Any Purpose EKUs or has no EKU at all. This can result in certificates that can be used for any purpose or that function as subordinate CA certificates.
Other misconfigurations involve templates that include the Certificate Request Agent EKU (1.3.6.1.4.1.311.20.2.1) and allow enrollment from low-privileged users with no manager approval or additional signatures requirements. Another insecure combination of options is low-privileged users allowed to enroll, manager approval is disabled, the template schema is version 1 or is greater than 2 and specifies an Application Policy Issuance Requirement requiring the Certificate Request Agent EKU, the template defines an EKU that allows for domain authentication and enrollment agent restrictions are not implemented on the CA.
Templates can also be misconfigured at the access control level as objects in AD. For example, if the attacker can chain various accesses to a point that allows them to have “Full Control” or “Write” access in the certificate template, they can intentionally push misconfigurations to otherwise secure templates.
Furthermore, several AD objects outside of certificate templates and the certificate authority can impact the security of the entire AD CS system. According to the researchers these are: the CA server’s AD computer object, the CA server’s RPC/DCOM…
Active Directory Certificate Services a big security blindspot