Securing AD CS: Microsoft Defender for Identity's Sensor Unveiled

Active Directory Certificate Services (AD CS) is commonly used in Active Directory environments to manage Public Key Infrastructure (PKI) and it plays a critical role in instrumenting digital certificates. Because of its ability to generate password-equivalent digital certificates, AD CS servers are classified as tier-0 assets whose compromise can be as catastrophic as a compromise to a Domain Controller itself. Despite being a prime target, AD CS security has been largely overlooked by security products and professionals over the years allowing cyber-criminals to continue exploiting gaps in protection to escalate privileges, steal credentials and gain domain persistence. 

 

In August we unveiled our newest Microsoft Defender for Identity sensor specifically designed for Active Directory Certificate Services (AD CS) servers to help our customers gain even more visibility into this critical piece of Identity infrastructure. Today I am excited to discuss some of the AD CS abuse techniques outlined in "Certified Pre-Owned" (by Will Schroeder and Lee Christensen) and share more insight into the upcoming Defender for Identity capabilities designed to help address them. 

 

New detections:

Suspicious Domain-controller certificate request (ESC8)

Active Directory Certificate Services (AD CS) provides various methods for issuing certificates, using different network protocols. Two common HTTP-based methods are the Certificate Enrollment Service (CES) and the Web Enrollment interface (Certsrv), which are often enabled on AD CS servers with default configurations. These configurations have been found to expose the endpoints, making them prime targets for NTLM relay cyber-attacks. NTLM relay is a well-known technique where a victim authenticates to an attacker-controlled machine, and the authentication is relayed to another target, impersonating the victim's identity. If the target server doesn't enforce protocol signing, the cyber-attack succeeds, granting the cyber-criminal access with the victim's privileges. Although highly effective, this strategy has a significant drawback since the access is limited to a specific session and specific server—the non-enforcing target.

 

ESC8 is a variant of the classic NTLM relay that targets AD CS HTTP endpoints. An adversary using this variation can issue a certificate for the impersonated entity, making access persistent for the certificate's lifetime (typically around a year). The certificate is valid for authenticating using the PKINIT Kerberos protocol extension and can be used for accessing every resource, rather than one victim server as in the classic NTLM Relay scenario.

 

This persistence, however, isn't limited to the certificate's lifetime. Once in possession of the certificate, cyber-attackers can also retrieve the user's NTHash (even if the password has been rotated) allowing them to persist even longer in the environment simply by holding the account’s NTHash.

In a scenario where the victim of such an attack is a Domain Controller (NTLM authentication can be coerced in several ways, see more here), the cyber-attacker would obtain a certificate valid for the DC, potentially leading to a full domain compromise (by performing DCSync attack, for example). The diagram depicts this below:

 

 

To help counter this type of cyber-threat, Microsoft Defender for Identity‘s new AD CS sensor for AD CS monitors for certificate issuance requests and triggering an alert when those requests are relayed from a Domain Controller. The alert below is an example, detailing that DC1 has requested a certificate, but the request originated from different source than expected (CLIENT2 instead of DC1), and the request was processed in DC2 (AD CS server).

 

 

Suspicious disable of audit logs of AD CS

Auditing in AD CS can be disabled by a privileged cyber-attacker, enabling them to carry out malicious actions without leaving any traces of their activities. Microsoft Defender for Identity now monitors audit configurations and this new detection alerts you when changes have been made, highlighting which audit configurations were altered.

 

Suspicious deletion of certificate database entries

Another method cyber-criminals use to cover their tracks is to delete the certificate requests themselves. This new detection monitors such activity, indicating when and by whom these requests are deleted. Microsoft Defender for Identity also profiles past deletions carried out by the suspicious user across all AD CS servers to help distinguish between legitimate and malicious activities.

 

Suspicious modifications to the AD CS settings (ESC7)

Certificate Authorities (CAs) maintain an access control list that defines roles and permissions for the CA. There are two permissions of particular interest, as they grant an attacker the ability to perform high-privilege operations on the CA:

 

 

• Issue and Manage Certificates (also known as 'CA Officer') – An attacker with this permission can revoke certificates and approve certificate requests, potentially bypassing security measures like 'Manager approval'.
• Manage CA (also known as 'CA Administrator') – An attacker with this permission can perform various administrative actions, such as enabling certificate templates, editing CDP endpoints, and most dangerously, modifying the CA settings to introduce misconfigurations that could compromise the Certificate Authority entirely (and consequently the entire organization).

