Simple, Practical Security Guidance for AD CS

In 2008, Microsoft released the Active Directory Certificate Services(AD CS) feature to allow Administrators to manage their own Public Key Infrastructure and their Remote Authentication Dial-In User Service(RADIUS). This paved the way for 802.1x authentication using Extended Authentication Protocols(EAP) that will provide a more secure network using digital certificates to authenticate the enrolled user, device, and group policies to achieve enhanced security practices. However, AD CS has been commonly found to be a challenging daily effort for administrators to ensure a secure and efficient environment. To achieve authentication, authorization, and accounting of the domain directory, client, and work devices. Domain administrators require the proper network infrastructure, a Certificate Authority, a subordinate CA that issues certificates, a Certificate Store, and a Certificate Database. These lead to many complexities, including maintenance, setting configurations, and policy governance. Not following the recommended configurations or policies can lead to security vulnerabilities; however, in 2021, Specterops Cyber Security released its article covering the abuse of AD CS and determined that offensive and defensive tactics were not explicitly covered by the Red and Blue teams’ communities. In their white paper to raise awareness to assist admins with their networks, they have found that despite its strong network security capabilities through digital certificates, network segmentation, and permission-level access, Active Directory Certificate Services are still very much vulnerable to black hat attacks. This article is an examination of those found vulnerabilities and was written in hopes of raising awareness for those who are currently looking for any needed patches and what defensive enhancements or policies domain administrators should implement to prevent the domain’s PKI from being compromised or combat current vulnerabilities due to experiencing a recent attack.

Defensive Gaps and Challenges

Addressing security concerns in Active Directory Certificate Services (AD CS) presents challenges and complexities. While acknowledging their efforts in coverage, there is an anticipation of gaps in preventative measures and the likelihood of discovering new attacks against AD CS in the future. Detecting requested certificates proves difficult. Exposes limitations in existing event IDs for tracking such requests. There is a need for Microsoft to provide detailed and security-focused event auditing, suggesting improvements like incorporating template information into events for better correlation. Furthermore, it would be beneficial to have enhancements in event logs, such as including backups and additional contextual information within backup events. One particular challenge lies in detecting the usage of forged certificates following the theft of a Certificate Authority key, emphasizing the hope for detection approaches to be developed in the future. To mitigate the exposed vulnerabilities, we will cover preventive measures to safeguard the network from several attacks hackers can implement to compromise it. Below, you will find the attacks that hackers will carry out, which will be mentioned throughout the article.

Preventive Guidance

A hacker can use four attacks to compromise the entire ad cs system. These attacks are Domain Persistence, Domain Escalation, Account Persistence, and Certificate Theft. Each of these attacks includes a variety of ways that attackers may carry out. There are eight different ways to prevent these attacks. Below, you will find the attacks that hackers will carry out, which will be mentioned throughout the article. Implementing this preventive guidance will help mitigate the security risk to a minimum. Account Persistence

• • PERSIST1- Account persistence via requests for new authentication certificates for a user

• • PERSIST2- Account persistence via requests for new authentication certificates for a computer

• • PERSIST3- Account persistence via renewal of authentication certificates for a user/computer

Certificate Theft

• • THEFT1- Exporting certificates and their private keys using Window’s Crypto APIs

• • THEFT2- Extracting user certificates and private keys using DPAPI

• • THEFT3- Extracting machine certificates and private keys using DPAPI

• • THEFT4- Theft of existing certificates via file/directory triage

• • THEFT5- Using the Kerberos PKINIT protocol to retrieve an account’s NTLM Hash

Domain Escalation

• • ESC1- Domain Escalation Via No Issuance Requirements + Enrollable Client Authentication/Smart Card Logon OID templates + CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT

• • ESC2- Domain Escalation Via No Issuance Requirements + Enrollable Any Purpose EKU or No EKU

• • ESC3- Domain Escalation Via No Issuance Requirements + Certificate Request Agent EKU + No Enrollment Agent Restrictions

• • ESC4- Domain Escalation Via Misconfigured Certificate Template Access Control

• • ESC5- Domain Escalation Via Vulnerable PKI AD Object Access Control

• • ESC6- Domain Escalation Via the EDITF_ATTRIBUTESUBJECTALTNAME2 setting on CAs + No Manager Approval + Enrollable Client Authentication/Smart Card Logon OID templates

• • ESC7- Vulnerable Certificate Authority Access Control

• • ESC8- NTLM Relay to AD CS HTTP Endpoints

Domain Persistence 

• • DPERSIST1- Domain Persistence Via Certificate Forgery With Stolen CA Private Keys

