TL;DR
AD CS is Tier 0 identity infrastructure. Misconfigured templates, enrollment endpoints, or CA keys let attackers mint trusted identity credentials.
I have seen environments where everyone knew the domain controllers mattered, privileged groups were monitored, and password resets were part of the response plan. But when the conversation turned to certificate services, Active Directory Certificate Services (AD CS) was treated as “the PKI box.”
It issued certificates, nobody touched it often, and because nothing looked broken, it was assumed to be fine.
That assumption is dangerous. Attackers do not look at Active Directory Certificate Services as background infrastructure. They look at AD CS as a way to mint identity, escalate privileges, and persist through certificates that defenders may not be watching.
This is a practical AD CS security guide for defenders who need to understand certificate template abuse, ESC1, ESC8, Golden Certificate attacks, detection, and hardening.
Important takeaway: AD CS is Tier 0 identity infrastructure. Misconfigured templates, enrollment endpoints, CA permissions, or CA keys can let attackers mint trusted identity credentials instead of stealing passwords.
Why AD CS is an Identity Security Problem
If an attacker can abuse a certificate template, relay authentication to enrollment services, modify CA permissions, or steal a CA signing key, they may not need a password, MFA prompt, or malware payload. The certificate itself can become the credential.
Why the Misconfigurations Matter
AD CS are easy to overlook because they usually work quietly in the background. That quietness is the problem. A single vulnerable template can let a low-privileged user request a certificate that authenticates as a privileged account.
A web enrollment endpoint that accepts relayable NTLM can become a fast path to a domain controller certificate. A stolen CA private key can turn into a long-term forged identity across the domain.
The uncomfortable part: password resets do not automatically solve certificate abuse. If the attacker already has a valid authentication certificate, that certificate may continue to work until it expires or is revoked. In many environments, that window is months or years.
That is why AD CS belongs in identity threat detection, incident response planning, and resilience conversations. It is not just a PKI service. It is a trust fabric attackers can abuse.
How Certificate Abuse Usually Works
- Enumerate: Map certificate authorities, templates, enrollment rights, CA flags, enrollment endpoints, and PKI object permissions.
- Find the weak link: Look for dangerous subject settings, broad EKUs, weak approval controls, excessive enrollment rights, modifiable ACLs, or relayable enrollment services.
- Request or manipulate a certificate: Request a certificate directly, modify a template, abuse enrollment agent rights, or relay authentication to enrollment services.
- Authenticate as the target identity: Use PKINIT or certificate-based paths such as Schannel/LDAPS to act as the identity represented in the certificate.
- Persist: Keep using the certificate even after password resets or session cleanup if defenders miss it.
ESC1 Certificate Template Abuse: The First AD CS Risk to Check
ESC1 turns a certificate template into an impersonation service. The risky combination is usually simple: client authentication is allowed, the requester can supply the subject or SAN, approval is not required, and too many users have enrollment rights.
What to look for:
- Client Authentication EKU.
- Requester-supplied subject or SAN.
- Broad enrollment rights.
- No approval requirement.
- Long certificate validity.
The old DCShadow joke was, “My mom said I could be anything I wanted, so I became a domain controller.” ESC1 carries the same lesson with a certificate twist: if a template lets the requester choose the identity, the certificate can become whatever the attacker claims, including a privileged user or even a domain controller identity.
The failure is rarely exotic. It is usually a template created years ago for operational convenience, then forgotten. If Domain Users or another broad group can enroll, that template may become a privilege escalation path.
Why ESC1 Attacks Are Hard to Detect
It looks legitimate: The certificate was issued by a trusted enterprise CA, so authentication may look valid.
It survives common response steps: If responders only reset passwords or disable stale sessions, the certificate may remain usable.
It is often under-logged: Many environments do not collect the right CA events, template changes, enrollment activity, or certificate-based authentication signals.
The Control Failures Behind ESC Abuse
It is easy to get lost in the ESC numbering. For defenders, the better question is: what control failed? Most abuse falls into a few repeatable buckets: dangerous template settings, weak ACLs, unsafe CA-wide settings, relayable enrollment services, and compromised CA trust.
ESC1 is usually about template abuse. ESC8 is different because the weak point is the enrollment path itself.
ESC8 NTLM Relay to AD CS Web Enrollment
ESC8 is the web enrollment path I would not hand-wave away. If web enrollment accepts relayable NTLM without the right protections, an attacker may be able to coerce authentication from a machine account and relay it to the CA.
The high-impact version is a domain controller certificate. Once obtained, that certificate can support follow-on abuse that may lead to directory replication-style access, depending on the environment and controls. From the defender side, this is not just a web server hardening problem. It is an identity control problem.
Template and enrollment abuse are bad enough. A compromised CA private key moves the problem from misconfiguration to trust recovery.
Golden Certificate Attacks: When the CA Becomes the Backdoor
A Golden Certificate attack happens when the attacker compromises the CA private key and can forge certificates that chain back to trusted enterprise PKI. At that point, this is no longer only a template problem. It is a trust recovery problem.
A forged certificate can represent almost any identity the attacker chooses, depending on how the environment validates and maps certificates. It can also be long-lived and hard to distinguish from legitimate certificates.
If your incident response plan does not include CA key compromise, revocation impact, certificate reissuance, and trust rebuilding, you are not ready for the worst-case AD CS scenario.
AD CS Detection: Signals Defenders Should Prioritize
ESC8 is the web enrollment path I would not hand-wave away. If web enrollment accepts relayable NTLM without the right protections, an attacker may be able to coerce authentication from a machine account and relay it to the CA.
The high-impact version is a domain controller certificate. Once obtained, that certificate can support follow-on abuse that may lead to directory replication-style access, depending on the environment and controls. From the defender side, this is not just a web server hardening problem. It is an identity control problem.
Template and enrollment abuse are bad enough. A compromised CA private key moves the problem from misconfiguration to trust recovery.
Request and Issuance Activity
- Monitor certificate requests and issued certificates, including requester, template, subject, SAN, source host, and approval path.
- Pay special attention to Event ID 4886 for received certificate requests and Event ID 4887 for approved and issued certificates when auditing is enabled.
- Alert when the requester and certificate subject do not make sense, especially for privileged users, domain controllers, service accounts, and high-value groups.
Template and CA Changes
- Detect changes to certificate template ACLs, enrollment permissions, EKUs, subject name settings, issuance requirements, and manager approval.
- Watch for changes to CA configuration, CA security settings, NTAuth certificates, enrollment service configuration, and dangerous CA flags.
- Treat unexpected ManageCA or ManageCertificates delegation as high-risk until reviewed.
Authentication Correlation
Correlate certificate issuance with Kerberos certificate-based authentication, Schannel/LDAPS certificate authentication, privileged group activity, replication behavior, and first-time certificate logon for sensitive identities.
Once you know what to watch, reduce the number of ways attackers can get a useful certificate in the first place.
AD CS Hardening: What to Fix First
Templates
- Remove supply-in-request subject capability unless there is a documented and controlled business requirement.
- Restrict enrollment and auto enrollment to least privilege groups.
- Require approval for sensitive templates.
- Remove Any Purpose EKU and avoid templates with no clear EKU when authentication is possible.
- Retire unused templates instead of leaving legacy risk in place.
Enrollment services
- Disable web enrollment if it is not required.
- If web enrollment remains enabled, then enforce HTTPS and Extended Protection for authentication.
- Reduce or eliminate NTLM exposure where possible.
- Segment CA and enrollment endpoints so they are not broadly reachable from every workstation subnet.
Permissions
- Review who can modify certificate templates, CA settings, enrollment services, issuance policies, and NTAuth trust.
- Remove standing administrative access where JIT or approval-based access is possible.
- Treat CA infrastructure like domain controllers from a tiering, access, and monitoring perspective.
CA keys
- Limit interactive access to CA servers.
- Protect CA private keys with appropriate hardware-backed or operational controls.
- Monitor CA backup operations and private key export attempts.
- Document how you would handle CA compromise, including key rotation, certificate reissuance, revocation, trust removal, and PKI rebuild steps.
AD CS Assessment Checklist for Defenders
- Inventory every enterprise CA, enrollment endpoint, published template, and trusted root or subordinate CA.
- Enumerate certificate templates and flag dangerous combinations of authentication EKUs, subject supply, broad enrollment, weak approval, or long validity.
- Review permissions on templates, CA objects, PKI containers, issuance policies, and NTAuth trust.
- Validate web enrollment and RPC enrollment exposure, including NTLM relay resistance.
- Confirm CA auditing is enabled and that certificate request, issuance, approval, denial, revocation, and configuration changes are collected centrally.
- Correlate issued certificates with certificate-based authentication and privileged activity.
Validation matters.
- Do not only ask whether auditing is enabled. Confirm the events arrive in the SIEM and contain usable fields.
- Do not only ask whether templates are reviewed. Confirm template drift creates an alert.
- Do not only ask whether the CA is backed up. Confirm recovery steps exist for CA compromise, not just CA outage.
The goal is not to memorize every ESC label. The goal is to know whether your certificate infrastructure can silently mint identity credentials that bypass your normal assumptions.
The Key Takeaway and Action Plan
If you are responsible for Active Directory security, treat AD CS as part of identity attack surface management. Start with the basics: find vulnerable templates, reduce enrollment scope, harden enrollment endpoints, monitor certificate issuance, detect template drift, and prepare for CA key compromise.
Assume you have exposure until you prove otherwise. That mindset is not fear. It is operational reality.
This week: Run an AD CS assessment focused on templates, enrollment rights, CA permissions, and enrollment endpoints.
This month: Remediate high-risk templates, restrict enrollment, harden or disable web enrollment, and enable useful CA auditing.
This quarter: Build continuous monitoring for template drift, CA configuration changes, certificate issuance, and certificate-based authentication to privileged accounts.
Your certificate infrastructure is part of your identity perimeter. Defend it like attackers already know that.
FAQs
AD DS (Active Directory Domain Services) is the core directory service that stores and manages users, computers, and groups, and handles authentication and authorization. AD CS (Active Directory Certificate Services) is a separate role that issues digital certificates. AD CS certificates can be used to authenticate into AD DS, which is exactly why a compromised AD CS environment can bypass password-based controls in AD DS.
A CA (Certificate Authority) server is the system that issues, signs, and revokes certificates within AD CS. It holds the CA private key, which is what makes a certificate trusted. If that key is compromised, as in a Golden Certificate attack, the CA can be used to forge trusted certificates for any identity.
No. If an attacker already holds a valid authentication certificate, it can remain usable until it expires or is explicitly revoked, sometimes for months or years, regardless of password resets or session cleanup.
Tier 0 refers to the systems that can control the entire domain, including domain controllers and, per this article, AD CS. Anything at Tier 0 needs the strictest access, monitoring, and change control, since compromise at this level gives an attacker persistent, hard-to-revoke control over identity itself.
h2
text
h3
h3
hello
call out
h3
h2
hello
| hello | hello | hello |
| hello | hello | hello |
| hello | hello | hello |
| hello | hello | hello |
| hello | hello | hello |
| hello | hello | hello |
h2
hello
h3
hello
h3
hello
h3
hello
callout
h2
h3
callout
h3
Key Takeaways
See Cayosoft in Action
Cayosoft is recognized by Gartner as an ITDR solution provider and provides solutions that make identities more resilient to attacks and guarantee a fast forest recovery, if needed. Learn how Cayosoft Guardian facilitates granular change tracking, post-breach analysis, and long-term AD security improvements. Schedule a demo to see the capabilities in depth.