Cyber-attackers may add these permissions to escalate privileges or create a hidden backdoor as a persistence measure. To help counter this, MDI now monitors changes to the Certificate Authority ACL and raises alerts when suspicious additions of high-privilege permissions occur.

 

Security Recommendations

In line with Microsoft Defender for Identity's commitment to helping customers institute identity security protections we believe our product should proactively "shift left" and help prevent compromises as much as detect once they have occurred. To achieve this, Microsoft Defender for Identity offers Security Posture recommendations alongside detections, surfacing security issues and severe misconfigurations that pose risks to the entire organization.

 

This aspiration grows even bigger, considering that Active Directory Certificate Services (AD CS) can be complex to manage and prone to various misconfigurations, differing in severity, exploitability and prevalence. Overall, we asses that 30-40% of environments with AD CS deployed in their forest, have at least one exploitable misconfiguration of the highest severity. To address these potential risks, we are happy to introduce the new AD CS-related ISPMs, where we will analyze the configurations of different AD CS components and guide remediation, if necessary.

 

The security recommendations detailed below fall into two categories - Certificate Template (which rely on the PKI-Certificate-Template Active Directory objects and do not require the AD CS sensor) and Certificate Authority ones (which do require the AD CS sensor).

*The below recommendations were released for private preview, and will be globally available on December 18th 2023*

 

Certificate Templates Security Recommendations

Certificate templates in Active Directory Certificate Services (AD CS) serve as blueprints for creating digital certificates. A certificate template defines the format, security settings and the intended usage of a digital certificate – including information such as cryptographic algorithms, EKUs, ‘Manager approval’, authorized signatures required and other attributes.

 

EKU - Certificates have an “Extended Key Usages (EKUs)” field – it holds a set of Object identifiers (OIDs) that describe how the certificate can be used. Common OID examples include Client Authentication (OID 1.3.6.1.5.5.7.3.2) and Code Signing (OID 1.3.6.1.5.5.7.3.3).

Manager approval – This certificate template option ensures that each request for this template requires manual approval from a certificate manager (a user with "Manage Certificates" permission on the CA). This option serves as an additional control for sensitive templates.

Number of authorized signatures required – determines the number of valid signatures (with existing certificates) that need to be supplied in the certificate signing request (CSR).

 

 

For a certificate template to be available for enrollment, it must be published by a Certificate Authority (CA). Each enrollment service announces its supported templates using the certificateTemplate attribute (Certificate Templates and Enrollment Services are represented as AD objects, accessible via LDAP). When a client requests a certificate from a CA, it must specify a certificate template, which in turn must be published by a CA. The CA then uses the certificate template to create the requested certificate with the specified settings.

 

As previously mentioned, certificate templates are essentially Active Directory objects, found in the "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<Domain_Name>" container. Each AD object contains the specific configurations and details for the template, and CAs query them (using LDAP) from Active Directory. Like all AD objects, Certificate Templates have ACLs that control access to the object. In the case of Certificate Templates, they include enrollment permissions on top of regular permissions, determining which entities can issue a certificate from the CA.

 

While most configuration options for a Certificate Template are not inherently dangerous, certain combinations of configurations might create severe vulnerabilities, undermining the entire trust model of Active Directory. Microsoft Defender for Identity now analyzes the Certificate Templates within the organization and presents an ISPM for each exploitable configuration (abuseable template that is published by any certificate authority) found, aligning with some of the escalation techniques in “Certified Pre-Owned”. We highly encourage you to address these vulnerabilities if they are found in your environment, as they can be critical.

 

 

Prevent users to request a certificate valid for arbitrary users (ESC1)

Each certificate is associated with an entity through its subject field. However, a certificate also includes a "Subject Alternative Name" (SAN) field, which allows the certificate to be valid for multiple entities. This feature is commonly used for web services hosted on the same server, enabling the use of a single HTTPS certificate instead of separate certificates for each service. When the specific certificate is also valid for authentication (by containing an appropriate EKU, such as Client Authentication), it can be utilized for authenticating several different accounts.

For instance, consider this certificate that indicates it was issued for User1 and can be used to verify their identity. This certificate also includes the Administrator account in its "Subject Alternative Name" field, making it sufficient for authentication as the Administrator as well.

 

 

The obvious question is, how one can enroll a certificate that is valid for additional accounts? When the “Supply in the request” option is selected for a certificate template, the enrollee states in the certificate signing request (CSR) which entities will be included in the certificate SAN, allowing any user with sufficient enrollment permissions, to enroll a certificate valid for arbitrary users. If the certificate is permitted for authentication and no mitigation measures (such as ‘Manager approval’ and authorized signatures requirement) are enforced, this certificate template is extremely dangerous and enables any unprivileged user to easily takeover any arbitrary user, naturally, a domain admin user.

 

 

