AD CS Certificate and Security Configuration Exploits

Active Directory Certificate Services (AD CS) is a critical platform  in cybersecurity, providing infrastructure for managing certificates within an organization. At the heart of AD CS lies the Public Key Infrastructure (PKI), which uses pairs of public and private keys to enable secure communication. These keys, combined with algorithms and key lengths, form the basis for data encryption techniques that safeguard information by maintaining its confidentiality and integrity, thereby enhancing the safety of user authentication.

To incorporate this highly secure network feature into enterprise environments, domain administrators must have a strong understanding of AD CS. It issues digital certificates governed by templates, which determine which certificate a domain user or machine client will receive for authenticated network access and the level of access to server-based resources. This enables certificate-based authentication, allowing authenticated users to access their enterprise’s resources using 802.1x protocols. 

Unfortunately, AD CS is often mismanaged due to the complexity of maintaining and operating PKI infrastructure. AD CS is often misconfigured in the early stages, as most domain admins are more focused on finding the right settings that allow different systems and services to utilize the PKI while adhering to principles like least privilege and separation of duties. Frequently, it’s just easier to provide more permissions than necessary because it simplifies troubleshooting and management in a tightly controlled manner. This lack of awareness regarding the vulnerabilities and complex management of certificate templates can lead to improperly configured certificate service instances.

In this article, we will cover all the vulnerabilities an enterprise’s domain admin may encounter or currently face when using Microsoft’s PKI implementation through an Enterprise Certificate Authority, as uncovered by the cybersecurity organization SpecterOps. These vulnerabilities could lead to certificate theft, account persistence, domain persistence, and domain escalation attacks, compromising an enterprise’s entire AD CS system.

What are Some Key AD CS Components?

Below are the components that make up a Public Key Infrastructure and X.509 Digital Certificate that administrators would deploy for authentication, messaging signing, and encryption:

• Basic Constraints: Specifies if there are any constraints and if the certificate is an end entity or Certificate Authority. 
• CA(Certificate Authority): Certificate Authorities are responsible for issuing certificates and managing the validity of the certificates. Certificates can be issued by either Root or Subordinate Certificate Authority.
• Certificate Signing Request (CSR): An encrypted message sent from the Secure Sockets Layer (SSL) Digital Certificate requestee to the Domain Certificate Authority(CA). The CSR will validate whether the information the CA requires is valid. 
• DPAPI: The Windows Data Protection API is a way for the Windows Operating System to perform symmetric encryption or asymmetric private keys. This allows the current user account or computer to encrypt its data without creating and storing certificate private keys. 
• DPAPI Masterkeys: These are used to encrypt the user’s RSA key. This is stored in the same file as the master key that protects the user’s private keys.
• Extended Key Usages (EKUs): Object Identifiers (OID) that describe how the certificate will be intended to be used. This can also be referred to as Enhanced Key Usage. Object identifiers include:
  • Client Authentication
  • Code Signing
  • Encrypting File System
  • Secure Email
  • Smart Card Logon
• Issuer: The name of the CA that issues certificates. The Issuer and Subject are the same for root CAs.
• Masterkey: The client and server use the key for all session key generation. The master key generates the client-read key, the client-write key, the server-read key, and the server-write key. Master keys can be exported as simple key BLOBs.
• NotBefore and NotAfter dates: Also known as the validity Period, this specifies the duration of the certificate’s validity.
• Public Key Cryptography for Initial Authentication (PKNIT): This service allows Network Authentication Services to run a Key Distribution Center (KDC) on multiple OSs to use PKI in the Authentication Service exchange. The two methods of encrypting the response to a client are the Diffie-Hellman Key Exchange Method and the Public Key Encryption RSA Method. 
• Public Key: This associates the Subject with a private key stored separately.
• Public and Private Key: The core of the Public Key Infrastructure(PKI).  This long string of bits is used to encrypt and decrypt data during transmission. The public key is available to anyone who requests it and is issued by a trusted certificate authority. The public key verifies and authenticates the sender of the encrypted message. The private, or secret key, is kept confidential by the recipient of the encrypted message and used to decrypt the transmission so that only the recipient can open and read it. 
• Root CA: The core CA that functions at the start of the chain of trust in a PKI. This CA will sign the certificates for Subordinate CAs, authorizing them to Issue Certificates independently. 
• Subject: Here, you can enter the name of the user/device to which the CA issues the certificate. Most organizations use this to store the certificate Common Name, which is almost always the user’s email address.
• Serial Number: This is an identifier that the Certificate Authority assigns. 
• Subject AlternativeName: Defines the alternative names that the Subject may go by. 
• Signature Algorithm: The algorithm that is used to sign the private key. This is usually RSA 2048.
• Signature: This is the identity of the signature algorithm the certificate authority uses to sign the certificate.  
• Subordinate CA: This Certificate Authority is certified by another CA. 