• • DPERSIST2- Domain persistence Via Certificate Forgery From Maliciously Added Root/Intermediate/NTAuth CA certificates

• • DPERSIST3- Domain Persistence Via Malicious Misconfigurations That Can Later Cause A Domain Escalation

Treat CA’s as Tier 0 Assets

Regarding network security tactics, assigning a level of importance to Certification Authority (CA) servers as domain controllers is crucial. This ensures that CA servers receive protection against threats such as Domain Persistence attacks by certificate forgery with stolen CA private keys or trusting rogue CA certificates via certificate forgery with maliciously added root/intermediate/NTAuth CA certificates. Despite being of obvious importance, many organizations need to pay more attention to the significance of securing Certification Authorities (CAs) in real-world assessments. This emphasis goes beyond the root CA and extends to subordinate CAs recognizing their role in domain authentication. To ensure protection, measures should be taken to secure appliances or hosts that possess CA certificates. In this regard, the article suggests using tools like the PSPKIAudit PowerShell toolkit or Certify to identify and address issues related to CA architecture.

Harden CA Settings 

Organizations should conduct audits to enhance security and mitigate potential threats. Significantly strengthening settings on their Enterprise Certification Authorities (CAs) to prevent Domain Escalation attacks 6 and 7 via the EDITF_ATTRIBUTESUBJECTALTNAME2 flag being set on the Certificate Authority and Vulnerable Certificate Authority Access Control. To avert a Domain Escalation scenario from occurring, one specific setting that needs attention is turning off the “EDITF_ATTRIBUTESUBJECTALTNAME2” flag, as its presence within an environment can potentially allow unauthorized users to elevate their privileges to the domain admin level. Alternatively, if there is a need to retain this flag, it is recommended to enable manager approvals for certificate templates of domain authentication.

Moreover, organizations should tightly control enrollment agents using tools like the Certificate Authority MMC snap-in and appropriately restrict access rights of CA servers through auditing and limiting permissions for actions such as issuing and managing certificates to prevent Escalation 7, Vulnerable Certificate Authority Access Control. An additional precautionary measure is that the organization may consider removing “Request Certificates” permission from groups like Domain Users at the CA level or restrict it at the template level to minimize escalation scenarios.

Audit Published Templates 

Domain Escalation entails eight scenarios, and auditing published templates will prevent Escalation scenarios 1,2,3,4,6 and 7. In the context of Certificate Enrollment, administrators add the names of certificate templates to the certificate templates attribute of the AD object for an Enterprise CA. Information can be accessed through the Certificate Authority MMC snap-in (certsrv.msc), which allows administrators to see a list of published templates. This can help prevent Domain Escalation attacks for Misconfigured Templates and Vulnerable Access Controls. Alternatively, commands like Certify.exe and Certutil.exe can also be used to find and list published templates for an Enterprise CA. To enhance security, administrators must regularly remove unused templates from being published on all CAs in the environment to improve security. This practice helps minimize vulnerabilities and reduces the chances of misconfigurations.

Harden Certificate Template Settings

To prevent Domain Escalation attacks 1 through 4, administrators should look to harden their Certificate Template Settings to defend against certificate requests for unauthorized purposes from vulnerabilities such as enrollment agent templates, subject alternative names, and other certificate templates. Administrators can use PowerShell executables such as Invoke PKIAudit, Certify.exe, and certutil.exe to assess certificate template settings and identify vulnerabilities. Specifically, there are mitigation options for misconfigured templates that allow Subject Alternative Name (SAN) specification and domain authentication. Hardening Certificate Template Settings eliminates Domain Escalation attacks against misconfigured template scenarios one through four. This includes removing the “Supply in Request” setting for templates or enabling certificate approvals. Administrators can also configure authorized signatures under “Issuance Requirements” to restrict CSR signing. If it is necessary to have the “Supply, in Request” setting enabled, it is vital to follow Microsoft’s guidance and ensure that enrollment privileges are limited to controlled groups. It is essential to conduct audits on the write access permissions of template security descriptors to prevent attackers from exploiting vulnerabilities through template reconfiguration. When analyzing enrollment permissions, it is crucial to consider the Enhanced Key Usage (EKU) and Application Policies to limit privileges to groups. Templates that have EKUs should be accessible only by privileged groups, while EKUs that enable domain authentication should be reviewed for necessity and appropriate restrictions.

Audit NTAuthCertificates