If Microsoft Defender for Identity has reported certificate templates that endanger your organization due to this vulnerability, perform at least one of the following possible remediations on the impacted templates (showed in the “exposed entities” pane)

1. Disable the “Supply in the request” configuration. 
2. Remove any EKU’s enabling user authentication (Client Authentication, Smartcard logon, PKINIT client authentication, Any purpose). 
3. Remove overly permissive enrollment permissions, which allows any user to enroll certificate based on that certificate template. Templates that were marked as vulnerable by MDI have at least one access list entry enabling enrollment for built-in unprivileged group (e.g., Authenticated Users, Everyone) making this exploitable by any user.
4. Enable ‘CA Certificate Manager approval’ requirement.

5. Remove the certificate template from being published by any CA. Templates which are not published cannot be requested (thus cannot be exploited).

 

 

Edit overly permissive Certificate Template with privileged EKU (ESC2)

Digital certificates play a vital role in establishing trust and preserving integrity throughout an organization, not only in Kerberos domain authentication but also in other areas such as code integrity (signing code and binaries), server integrity (e.g., HTTPS), and technologies that rely on certificates like AD FS and IPSec.

 

When a certificate template has no EKUs or Any Purpose EKU, and is enrollable for any unprivileged user, certificates issued based on that template can be used maliciously by an adversary, compromising trust in the above-mentioned components. Note that even though it can’t be used for impersonating user authentication (as opposed to ESC1), it compromises other components that relieve digital certificates for their trust model – for example, adversary can craft TLS certificate, impersonating any website.

 

Microsoft Defender for Identity will report on certificate templates prone to this vulnerability. In case this issue is found in your environment, make sure to restrict their overly permissive enrollment permissions/remove them from being published. We also recommend enforcing additional mitigations such as ‘Manager approval’ and signing requirements, if possible.

 

Edit misconfigured Enrollment Agent certificate template (ESC3)

As you can imagine, in most cases regular user doesn’t enroll a certificate for itself, but rather have an Enrollment Agent that enrolls the certificate on behalf of him. An Enrollment Agent certificate is a certificate with the “Certificate request agent” EKU in its EKU list, allowing it to enroll certificate for any eligible user (eligibility is controllable, but defaults to all users) by signing the CSR with the agent certificate.

 

If there is an enabled (published) template with a “Certificate request agent” EKU that is enrollable by any user, which don’t have any mitigations enforced, an unprivileged user would be able to enroll an Enrollment Agent certificate that can be later used to enroll certificates. It is important to note that an Enrollment Agent certificate is not allowed to enroll certificates for any template, there are some conditions to be met by another template in order for this attack to be exploitable - and enable complete forest takeover. The second template that is required for this specific abuse (the template that would be requested using the Enrollment Agent certificate) is any template that has EKU for authentication, enrollable for any user, not requiring ‘Manager approval’ and with appropriate schema version (schema version should be 1, or alternatively bigger than 1 with Application Policy containing “Certificate request agent” EKU). There are default templates that meet these conditions.

 

If both necessary templates configurations described above are found, an adversary with an unprivileged user can enroll an Enrollment Agent certificate and use it afterwards for enrolling certificates permitted for authentication on behalf of arbitrary users.

 

Microsoft Defender for Identity will report on Enrollment Agent certificate templates endangering your organization only when finding a second template enabling the utilization of the attack. If found, perform at least one of the following possible remediations on the affected templates (MDI will show only the Enrollment Agent templates on the “exposed entities” pane).

1. Remove “Certificate request agent” EKU.
2. Remove overly permissive enrollment permissions, which allows any user to enroll certificate based on that certificate template. Templates that were marked as vulnerable by MDI have at least one access list entry enabling enrollment for built-in unprivileged group (e.g., Authenticated Users, Everyone) making this exploitable by any user.
3. Enable ‘CA Certificate Manager approval’ requirement.
4. Remove the certificate template from being published by any CA. Templates which are not published cannot be requested (thus cannot be exploited).
5. Use Enrollment Agent restrictions on the Certificate Authority level (it is possible to restrict which users are allowed to act as Enrollment Agent, and which templates can be requested).

 

 

Edit misconfigured certificate templates ACL (ESC4)