AD CS Attacks

Active Directory Certificate Service attacks are often triggered by the misconfiguration of certificate templates and AD CS server settings. These vulnerabilities can be found within the enterprise PKI design, affecting components such as the enterprise root, enterprise subordinate, certificate templates, and auto-enrollment CA settings. Misconfigurations in these areas can lead to various attacks, potentially compromising your domain Certificate Authority (CA) and allowing attackers to operate as the organization’s CA. This access grants them complete control over all of the enterprise’s resources.

Attackers aim to gain privileged access rights equivalent to those of a domain admin user, enabling them to control the organization’s network and access domain users’ group information. They target weak points such as insufficient certificate mappings, vulnerable web enrollment endpoints, and misconfigured certificate values to access the domain administrator account of the Active Directory environments. In this section, we’ll explore the types of attacks that hackers employ and the different methods of offense they use.

1. Certificate Theft

The theft of certificates is a significant concern when it comes to Active Directory Certificate Services (AD CS). Attackers who want to compromise the confidentiality and integrity of communication can exploit vulnerabilities to steal certificates. By getting hold of certificates, they can masquerade as authorized users, leading to unauthorized access and potential data breaches. The impact of certificate theft extends beyond breaches: compromised certificates can be used for extended periods, making it difficult to detect and resolve the issue. In this section, we will cover four different methods of certificate theft.

Using Crypto API to Export Certificates

One of the simplest methods for attackers to steal certificates involves leveraging the Cryptographic Application Programming Interface (Crypto API). Imagine an attacker gaining access to a compromised domain PC where the private key is marked as exportable. The attacker can easily click on the certificate during an interactive desktop session and export it as a .pfx file. This export includes both the user or machine certificate and its private key, allowing the attacker to impersonate the legitimate user or device.

By utilizing tools and scripts designed to interact with Crypto API, attackers can quickly automate this process, extracting certificates from multiple machines. This makes it crucial to ensure that private keys are not marked as exportable unless necessary and to monitor for any unusual certificate export activities.

Extraction of User and Machine Certificates via DPAPI

