In our latest technical blog series, our DFIR team are highlighting the most prominent Active Directory (AD) threats, describing the tell-tale signs that your AD might be at risk, and give experienced insight into the best prevention and mitigation strategies to shore up your AD security and bolster your digital identity protection.
Last time we unravelled the sinister secrets of DCSync attacks. Up next, we're entering into the labyrinth of Active Directory Certificate Services (AD CS) attacks - where digital trust becomes a double-edged sword.
Definition
Active Directory Certificate Services (AD CS) is a critical component in enterprise networks. ADCS provides public key infrastructure (PKI) for managing digital certificates used in encryption, authentication, and digital signatures. While AD CS plays a vital role in securing communications and identities, it is often overlooked in security audits, leaving it vulnerable to exploitation. Misconfigurations in AD CS can lead to privilege escalation, lateral movement, and persistent attacks within compromised environments. Understanding and securing AD CS is therefore crucial to preventing certificate abuse and maintaining a robust infrastructure.With several ways to abuse misconfigurations on a Certificate Authority (CA) Server, it can be difficult to detect and respond because the techniques leverage legitimate functionalities within the component and by nature, the certificates (contrary to passwords) can remain active for extended periods of time. A number of AD CS attacks are described below.
Enterprise Security Certificates Attacks
An Enterprise Security Certificate (ESC) attack is a cyber-attack which abuses misconfigured certificate templates granting higher privileges to attackers. There are certain steps to performing this type of attack which are common to all templates. An attacker abusing Active Directory Certificate Services (AD CS) typically follows a sequence of steps, targeting weaknesses in the ESC configuration and processes, focusing on compromising certificates for privilege escalation and lateral movement. Typical steps include:
- Identify AD CS infrastructure: the attacker identifies if AD CS is present in the environment by enumerating domain controllers and checking for certificate-related services. If present the attacker needs to identify the Certificate Authority (CA) Server.
- Enumerate and discover Vulnerable Certificate Templates: the attacker looks for misconfigurations in certificate templates, such as:
- Weak or non-restrictive security descriptors (ACLs).
- Templates allowing Client Authentication or Enrollment for low-privileged users.
- Templates that allow certificates to be issued without subject name constraints.
This activity can be done either using Windows binaries such as certutil.exe or external tools like certipy or certify.
Certificate Templates are predefined configurations that define the settings and constraints for certificates issued by a CA. They allow administrators to standardize and automate the issuance of certificates across an enterprise environment by specifying the key properties, permissions, and usage scenarios for certificates.
Additionally for query certificate templates or request certificates, a valid account is needed, often the misconfigurations rely on low privileged accounts being allowed to request certificates for high privileged ones.
ESC1 - Certificate Template Vulnerability Abuse
Attackers exploit misconfigured certificate templates that grant excessive permissions. These templates allow low privilege users to request certificates that impersonate high-privileged accounts, such as domain administrators leading to privilege escalation because attackers can request certificates that allow them to authenticate with elevated privileges.
Templates vulnerable to ESC1 have the following configurations:
- Client Authentication: True
- Enabled: True
- Enrolee Supplies Subject: True
- Requires Management Approval: False
- Authorized Signatures Required: 0
This can lead to an attacker leveraging it to get a Kerberos ticket and the hash for this account, elevating its privileges. Once access is gained the attacker will have access to the account for the duration of the certificate validity regardless of any password changes, unless explicitly revoked.
To remediate you must revoke the certificate; delete the account and re provision another one for the user.
This attack is mapped as T1649 on Mitre ATT&CK. Steal or Forge Authentication Certificates. https://attack.mitre.org/techniques/T1649/.
ESC2 - Misconfigured Certificate Templates (2)
This is a variation of ESC1 attack. In this case a certificate template is configured with the Any Purpose EKU or without an EKU configuration. An EKU (Extended Key Usage) is a certificate extension that defines the intended purpose of the certificate, and the configuration specifies the roles or functions a certificate can perform. To be vulnerable the certificate template must have the following configurations:
- Enabled: True
- Enrolee Supplies Subject: True
- Requires Management Approval: False
- Authorized Signatures Required: 0
- Any Purpose: True OR Extended Key Usage: False - EKU configuration.
ESC3 - Enrolment Agent Templates
This is another variation of ESC1 attack. In this case The Certificate Request Agent EKU can be used to request a certificate on behalf of another domain object. To be vulnerable the certificate template must have the following configurations:
- Enabled: True
- Enrolee Supplies Subject: True
- Requires Management Approval: False
- Authorized Signatures Required: 0
- Certificate Request Agent EKU
The above techniques are often used when an attacker lacks permissions to request another user's certificate. The attacker can request a certificate with the ability to sign other certificates, thereby bypassing the restriction.
ESC4 - Vulnerable Certificate Template Access Control
ESC4 is possible when templates are misconfigured at the access control level. Should Access Control Entries (ACEs) allow unintended, or unprivileged Active Directory users to edit security settings in the template it can result in unintended users being granted one of the following template security permissions:
- Owner
- WriteOwnerPrincipals
- WriteDaclPrincipals
- WritePropertyPrincipals
These permissions permit any domain user to modify any property in the template, making the template vulnerable.
ESC5 - Vulnerable PKI Object Access Control
This is a post-exploitation attack that can only be performed once an attacker gains access as a local admin on the Certificate Authority (CA) server. The following must be met:
Certificate Authority Server as part of the Domain Local Admin access on the CA server Low Privileged Domain User
Once access is gained an attacker can exploit this privilege to create a Golden Certificate. These certificates are forged using the compromised CA’s certificate and private key. Once the certificate is generated the attacker can simply extract the password hash and the Kerberos ticket for the account.
This attack is mapped as T1555 on Mitre ATT&CK. Credentials from Password Stores. https://attack.mitre.org/techniques/T1555/.
ESC6 - EDITF_ATTRIBUTESUBJECTALTNAME2
ESC6 is often seen when issuing certificates for webservers. Administrators often wish for additional hostnames to be added to certificates which can be achieved by allowing SAN request attributes to be provided (+EDITF_ATTRIBUTESUBJECTALTNAME2 flag set on CA).
The EDITF_ATTRIBUTESUBJECTALTNAME2 flag applies to the entire CA and therefore every single certificate template which allows less privileged user enrollment can be misused to issue certificates with a Domain / Enterprise Admin as an additional User Principal Name (UPN).
This allows an intruder to enroll through any template set up for domain authentication, specifically those open to unprivileged user enrollment, like the standard User template resulting in an attacker being able to authenticate as a domain administrator or any other active entity within the domain.
ESC7 - Vulnerable Certificate Authority Access Control
A certificate authority has permissions that secure various CA actions, this can be accessed through certsrv.msc. The key permissions for such attacks are: ManageCA and ManageCertificates.
ManageCA grants a principal the right to perform administrative actions on a Certificate Authority (CA). This provides control over the EDITF_ATTRIBUTESUBJECTALTNAME2 flag, enabling any principal with ManageCA rights to exploit ESC6 using the Enable-PolicyModuleFlag cmdlet in PSPKI.
The ManageCertificates permission allows a principal to approve pending certificate requests, bypassing any issuance requirement. While this permission alone cannot compromise the domain, it can be used to circumvent certain protections.
ESC8 – NTLM Relay to AD CS HTTP Endpoints
ESC8 leverages the web enrolment interface of Active Directory Certificate Services (AD CS). The web enrolment interface is an optional feature alongside AD CS which is often utilised. Due to authentication web enrolment endpoints are particularly vulnerable to NTLM relay attacks.
A key vulnerability arises because not all of the AD CS web interfaces enforce HTTPS, which is essential for safeguarding against NTLM relay attacks. Furthermore, if the Certificate Authority (CA) has a published certificate template that supports client authentication and domain computer enrolment, which is very common, it can be exploited.
ESC8 can be directed at any domain machine, including domain controllers, making these web enrolment endpoints attractive targets. NTLM relay attacks often result in the attacker gaining privilege escalation by relaying the authentication to a service with higher privileges, allowing the attacker to further the attack.
AD CA’s that are vulnerable to ESC8 meet the following conditions:
- Web Enrollment: Enabled
- Request Disposition: Issue
The attack process for this technique can be summarized as follows:
- Victim machine authenticates to an attacker-controlled host.
- Hash from the victim to the ADCS HTTP endpoint.
- Request a certificate in the name of the forced machine account.
- Authenticate to collect the NTLM hash of the victim machine.
This attack requires a victim account to authenticate to an attacker-controlled machine.
ESC9 – No Security Extension
To understand this misconfiguration, it is necessary to refer to the concept of certificate mapping. It can be implicit or explicit, and weak or strong. Implicit mapping uses information in the certificate’s Subject Alternative Name (SAN) to match a user or machine account, while explicit mapping requires the certificate to be explicitly linked to an account’s altSecurityIdentities attribute. Weak and strong mappings influence the authentication process.
Certificate attributes, defined in certificate templates, determine how the Subject Name and SAN fields are populated. Some attributes are mandatory, and missing attributes can prevent certificate enrolment.
ESC9 refers to a setting that stops the security extension szOID_NTDS_CA_SECURITY_EXT from being included in a certificate. If enabled in the certificate template it can be easier to exploit weak mappings.
If the certificate attribute msPKI-Enrollment-Flag contains the flag CT_FLAG_NO_SECURITY_EXTENSION, the szOID_NTDS_CA_SECURITY_EXT extension will not be embedded, meaning that even with StrongCertificateBindingEnforcement set to 1, the mapping will be performed similarly as a value of 0 in the registry key.
When the setting for StrongCertificateBindingEnforcement is set to the default setting of 1 and the CT_FLAG_NO_SECURITY_EXTENSION flag is applied, weaker certificate mappings are allowed. This becomes a problem when someone can modify an account.
Misconfiguration of ESC9 permits an attacker the opportunity to obtain unauthorised admin access.
ESC10 - Weak certificate mapping
ESC10 is a variation of the same Domain compromise technique as ESC9. ESC9 uses an account that the current principal has GenericWrite permissions over to compromise any account in the Domain, including Domain Administrators. The main difference between ESC9 and ESC10 is that ESC9 is limited to a specific certificate template, whereas ESC10 has no restriction.
There are two main methods of exploitation, determined by specific registry keys on the Domain Controller:
- StrongCertificateBindingEnforcement is set to 0 (located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc). An attacker take control of a user account, modify their UPN, and request a certificate as Administrator. With StrongCertificateBindingEnforcement configured as 0, an account with GenericWrite permissions can be exploited to compromise any other account.
- If CertificateMappingMethods includes the UPN bit (0x4) (located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel). An attacker can compromise any account, even those without a userPrincipalName, such as machine accounts, including Domain Controllers, through the proxy account controlled with GenericWrite permissions.
ESC11 - Relaying NTLM to ICPR
If the CA server is not configured with the IF_ENFORCEENCRYPTICERTREQUEST attribute, an attacker can exploit this vulnerability to conduct NTLM relay attacks against the RPC service without requiring signing. By leveraging authentication coercion, it is possible to relay any Domain Computer’s authentication request to the CA and request a certificate as that machine account. This effectively grants access to any machine within the domain and poses a risk of a full Domain compromise.
As seen in ESC8, an attacker can potentially gain full control of a domain by requesting a certificate for the Domain Controller's machine account.
ESC12 – ADCS CA on YubiHSM
In this scenario, administrators can store an AD CS Certificate Authority on a Yubico YubiHSM, a hardware security module used for enhanced protection.
If an attacker gains remote command execution on the host operating system, they can exploit the YubiHSM CA’s private key to create and issue certificates. This attack is possible because the plaintext password required to unlock the YubiHSM is stored in the registry key of the local machine: HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword.
ESC13 - OID Group Link Abuse
An Object Identifier (OID) is a unique identifier that distinguishes all Active Directory objects. The ms-DS-OIDToGroup-Link attribute links an issuance policy to a specific Active Directory group. If a certificate template is configured with the necessary enrolment rights for a particular user or computer, and the issuance policy for that template has an OID group link, the user or computer can request a certificate that effectively grants access to the resources as a member of the linked group.
Like other ESC vulnerabilities, ESC13 requires conditions such as client authentication and certificate enrolment permissions. However, it also has additional requirements, including:
- The certificate template must have an issuance policy extension.
- The issuance policy must link to a specific AD group through an OID group link.
The impact of ESC13 largely depends on which AD group the OID group link connects to. If the link is to a high-privilege group, such as the Domain Admin group, it could enable full privilege escalation across the domain.
Preventing ADCS Abuse
All ADCS attacks rely on misconfigurations either from the CA Server, web interfaces or templates therefore the most important recommendation for preventing these attacks is to harden the configuration of the service entirely. This must be done with preventive measures, using hardening guides and testing before it goes into production, if it’s already in production, it is recommended to use automatic tools to test such the config such as GhostPack and PSPKIAudit. Conducting an offensive security assessment should also be considered. The following are general principles to follow upon configuring the service, but these will not replace testing and hardening.
Limit Permissions on Certificate Templates
- Restrict which users or groups can request certificates from sensitive templates.
- Restrict Enrolment Permissions: Ensure that only authorized users or service accounts can request certificates using the Enrol and AutoEnrol permissions.
- Review the CERTSVC_DCOM_ACCESS group to ensure that only legitimate users and computers have access to the certificate authority (CA).
Disable Unused or Vulnerable Certificate Templates
- Templates allowing user and machine authentication with weak configurations should be addressed.
- Use PowerShell or the Certification Authority MMC to disable templates no longer needed.
Implement Strong Key Protection
- Use Hardware Security Modules (HSMs) for the storage of sensitive private keys, especially those belonging to CAs.
- Ensure that certificates issued to users or services have strong key protection enabled, such as non-exportable keys or protected with Trusted Platform Module (TPM).
- Ensure that all certificates use at least SHA-256 or better.
Use Role-Based Access Control (RBAC) for CA Access
- Limit CA administrator roles to a few trusted individuals and audit regularly.
- Ensure that only CA administrators have permissions to modify key settings, templates, or access CA private keys.
- Use Dedicated Admin Workstations (PAWs) for managing AD CS components.
Monitor and Audit Certificate Usage
- Enable detailed logging of certificate requests and enrolments on the CA. Ensuring all certificate operations, including issuance, renewal, and revocation, are logged.
- Review logs regularly to detect suspicious certificate enrolments.
- Utilize Security Information and Event Management (SIEM) solutions like Splunk or Sentinel to alert on abnormal certificate-related activity.
Enforce Certificate Lifetime and Renewal Policies
- Reduce the lifetime of certificates to minimize the window of abuse.
- Regularly review and enforce strict renewal policies.
- Revoke certificates that are no longer necessary or that have been compromised.
Detecting ADCS Abuse
To detect ADCS abuse techniques and identify related misconfigurations, several key log sources, configurations, and Event IDs are essential. Here’s a summary of how to leverage Windows Event Logs and other solutions for each ESC detection scenario:
Certification Services Logs: Consideration should be given to ensuring the following Windows Security events are enabled.
- Windows Security Log Event ID 4886: Certificate Services received a certificate request
- Windows Security Log Event ID 4887: Certificate Services approved a certificate request and issued a certificate
- Windows Security Log Event ID 4768: A Kerberos authentication ticket (TGT) was requested
If these three events are detected together in a short period of time it can indicate that suspicious activity has taken place.
Monitoring for vulnerable certificate templates should also be considered:
- Windows Security Log Event ID 4899: A Certificate Services template was updated
- Windows Security Log Event ID 4900: Certificate Services template security was updated
Directory Service Changes Logs: Enable Event ID 5136 on Domain Controllers (DCs) to monitor for any certificate template modifications and security descriptor changes. This can indicate template configuration changes, which attackers may exploit for privilege escalation.
Kerberos Authentication Events: Monitor for anomalies in Kerberos authentication using Event IDs 4768 and 4769. This can help detect abuse through the use of tools like Rubeus and is important for detecting unauthorized smart card requests or anomalies in the PreAuthType field that can signal abuse.
Supplementary Detection Techniques: Enable Security Event ID 4688 (Process Creation with command-line auditing). This will capture suspicious PowerShell commands or the use of tools like Certutil and Certify.
Conclusions
AD CS is a critical component in managing and securing digital identities within an organization, enabling secure authentication, encryption, and digital signatures. Its complexity, however often leads to misconfigurations. Key vulnerabilities demonstrate that misconfigurations in certificate templates, permissions, and registry settings can be exploited to compromise domain security. Attackers can abuse poorly secured CA’s, weak certificate mapping, or misconfigured templates to escalate privileges or even achieve full domain compromise.
To mitigate these risks, it is vital for organizations to implement strong policies, enforce the use of security extensions, conduct regular auditing and protect sensitive data such as private keys and authentication credentials. Properly securing AD CS through best practices, such as limiting access to certificate enrollment, enforcing strong mapping, and regularly reviewing permissions, is essential for maintaining the integrity of an organization's Active Directory infrastructure.
Learn more about the following services to help you proactively prepare against Active Directory attacks:
Signup to our free Threat Intelligence for regular updates on the latest threat actors or contact NCC Group if you have any further queries.