To ensure authentication to Active Directory (AD) in the context of Kerberos Authentication and the NTAuthCertificates Container, administrators should review and manage the CA certificates stored in the NTAuthCertificates AD object to prevent Domain Persistence attacks by trusting rouge CA certificates. Tools like Certify, certutil, or MMC can be used to view these certificates. If your organization does not use smart card authentication and does not require certificate authentication to AD, it is advised to consider removing all certificates from the object. This helps prevent AD authentication using certificates. You can delete these certificates either by using certutil.exe or through the pkiview.msc interface. Another option is to utilize the PSPKI PowerShell module, which allows you to list and remove certificates from the NTAuthCertificates object based on their thumbprints.

Secure Certificate Private Key Storage

Securing Certificate Private Key Storage is a way to prevent Credential Theft attacks via exporting certificates and their private keys using Windows Crypto APIs and Account Persistence attacks via the request for new authentication certificates for a user. Organizations are encouraged to protect their Certification Authority (CA) keys at a hardware level to enhance security using the Data Protection API (DPAPI) technology. Microsoft’s “Securing PKI: Protecting CA Keys and Critical Artifacts” documentation guides migrating from software keys to hardware security modules (HSMs), a recommended best practice. While Microsoft’s Credential Guard may be mentioned as a solution for securing certificates, its effectiveness against DPAPI-related risks remains uncertain. Enabling Credential Guard is still recommended due to its benefits in protecting credentials, but administrators should be cautious of its compatibility issues with the EAP- PEAP-MSCHAPV2 network protocol. To ensure the security of keys on workstations and servers, it is recommended to use Trusted Platform Module (TPM) protection. By enabling certificate TPM attestation in the environment, you can ensure that Active Directory Certificate Services (AD CS) only accepts certificates with TPM-protected keys.

Enforce Strict User Mappings

Enforcing Strict User Mappings will help prevent Domain Escalations attacks in scenarios 1,2 and 6. This approach to user mappings during certificate authentication in Active Directory (AD) involves disabling Subject Alternative Name (SAN) user mapping by modifying registry keys and, in the domain controllers registry, setting the DWORD value of UseSubjectAltName to 0 at HKLM\SYSTEM\CurrentControlSet\Services\Kdc forces explicit mapping during Kerberos authentication. This prevents using certificates with SANs and avoids specific errors in Kerberos authentication. To altogether disable SAN user mapping for SChannel, which supports certificate-based authentication, organizations should adjust the CertificateMappingMethods registry value at HKLM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. Specific bitmask values like SP_REG_CERTMAP_SUBJECT_FLAG and SP_REG_CERTMAP_ISSUER_FLAG control this setting. Setting the key to 0x1 or 0x2 effectively blocks SANs in SChannel authentication. It may require investigation to confirm its effectiveness. To enhance security measures, organizations can utilize these keys to limit the types of certificate authentication allowed, even though they may not entirely prevent it.

Harden AD CS HTTP Endpoints

Hardening AD CS HTTP Endpoints will help prevent NTLM Relay to AD CS HTTP endpoint attacks, Domain Escalation scenario 8. IT administrators can identify enabled HTTP endpoints by examining CA servers’ AD CS server roles. Checking access logs in IIS, where the AD CS HTTP endpoints are hosted, can provide insights into endpoint usage. If these endpoints are necessary, enforcing HTTPS access and restricting NTLM authentication is recommended. Potential actions include:

• • Disabling NTLM at the host and IIS levels or if NTLM needs to be retained

• • Implementing HTTPS

• • Enabling Extended Protection for Authentication.

If the vulnerability persists, organizations are encouraged to contact Microsoft representatives for assistance in addressing the insecure default configuration; however, direct servicing is currently not scheduled. Following all these preventive guidelines will assist immensely with securing the network infrastructure. It should be noted that it won’t make the domain immune to black hat activity, as there are many ways to compromise an enterprise’s network without attacking the PKI.

Detective Guidance

Monitoring is another essential component of the mitigation of attacks against AD CS. Through monitoring, auditing, and using honey credentials, domain administrators can locate misconfigured templates, CA settings, or over permissive user accesses and fix them before any incident occurs. Below are seven different methods found by SpecterOps to implement defensive protocols for Detective Guidance.

Monitor User/Machine Certificate Enrollments 

Monitoring User and Machine Certificate Enrollments will assist in detecting activities of Domain Escalation scenarios 1,2,3,4 and 6; it will also benefit Domain Persistence 1 and 2. Whenever an account requests a certificate,

• • Event ID 4886 is generated by the Certification Authority (CA), indicating that a certificate request has been received. Subsequently, when the CA issues the certificate

• • Event ID 4887 is created to confirm that the approval and issuance of the certification have taken place. These events provide information to users, such as user context, DNS hostname, and request time. However, they only include some details in Certificate Signing Requests (CSRs)