Windows uses the Data Protection API (DPAPI) to securely store certificate private keys for user and machine certificates. User certificates are commonly stored in `HKEY_CURRENT_USER\SOFTWARE\Microsoft\SystemCertificates`, while machine certificates are often found in `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates`. Additionally, personal certificates for users are stored in the directory `%APPDATA%\Microsoft\SystemCertificates\My\Certificates\`.

DPAPI private keys are located in `%APPDATA%\Microsoft\Crypto\RSA\User SID\` for older keys and `%APPDATA%\Microsoft\Crypto\Keys\` for Cryptography Next Generation (CNG) keys. The DPAPI Master Key is required to decrypt these private keys. Attackers can identify the user or machine master key via a globally unique identifier (GUID) and use it to decrypt the private key.

To gain possession of user certificates and their associated private keys, an attacker will identify the most beneficial user certificate to extract, locate the corresponding DPAPI Master Key, and obtain the plaintext DPAPI Master Key needed to decrypt the private key. For machine certificates, attackers can use the system’s DPAPI_SYSTEM Local Security Authority (LSA) secret. However, attackers cannot decrypt the domain’s DPAPI Master Keys using the domain’s DPAPI backup key; only the SYSTEM user can access the DPAPI_SYSTEM LSA secret.

Locating Certificate Files

Another method attackers use to steal certificates involves locating files on compromised systems. These files are often found in predictable locations, such as the Downloads folder or shared directories. Attackers frequently use tools like the Seatbelt command within Windows PowerShell to streamline the search. For example, executing `dir C:\ -Recurse -ErrorAction SilentlyContinue | Where-Object { $_.Name -match “\.(pfx|pem|p12)$” }` can help locate certificate files.

The file extensions of interest include `.key` for private keys alone, `.crt` or `.cer` for certificates alone, and `.pfx` or `.p12` for combined certificates and keys. Additionally, attackers may search for Certificate Signing Request (CSR) files with the `.csr` extension, which contains domain, service, organization, and website information. Java Keystore files, which store private keys and certificates for Java applications, are also of interest, typically found with extensions like `.jks`, `.keystore`, or `.keys`.

Using PKINIT to Expose NTLM Credential Theft Vulnerability

When incorrectly implemented or misconfigured, combining certificates and Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) can expose NTLM credential vulnerabilities. Within Microsoft’s PKINIT specification, a fallback mechanism is in place if someone uses PKINIT to obtain a Ticket Granting Ticket (TGT) and successfully authenticates but needs to interact with services that do not support certificate-based authentication. The Key Distribution Center (KDC) returns the user’s NTLM hash within a specialized package called the Privilege Attribute Certificate (PAC).

Decrypting this package requires understanding the PAC_CREDENTIAL_DATA structure, representing the NTLM plaintext. Tools like Kekeo can handle smartcard-protected certificates if the attacker possesses the smartcard PIN. Thus, if an attacker retrieves NTLM hashes and combines them with a stolen root certificate from an Active Directory Certificate Authority (AD CA), they can fabricate certificates for any user or computer.

2. Account Persistence

Maintaining account persistence after gaining access is challenging in the AD CS environment. Once attackers gain entry through certificate theft, their next strategic move is to stay undetected within the system. They employ various techniques to ensure their presence is persistent, allowing them to maintain control and potentially engage in long-term malicious activities. This persistence can manifest in manipulating user accounts or creating unauthorized accounts, thereby complicating the efforts to uphold security measures. To achieve account persistence, attackers exploit methods such as active user credential theft through certificates, machine persistence through certificates, and certificate renewal strategies.

Active User Credential Theft Through Certificates

Active user credential theft via certificates is a primary method of achieving account persistence. This method is often employed in organizations with their own Certificate Authority (CA). In such environments, individuals can request a certificate for purposes like authenticating to Active Directory. To successfully acquire a certificate, they must meet the criteria defined in the certificate template, such as eligibility for enrollment, specific group permissions, and relevant Extended Key Usages (EKUs).

One commonly used template for this purpose is the “User” template. However, this template may sometimes be inactive or unavailable. In such cases, attackers use command-line tools to scan the Lightweight Directory Access Protocol (LDAP) directory for templates that meet the necessary criteria. If the attacker finds a suitable template, they can exploit it by requesting the corresponding certificate. The issued certificate allows them to authenticate as the user for its entire validity period, which often remains unaffected even if the user subsequently changes their password.

Furthermore, specific templates may have rights called “Enrollment Principals.” Using command-line tools, attackers can reveal these principals. If an attacker gains control over a principal with enrollment privileges for a certain template, they can exploit this situation to their advantage. They can manually request a certificate using graphical user interface (GUI) tools like certmgr.msc or command-line tools. Once the attacker secures the certificate, they can convert it into a compatible format and request a Ticket Granting Ticket (TGT) for the enrolled user as long as the certificate remains valid—typically for one year. Notably, these certificates can still be utilized even if the user changes their password, enabling attackers to commit long-term credential theft without needing continuous access to sensitive system components.

Machine Persistence Through Certificates

Machine persistence through certificates is another prevalent method used by attackers. Machine accounts are a type of user account that, if configured correctly, can be exploited by attackers to enroll compromised systems’ machine accounts into certificate templates. Specifically, if machine certificate templates are configured to allow Domain Computers as the enrollment principal, attackers can use this to gain unauthorized access.

The default “Machine” template is often pre-configured for this purpose. Once attackers obtain privileges on a compromised system, they can utilize the SYSTEM account to enroll in certificate templates that grant enrollment privileges to machine accounts. With a valid machine account certificate, attackers can authenticate themselves as the machine account within Kerberos. By employing the Service for User to Self (S4U2Self) delegation, they can acquire a Kerberos service ticket for any service on the host (like CIFS, HTTP, or RPCSS) as any user. This effectively grants them a powerful tool to maintain persistence on the machine for as long as the certificate template remains valid.

This method of persistence is robust. It remains effective even when the system updates its password (typically every 30 days) and can survive a system wipe, provided the same machine account name is reused afterward. Moreover, it does not require any modifications to the operating system, making it a stealthy and resilient means of maintaining access.

Certificate Renewal

Another strategy attackers use to maintain persistence is exploiting the certificate renewal process. Certificate templates usually include a designated “Validity Period,” which dictates how long an issued certificate remains valid. Additionally, a “Renewal Period” typically lasts for six weeks, during which account holders can manually renew their certificates before they expire.

Suppose an attacker manages to gain access to a domain authentication certificate through theft or exploiting vulnerabilities. In that case, they can use it to authenticate themselves to Active Directory (AD) for the certificate’s validity period. The renewal feature gives attackers a significant advantage: they can renew the certificate before it expires, extending their access to AD services without raising any security alarms.

AD Certificate Services (AD CS) itself is not inherently insecure. However, like any complex system, it can become susceptible to vulnerabilities if not configured and maintained properly. Attackers exploit these vulnerabilities to maintain their presence within an environment. Therefore, organizations must prioritize properly setting up and maintaining their AD CS to protect their environment from exploitation. 

Layered Defense Against Account Persistence

Mitigating these persistence techniques involves a multi-layered approach. Here are some best practices to enhance your defenses:

• Strict Template Management: Enforce stringent policies for certificate template creation and management. Only authorized personnel should be able to create, modify, or approve templates. Review and audit template configurations to ensure they adhere to security best practices.
• Limit Enrollment Privileges: Restrict enrollment privileges to the minimum number of users and devices necessary. Implement policies that limit which accounts can request or renew certificates, particularly for high-privilege templates.
• Expiring Credentials Regularly: Implement policies that automatically expire certificates and associated credentials regularly, ensuring that even if an attacker gains access, their opportunity window is minimized.
• Continuous Monitoring: Utilize advanced monitoring solutions to detect certificate requests and usage anomalies. Real-time alerts for unusual activities, such as unexpected certificate enrollments or renewals, can help you respond swiftly to potential breaches.
• Enhanced Authentication Mechanisms: Apply multi-factor authentication (MFA) for all certificate-related operations, including requesting, renewing, and managing certificates. MFA adds a layer of security, making it more difficult for attackers to exploit stolen certificates.
• Patch and Update: Regularly update your AD CS systems to incorporate Microsoft’s latest security patches and improvements. Keeping your system up-to-date reduces the chances of attackers exploiting known vulnerabilities.

3. Domain Escalation 

Domain Escalation is an attack against AD CS caused by misconfigured certificate templates. After gaining access and establishing account persistence, adversaries often aim to elevate their privileges within the domain. Misconfigured certificate templates play a role in this phase, allowing attackers to exploit vulnerabilities and gain levels of access. Domain Escalation can result in control over infrastructure, potentially compromising the overall security of the entire network. In the following section, we will cover all eight attack methods in order of the most popular methods. 

Misconfigured Certificate Templates Configuration 

Misconfigured certificate templates are one of the biggest causes of Domain Escalation among organizations. When configuring certificates, administrators must be very mindful of the selected attributes for their templates; if not, they will put their enterprise and all users on their domain at risk for Domain Escalation.

Administrators should know three scenarios of vulnerable certificate templates when setting their configurations. 

ESC1 

• Enterprise CA provides Enrollment Rights to Low-Privileged Users.

• The Manager Approval Setting  is not enabled
• Not Requiring the Use of Authorized Signatures for CSR

• The Security Descriptor that is too permissive gives certificate enrollment privileges to Low-Levels.

The first scenario’s misconfigured certificate template allows the attacker to request a certificate using an arbitrary SAN (Subject Alternative Name/ subjectAltName). It will allow the malicious hacker to authenticate as any principle with low user privileges using SChannel or Kerberos.  This can occur because the Certificate Template will enable requesters to specify a SAN in the CSR (Certificate Signing Request) and define which EKUs (Extended Key Usage) will allow authentication. This includes EKUs such as Smart Card logon, Client Authentication, PKINIT Client Authentication, and any purpose or no Extended Key Usage/Sub CA.

Active Directory will use the identity specified by Certificates SAN during authentication, which allows the hacker to identify the SAN in the CSR. Knowing this, the attacker will then be able to request certificates as any user under the Active Directory environment, which includes the domain administrator, making this the most significant weak point.

ESC2

• Enterprise CA provides Enrollment Rights to Low-Privileged Users
• The Manager Approval Setting  is not enabled
• Not Requiring the Use of Authorized Signatures for CSR
• The Security Descriptor that is too permissive gives certificate enrollment privileges to Low-Levels 
• The Template defines no or Any purpose EKU

The second scenario has misconfigurations similar to the first, but the certificate template defines the Any Purpose or no EKU, allowing the hacker to authenticate to the Active Directory. The Any Purpose EKU enables the attacker to perform any authentication, such as server and client authentication. This can also lead to the attacker using the no EKU template/ a SubCA certificate to sign new certificates to specify an arbitrary EKU or fields within the new certificates.  

ESC3 

The third scenario of misconfigured certificate templates requires an extra step from the above vulnerable certificate template conditions. Two circumstances would cause Domain Escalation. 

Circumstance 1

• Enterprise CA provides Enrollment Rights to Low-Privileged Users
• The Manager Approval Setting  is not enabled
• Not Requiring the Use of Authorized Signatures for CSR
• The Security Descriptor that is too permissive gives certificate enrollment privileges to Low-Levels 
• The template, on behalf of other principles, specifies the Certificate Request Agent EKU

Circumstance 2

• Enterprise CA provides Enrollment Rights to Low-Privileged Users
• The Manager Approval Setting  is not enabled
• Enrollment Agent Restrictions are not enforced within the CA 
• The Template Specifies that an EKU that enables Domain Authentication 
• The Template Composition of Scenario 1 and Scenario 2 distinguishes an Application Policy Issuance Requirement Requiring CR Agent EKU

The hacker can abuse certificate templates in this scenario by recognizing the Certificate Request Agent EKU vulnerability. This EKU allows a principal to enroll for a certificate on behalf of another user. This can lead to privilege escalation for the attacker because the enrollment agent will register the hacker in a template that uses the certificate to co-sign a Certificate Signing Request on behalf of that hacker. After cosigning, the Certificate Signing Request will then be sent to the Certificate Authority with the requested certificate and enroll it with the template that permits “enroll on behalf of..” showing the certificate belonging to the other user, which will most likely be a domain admin.

Even if this configuration of Certificate Authority can be set to “Restrict Enrollment Agents,” this default setting is very permissive. It allows anybody on the domain to access and enroll in all templates as anybody within the Active Directory Environment to achieve domain administrator privileges.  

ESC 8: NTLM Relay to AD CS HTTP Endpoints

HTTP-based certificates are vulnerable to Domain Escalation through NTLM Relay attacks. These attacks can occur because of the combination of a published certificate template that allows domain computer enrollment and client authentication and the HTTP-based Certificate enrollment endpoints not having their NTLM Relay protections enabled. A hacker using a compromised machine to impersonate any inbound NTLM-authenticating Active Directory account perpetrates these attacks. 

After gaining access to the account, the hacker will begin to interface with web interfaces to request client authentication certificates depending on the user or machine certificate template that will allow the attacker more access within the system. 

This domain escalation scenario comes with its limitations. The attacker has a short time window for abusing the Certificate because of a Privileged Account in AD ( Active Directory). After relaying the inbound authentication, the account can only authenticate once to the hackers’ machine.  Attackers get around these limitations by forwarding the inbound authentication to the AD CS interfaces instead and requesting a client authentication certificate portraying as the victim’s account. They can then authenticate using Kerberos, Schannel, or PKNIT to gain the privileged NTLM hash. By doing so, the attacker will achieve access to the victim account for the length of the certificate validity to the domain and will be able to authenticate to any provided service through multiple authentication protocols without interference from NTLM Signing.  

Another limitation that attackers face is the requirement of the target account to authenticate the attacker’s possessed machine.  This can be sidestepped in two different ways. The Hacker can either wait for the target to sign into the machine or coerce an account to authenticate to the compromised machine using “ The Printer Bug” technique. This portrays a machine account requesting a Client Authentication Certificate-based template as that target machine’s account using its machine certificate. This could lead to the hacker carrying out privileged actions like domain replication if that account were to have Privileged Access. Another technique that the attacker may use is the S4U2Self to gain access to the target machine’s host OS or PKINIT to receive the NT hash and create a forged Kerberos Service Ticket. 

An organization must audit its PCs and certificate templates, as Domain Escalation scenarios can affect any computer running the spooler service. Once the vulnerabilities within the domain are determined, it’ll only be a matter of time until the hacker achieves access to the domain network. 

ESC 4: Vulnerable Certificate Template Access Control

Access Control Entries that enable unprivileged AD principals to configure sensible security settings within the certificate templates can lead to a Domain Escalation attack. This is caused by the attacker recognizing the  AD principal’s specific permission within the securable object in AD or the certificate templates. The attacker will then begin an attack focusing on chain access, searching for a domain computer with permissions over a Certificate Template’s AD object. Eventually, this leads to a point where they can push a misconfiguration vulnerability to a certificate template established previously as secured. This misconfiguration can be done by enabling the flag msPKI-certificate-name-flag, allowing domain authentication.  

ESC 5: Vulnerable PKI Object Access Control 

Outside of certificate templates, several vulnerabilities from ACL-based relationships can lead to attacks, ending with the hacker gaining control of the enterprise PKI infrastructure and escalating the domain privileges.  These vulnerabilities that should be monitored are the CA server’s RPC/DCOM server, the CA server’s AD computer object, and descendent containers/AD Objects like the Certificate Templates container, NTAuthCertificate Object, The Enrollment Services Container, and more. 

ESC 6: Vulnerability within the User SAN (Subject Alternative Name) Syntax

This vulnerability allows an attacker to enroll with any certificate template configured for domain authentication and allows unprivileged users to register.  This is caused by the flag set on the CA with the setting attribute EDITF_ATTRIBUTESUBJECTALTNAME2. 

Check whether this is enabled within your AD CS settings using the certutil.exe command certutil -config “CA_HOST\CA_NAME” -setreg “policy\EditFlags.” 

ESC 7: Vulnerable Certificate Authority Access Control

The certificate authority secures CA actions through a set of permissions. You can view these permissions by clicking start, run, and typing in certsrv.msc, right-click on the CA select properties, then choose the Security tab or view it within Windows Powershell using “Get-CertificationAuthority | Get-CertificationAuthorityAcl.” Within Windows Powershell, the two settings that control Certificate Authority Access Control are CA Administrator and Certificate Manager, also known as ManageCA and ManageCertificates rights. Suppose the attacker can possess a principal with ManageCA rights or set the CA’s persisted configuration data using Config_CA_Accept_Request_Attribues_SAN. This can lead to a vulnerability within the User SAN using PSPKI to remotely access and configure the setting attribute EDITF_ATTRIBUTESUBJECTALTNAME2. 

4. Domain Persistence

Domain persistence represents the culmination of account persistence and domain escalation. It signifies establishing a long-term presence within the AD CS environment, enabling attackers to maintain control and continue their activities over an extended period. Achieving domain persistence allows enterprise adversaries to adapt to evolving security measures, making it increasingly challenging to detect and mitigate their actions. To perform domain persistence, attackers will forge certificates with stolen Certificate Authorities (CAs), deceive users into trusting rogue CAs, and maliciously misconfigure AD CS’s security services.

Forging Certificates with Stolen CA Certificates

The Certificate Authority (CA) is a cornerstone of any organization’s certificate infrastructure, holding a certificate and its corresponding private key on its server. Typically, enterprise CAs are hosted on servers separate from domain controllers, and, alarmingly, they often do not receive the same level of protection as tier 0 assets. Attackers can exploit this discrepancy in security levels.

To identify the CA certificate, attackers look for specific characteristics. The certificate is located on the CA server, and the machine’s Data Protection API (DPAPI) safeguards its private key unless hardware protection is employed. The certificate’s Issuer and Subject fields will be set to the name of the CA. If an unauthorized individual gains control over the CA server, they could extract the private key, enabling them to generate a .pfx file used for forging certificates. This forged certificate can then be employed for authentication, granting the attacker access to systems.

The severity of this issue is compounded by the fact that the forged certificate remains valid until its specified end date, as long as the root CA certificate is valid. This exploitation isn’t limited to user accounts but also to machine accounts. Furthermore, because the fraudulent certificate is not part of the official issuance procedure, the CA cannot revoke it. This approach allows attackers to maintain their presence on domain machines for as long as the CA certificate remains legitimate. The absence of revocation procedures means that the CA is unaware of the forged certificate’s existence, further complicating detection and mitigation efforts.

Trusting Rogue CA Certificates

In Kerberos authentication, an object known as NTAuthCertificates holds one or more Certificate Authority Certificates. During the authentication process, the domain controller verifies whether the NTAuthCertificates object contains a certificate from the CA that matches the user’s authenticating certificate. If a match is found, authentication proceeds; otherwise, it fails.

Attackers can exploit this system by employing methods to forge certificates. For example, they might generate a self-signed CA certificate and clandestinely insert it into the NTAuthCertificates object. This approach is only feasible if the attacker has control over the NTAuthCertificates object itself, which typically requires high-level privileges such as those held by members of the Enterprise Admin or Domain Admins groups.

Although this tactic is sophisticated, attackers often find it more straightforward to steal an existing CA certificate than to introduce a fraud. Stealing an existing certificate is a more direct and practical approach, making it a more likely method for malicious individuals seeking to deceive users and systems.

Malicious Misconfiguration

Attackers have numerous opportunities to maintain access through malicious misconfigurations in AD Certificate Services (AD CS). This includes making unauthorized modifications to various components, such as the CA server’s computer object, RPC/DCOM server, AD objects or containers related to Public Key Services, and AD groups with specific rights associated with AD CS.

For instance, attackers with high-level access could assign themselves special permissions on the default User certificate template. By doing this, they can later modify the template to assign ownership to themselves. With this ownership, they can manipulate specific settings, potentially creating certificates that impersonate high-level users, such as a domain administrator. 

One critical challenge for organizations is the lack of effective monitoring and auditing capabilities for permissions related to certificate services. The absence of such controls makes it difficult to detect and prevent unauthorized changes to configurations and permissions, allowing attackers to maintain a persistent presence undetected.

Layered Defense Against Domain Persistence

Mitigating domain persistence requires a multi-faceted approach involving both technical and administrative measures. Here are some best practices to fortify your defenses:

Harden CA Servers: Ensure that CA servers receive the same security protections as tier 0 assets. This includes stringent access controls, regular audits, and robust monitoring to detect suspicious activities.

Regular Certificate Audits: Regularly audits all certificates issued within your environment. Verify that only authorized certificates are being used and that there are no anomalies in issuance patterns.

Monitoring and Alerts: Deploy advanced monitoring tools to monitor changes to the NTAuthCertificates object and other critical configurations. Set up real-time alerts for any unauthorized modifications.

Strict Access Controls: Control who can modify AD CS configurations and certificate templates. Limit high-level permissions to a minimum and implement role-based access controls (RBAC) to ensure only authorized personnel can make critical changes.

Comprehensive Logging: Enable detailed logging for all certificate-related activities. Store logs securely and regularly review them to identify suspicious or unauthorized actions. 

Training and Awareness: Educate your IT and security teams about the risks associated with AD CS and the importance of maintaining robust security practices. Regular training sessions can help inform everyone about the latest threats and best defense strategies.

Mitigating AD CS Threats with SecureW2 Solutions

Active Directory Certificate Services (AD CS) isn’t technically a fully-fledged Public Key Infrastructure (PKI) but a CA server that provides the framework to build and implement a PKI. Linked to Active Directory, a Windows server functioning as a user database, AD CS is pivotal in deploying certificates to devices across a network. As explored throughout this article, numerous vulnerabilities and configuration issues within AD CS and Active Directory can expose an organization to various cyber threats.

To address these challenges, SecureW2’s JoinNow Connector PKI offers a comprehensive managed PKI solution that seamlessly integrates with existing infrastructure to deliver robust functionalities. SecureW2’s managed PKI solutions are designed with scalability, security, and simplicity at their core. By leveraging SecureW2’s cloud-based services, including Cloud RADIUS, organizations can streamline certificate management, automate the issuance of digital certificates, and enhance secure communications through advanced public key encryption. This combination simplifies the onboarding process for users and devices and significantly reduces operational costs by eliminating the need for on-premise hardware security modules and specialized personnel.

Our Cloud RADIUS enables secure authentication and authorization, ensuring only authorized users can access sensitive data and resources. With features like automatic key generation, digital signatures, and certificate authority functions, our PKI solutions provide an added layer of security that protects against man-in-the-middle attacks and unauthorized access. By choosing SecureW2, businesses can enjoy peace of mind from a highly secure and efficient public key infrastructure tailored to meet the demands of modern digital environments. Schedule a free demo to learn more.