This abuse technique is more straightforward than the above, as in this scenario an attacker is tampering with the certificate template settings, applying an artificial misconfiguration - as those mentioned above.

 

As we already mentioned, certificate templates are AD objects with an ACL controlling the access to the object. Besides determining enrollment permissions, the ACL also determines permissions for editing the object itself. If, for any reason, there is an entry in the ACL that grants built-in unprivileged group (e.g., Authenticated users, Domain users, Everyone) permission allowing to change template settings (e.g., Full control, Write DACL), this is extremely severe as it means that an adversary would be able to introduce one of the above-mentioned misconfigurations for the template, escalating privileges and compromise the whole forest.

 

If Microsoft Defender for Identity has reported certificate templates with overly permissive ACL, make sure to remove any entry that grants unprivileged group permissions that allow tampering the template. Additionally, we recommend removing the certificate template from being published by any CA, if they are not needed.

 

Note that another variant of ESC4 is covered by different report – “Edit misconfigured certificate templates owner”. If found, change the template owner to a privileged and monitored user.

 

Sensor based Security Recommendations

The following ISPMs focus on the Certificate Authority itself, rather than the certificate templates it publishes. Microsoft Defender for Identity helps identify misconfigurations and security vulnerabilities in the Certificate Authority and associated services, highlighting prevalent issues that leave your CA vulnerable to attacks and potentially providing an attacker with an easy route to take control of the domain. To receive these security recommendations, it is essential to install the AD CS sensor on your AD CS CAs.

 

Edit vulnerable Certificate Authority setting (ESC6)

As we already learned from the ESC1 description above, unprivileged users that can specify the users in the Subject Alternative Names (SAN) may lead to immediate compromise and pose a great menace to your organization. We also mentioned that this configuration is per certificate template and should be handled accordingly. The following (mis)configuration we will discuss is similar, but it impacts the entire Certificate Authority rather than specific template.

 

AD CS Certificate Authority has many flags and configurations, the editflags among them. One particularly interesting flag from the editflags is EDITF_ATTRIBUTESUBJECTALTNAME2. If this flag is enabled, it means that every user can specify the SAN for his certificate request, affecting all certificate template, whether they have the “Supply in the request” option enabled or not. If there is an enrollable template that is valid for authentication, an attacker would be able to enroll a certificate that can impersonate any arbitrary account - similarly to the utilization of ESC1.

If Microsoft Defender for Identity reports a Certificate Authority in your organization that has this flag enabled, it is crucial for you to disable it – it endangers the whole organization. You can do it by executing the following commands:

Removing the flag – “certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2”

Restarting the service – “net stop certsvc & net start certsrv”

 

Edit misconfigured Certificate Authority ACL (ESC7)

If the former technique we discussed (ESC6) can be referred to as the CA-equivalent of ESC1, the following technique could be referred as the CA-equivalent of ESC4. Certificate Authorities maintain an access control list that outlines roles and permissions for the CA. If access control is not configured correctly, it might enable any user to interfere with the CA settings, circumventing security measures, and potentially compromise the entire domain.

 

The impact of a misconfigured ACL varies based on the type of permission applied. If an unprivileged user holds the "Manage Certificates" right, they can approve pending certificate requests, bypassing the ‘Manager approval’ requirement. With the "Manage CA" right, the user can modify CA settings, such as adding the "User specifies SAN" flag (EDITF_ATTRIBUTESUBJECTALTNAME2), again, creating an artificial misconfiguration that will later lead to a complete domain compromise.

 

If Microsoft Defender for Identity reports a Certificate Authority in your organization that has an overly permissive ACL, effectively allowing every user in the domain to perform administrative actions on the CA, remove all permissions granting unprivileged built-in groups “Mange CA” or/and “Manage certificates” permissions.

 

Enforce encryption for RPC certificate enrollment interface (ESC8)

In addition to the IIS endpoints mentioned above, Active Directory Certificate Services (AD CS) enables Certificate Enrollment via RPC protocol as well - specifically with the MS-ICPR interface. The settings of the CA determines the security level for the RPC interface, including the requirement for packet privacy. If the IF_ENFORCEENCRYPTICERTREQUEST flag (part of the InterfaceFlags) is enabled, the RPC interface will accept only connections with the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level (the highest authentication level) which requires each packet to be signed and encrypted, preventing any kind of relay attack (similar to ‘SMB Signing’ in SMB protocol). However, if the RPC enrollment interface does not require packet privacy, it becomes vulnerable to relay attacks (ESC8). The IF_ENFORCEENCRYPTICERTREQUEST flag is on by default but is often disabled to allow clients which cannot support the required RPC authentication level (client running windows XP, for example).

 