The Windows event log does not reveal all the attributes or extensions of certificates, which could lead to user impersonation and privilege escalation. Fortunately, the Certificate Authority (CA) stores information about CSRs and certificates in its database. Although Microsoft has yet to provide a way to access this information in time programmatically, tools like certutil.exe and PSPKI can be used for querying the CAs database. Certutil.exe provides insights into certificates, including submission date, CSR subject, public key details, attributes, and certificate extensions. PSPKI offers PowerShell auditing capabilities through tools like PSPKIAudit that enhance machine access to this information. These tools greatly assist detection engineers and incident responders.

Monitor Certificate Authentication Events

Monitoring Certificate Authentication Events will assist in detecting AD CS attacks, Certificate Theft via NTLM Credential Theft via PKINIT, Domain Persistence scenarios 1 and 2, and Domain Escalation attacks 1,2,3,4,5,6. Both Kerberos (via PKINIT) and Schannel authentication provide support for certificate-based authentication, and keeping an eye on the logon events using these protocols can help spot any activity in an environment. In the case of Kerberos, when a user authenticates with a certificate, the domain controller generates Event ID 4768, indicating a request for an authentication ticket (TGT). This event includes fields called “Certificate Information” that contain details about the issuer, serial number, and thumbprint of the authenticating certificate. To identify the usage of PKINIT, it is essential to establish a baseline for behavior and set up alerts for any anomalies. For SChannel authentication, various events are generated by the domain controller when a client undergoes authentication. During the S4U2Self process, Event ID 4769 is created to request a Kerberos service ticket. Subsequently, Event ID 4648 signifies an attempt to log in using credentials, while Event ID 4624 indicates a login with Kerberos as the Authentication Package and Schannel as the Logon Process Name. To detect SChannel authentication reliably, monitor the Logon Process field in Event ID 4624 for instances where its value is set as “Schannel.”

Monitor Certificate Authority Backup Events

Monitoring your Certificate Authority backup events will help detect vulnerabilities of stolen CA certificate forgeryTwo audit events within AD CS pertain to backing up a Certificate Authority through certsrv.msc: Event ID 4876 denotes when “Certificate Services backup started, “while Event ID 4877 signifies when “Certificate Services backup was completed.” However, these events only occur when you backup the database, including the database log, private key, and CA certificate. If you only back up the CA key, no logs will be generated. When you back up the key and CA certificate together, additional audit events take place:

• •  Event ID 5058. Key File Operation: This event shows who performed the backup, the name of the CA, the type of MachineKey used, and the process (e.g., mmc.exe) that exported the DPAPI encrypted file.

• •  Event ID 5061. Cryptographic Operation: Similar to Event ID 5058. With detailed information. It indicates a user opening the CAs key.

• •  Event ID 5059. Key Migration Operation: Similar to Event ID 5058. With an “Export of key” specified in the operation field.

These events provide details about operations related to files, cryptographic operations, and key migration during the backup process.

Monitor Certificate Template Modifications

Monitoring these Certificate Modification events and implementing SACLs makes it possible to detect and track any modifications made to certificate templates within AD CS. Keeping track of the following changes to certificate templates in Active Directory Certificate Services (AD CS) is essential in improving the overall security and detecting Domain Escalation through Vulnerable Certificate Template Access Control and Account Persistence via Certificate Renewal. Here are the following events that will uncover unwarranted modifications.

• • Event ID 4662: (“An operation was performed on an object”) captures details like the user for the action and the type of access used. This information helps with tracking changes made to certificate templates. This is also triggered when the user edits the object using LDAP.

• •  Event ID 4899: (“A Certificate Services template was updated”) is generated whenever attribute changes exist in the certificate template AD object.

• • Event ID 4900: (“Certificate Services template security was updated”) is generated whenever the security descriptor of the certificate template AD object changes.

It’s important to note that these events are unsuitable for real-time detection as they only occur when modifications are made to the template AD object, followed by an enrollment process. Another approach worth considering is applying Security Auditing Control Lists (SACLs) to the template AD objects. This allows for monitoring types of access such as Write, Delete, WriteDacl, and WriteOwner.

Detecting Reading of DPAI-Encrypted Keys 

To enable auditing, Windows endpoints mainly focus on Data Protection API (DPAPI) master files and DPAPI encrypted private vital files. Windows system access control lists (SACLs) can effectively assist in monitoring Certificate Theft attacks via DPAPI and Machine and User Certificate theft attacks. It also helps detect Account Persistence attacks of Active User Credential Theft via Certificates. It is assumed that SYSTEM processes are the ones accessing these files, although there might be a need for more confirmation data. Implementing SACLs helps identify when a process uses Windows APIs to read the files, the default approach employed by tools like SharpDPAPI and Mimikatz. While this method can locate theft involving user/machine certificate and certificate authority private keys, it may not detect techniques such as Mimikatz manipulating CryptAPI (CAPI), Cryptographic Next Generation (CNG), or other file reading methods. Utilizing SACLs offers a way to augment security by monitoring access to files and detecting unauthorized access or attempted theft.

