Active Directory Certificate Services (AD CS) abuse has been around for a while, yet it is still encountered regularly in Active Directory (AD) environments. As this topic has already been covered extensively online, this blog assumes a foundational understanding of AD CS and basic familiarity with the Certipy tool.
The purpose of this blog is to highlight key details that junior testers often miss. A stronger understanding of why a certificate template or certificate authority (CA) configuration is vulnerable will help not only with identifying valid attack paths during testing, but also with guiding clients towards effective remediation.
Many mistakes made by inexperienced AD testers come from not fully interrogating the tool output or not fully understanding why an attack is possible. Knowing what to look for helps you filter out false positives and identify valid attack paths that automated tooling may not clearly flag.
The first detail that is often overlooked in AD CS testing is the enrolment rights on a certificate template.
One of the most common AD CS attack paths is ESC1. In simple terms, ESC1 can allow an enrolee to supply a chosen Subject Alternative Name (SAN), which may let them request a certificate for another identity if the template is also usable for authentication. However, a template can appear vulnerable to ESC1 while standard Domain Users do not actually have the rights to enrol in it. A junior tester might therefore conclude that the issue is a false positive or has been sufficiently mitigated, but that is often not the case.
Another domain group may still have sufficient rights to enrol in the vulnerable template. In some cases, that group could be Domain Computers, which may be reachable by an attacker with only Domain User credentials if the Machine Account Quota (MAQ) allows them to create a computer account. Always review enrolment permissions carefully. Even if your current account cannot enrol, another obtainable principal might still be able to do so.
For example, a template may not be enrollable by Domain Users, but it may still be enrollable by Domain Computers. A low-privileged user may be able to create a machine account, enrol through that computer context, and still reach the vulnerable template.
Figure 1: An example of a certificate template with enrolment rights for Domain Computers but not Domain Users.
The second detail I often see junior testers miss is the Extended Key Usage (EKU) on each certificate template. EKUs matter because they influence whether an issued certificate can be used for AD authentication.
Useful values to look for include:
During live tests, inexperienced testers sometimes dismiss certificates simply because Kerberos authentication fails. This is a mistake. Certipy guidance often focuses on using a certificate to obtain a TGT to recover a privileged NT hash. If a certificate cannot be used successfully for one authentication path, that does not automatically mean it is useless.
For example, a certificate that is not usable for a specific Kerberos path may still be usable for LDAPS authentication. That could allow an attacker to modify a compromised object and move closer to Domain Admin privileges, depending on the permissions already available in the environment.
In summary, two AD CS details that are frequently overlooked are EKUs and enrolment rights. Manually checking these fields during testing will reduce the chance of missing a valid attack path.
Because visibility alone isn’t control. Alerts pile up, context gets lost, and the real attack paths stay buried between disconnected signals. What looks like coverage often hides gaps in understanding, and that’s where attackers win.
CybaOps changes that. It brings everything into a single operational layer, connects vulnerabilities to real-world impact, and highlights the actions that actually reduce risk. No noise. No guesswork. Just clear priorities and the ability to respond with confidence.
Speak to an expert and see how CybaOps helps you uncover what actually matters - Click here to enquire.