If Microsoft Defender for Identity reports that the RPC certificate enrollment interface has insecure settings, enable the IF_ENFORCEENCRYPTICERTREQUEST (and update affected clients, if there any).

 

Enabling the flag – “certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST”

Restarting the service – “net stop certsvc & net start ”

 

Edit insecure certificate enrollment IIS endpoints (ESC8)

As stated above, AD CS enables certificate enrollment through two HTTP-based endpoints - Certificate Enrollment Service (CES) and Web Enrollment interface (Certsrv). Insecure configurations of these endpoints make them vulnerable to NTLM relay attacks (ESC8).

If the IIS endpoint allows NTLM authentication without enforcing protocol signing (HTTPS) or without enforcing Extended Protection for Authentication (EPA), it becomes a ripe target for attackers trying to escalate privileges. Note that even though these roles do not exist by default on AD CS server, they are installed in most cases.

 

If Microsoft Defender for Identity reports on any enabled IIS endpoint with insecure settings, we recommend following these steps for each endpoint:

1. Determine whether the endpoint is necessary and in regular use. If it is not used, it is advisable to disable it.
2. Deactivate NTLM and Negotiate authentication providers for the IIS endpoint.
3. If NTLM cannot be disabled, enable "Require SSL" and "Require Extended Protection" for the IIS endpoint.

For more information, please refer to the official security advisory.

*This security recommendation is futured to be released in the beginning of 2024.

 

Bonus detection

Even though it is not necessarily related to AD CS, we have also released new detection that involves the usage of certificates for authentication, using PKINIT Kerberos (read more on the “PKINIT Kerberos” section in one of our previous blog posts).

 

Suspected account takeover using Shadow Credentials

Windows Hello for Business (WHfB) is a widely deployed feature on windows that replaces passwords with strong two-factor authentication on devices. This authentication consists of a type of user credential that is tied to a device and uses a biometric or PIN. It enables users to enjoy SSO experience without a password, working both in Active Directory and in Microsoft Entra ID.

 

When WHfB is deployed using the key trust model, the initial enrollment created as follows: the client generates a key pair - the private key will be saved on some kind of hardware protected device (usually a TPM) on the client side while the corresponding public key will be saved in the msDS-KeyCredentialLink attribute of the user. When the user attempts to authenticate, it will use a PIN/biometric on his endpoint and will log in, obviating the need of remembering password. Under the hood, after a successful biometric/PIN identification, the endpoint will perform a PKINIT Kerberos authentication using the private key from the TPM, and the KDC can verify the authentication using the private keys listed for the user in the msDS-KeyCredentialLink attribute. This flow is like SSH authentication in its essence.

 

Typically, when an attacker has permissions on an account in Active Directory, he can takeover this account using two main techniques:

• Changing the account password. As you can imagine, this method is noisy and likely to cause productivity impact for the victim user/computer.
• Abusing Resource Based Constrained Delegation. Well known technique, which is valid for computer accounts only, and is out of the scope of this article.

WHfB, as we explained above, relies on the msDS-KeyCredentialLink attribute for establishing trust. If an adversary has permission to edit this attribute on an account, he can add an arbitrary public key while having the corresponding private key, using it to authenticate on behalf of the user. This is a stealth and clinical way for taking over an account, working both for users and for computers. This technique can be used to gain persistence on sensitive accounts, gaining the attacker access regardless to the rotation of the account password.

 

Starting from version 2.208, Microsoft Defender for Identity detects malicious attempts of using Shadow Credentials technique to take over sensitive users and computers.

 

 

Wrapping up

In this article, we discussed some of the common AD CS abuse techniques outlined in "Certified Pre-Owned" (by Will Schroeder and Lee Christensen) and outlined how Defender for Identity's AD CS sensor can help address them. We cannot stress enough the importance of AD CS specific security in your environment and the severe potential damage that can result if gaps in protection go unaddressed. It is essential not to overlook this sensitive component, and we hope to have provided the necessary tools and guidance to help you secure your organization and enhance your identity protection.

 

We welcome any feedback and opinions on the content discussed in this article, as well as suggestions and ideas for additions to our security offerings.

 

Additional resources:

1. Learn more about the new sensor in our documentation here.
2. Learn more about Microsoft Defender for Identity, and begin a trial for Microsoft Defender for Identity here.
3. Black Hat talk that introduced the Shadow Credentials technique.