Use Honey Credentials 

Using Honey Credentials is a strategy where network defenders can anticipate attackers searching for certificates and private key files in THEFT4 attacks.Hackers are driven by motivations when trying to compromise a network. One of their goals is to locate certificates and private key files, which provide them with advantages such as assuming the identity of another user, creating certificates, carrying out man-in-the-middle attacks, or signing code using trusted certificates. To counter these attacks, defenders can employ a strategy involving the creation of “honey certificates.” These deceptive certificates are strategically placed in locations that attackers frequently search for. These locations may include file shares, Windows credential stores, or specific administrative folders on users’ machines. Defenders can implement Security Access Control Lists (SACLs) on honey certificates to enhance the effectiveness of detection measures. This allows them to monitor access attempts to these files or instances where the certificate is utilized. For example, they can track activities such as file signing or when a user logs in using the certificate. For an implementation scenario, detection engineers could generate an account and create a client authentication certificate for that account. The certificate and its corresponding key would then be exported as a.pfx file, strategically placed where potential attackers might encounter it. Detection mechanisms can be configured to trigger alerts whenever there is access to the file, or someone tries to log in using the certificate. These events can be monitored through specific event IDs like EID 4624 for Kerberos PKINIT or Schannel logons. The strategy generally involves using honey certificates as traps to identify and address attackers searching for and exploiting certificate and private key files.

Miscellaneous

Some Windows security events may be worth considering but have yet to be extensively explored. These events include:

• •  Event 4882: Changes in security permissions for Certificate Services. This can be relevant if attackers modify the Access Control Lists (ACLs) of the Certificate Authority (CA).

• •  Event 4890: Changes in certificate manager settings for Certificate Services.

• • Event 4892: Changes in a property of Certificate Services.

The technique to extract or obtain host private keys using SharpDPAPI involves elevating privileges to the SYSTEM level to retrieve the DPAPI_SYSTEM LSA secret to assist in monitoring Vulnerable Certificate Authority Access Control Detection, Domain Escalation scenario 7. Prevention measures related to elevating the SYSTEM level and dumping LSA secrets would also apply in this context.

Incident Response Guidance

In case of a breach, the traditional incident response approach of wiping/reprovisioning a user’s system and resetting their domain password may not be sufficient when dealing with certificates. Since certificates have a validity period beyond user password resets, there is a risk that issued certificates may have been stolen or that malicious certificates may have been requested. The suggested approach for addressing this issue includes:

• • Providing the user with an account.

• • Deactivating the old account.

• • Reviewing event logs for authentication attempts.

• • Cleaning the user’s workstation.

The user’s password should be reset if deactivating an account is impossible. Any certificates issued to that user and system should be invalidated in AD CS. However, programmatically examining a Certificate Authorities database for issuances poses specific challenges. To tackle this problem, the PSPKI PowerShell suite from PKISolutions is recommended as a toolkit. This suite offers functions that can be used to invalidate certificates. Additionally, PSPKIAudit can assist in investigating requests related to templates or from individuals. When the Certificate Authority server is compromised, or its private key is exposed, the organization should consider its entire PKI system compromised. Microsoft’s “Securing PKI: Compromise Response” document guides how to respond in scenarios. There are detailed technical guidelines available on decommissioning a CA server. However, providing incident response guidance for AD CS compromise goes beyond the scope of this document.

Conclusion

The key components of AD CS involving Active Directory environments, RADIUS, certificate management, PKI, Digital Certificates, and certificate templates are crucial to thoroughly understanding their roles and job functions. As we have covered, if administrators were to assign specific certificates to the wrong users and groups with highly privileged or misconfigured properties, it could lead to opportunities for hackers to take control of the Certificate Authority. Following the preventive team will assist highly with mitigating these attacks and lead to a more secure network. To avoid the complexities, maintenance, and vulnerabilities presented by AD CS, SecureW2 specializes in simplifying premier network security for enterprises with many different solutions, including PKI. Using a third-party public key infrastructure can benefit an enterprise for many reasons, such as cost, network segmentation, and increased productivity. We partner with Microsoft to ensure seamless integration and our solution’s versatility with many devices and operating systems. Contact us today to learn more about our solutions and the implementation process!