This post is not intended to dive deep into the technical aspects of AD CS or provide an exhaustive guide to remediation. Instead, Syndis shares this warning out of a sense of public responsibility to raise awareness about this overlooked and dangerous security risk.

Much of the technical foundation for this post is based on research conducted by SpecterOps. For detailed technical insights, readers are encouraged to consult their research and publications.

If you’re running AD CS in your environment, you should keep reading.

What is AD CS?

AD CS has existed for a long time—it’s a Windows service used to issue digital certificates. While many IT professionals are aware of it, few understand its full scope and potential vulnerabilities.

It is generally assumed that AD CS is a secure way to enable encrypted communications and authentication within a domain. But in practice, the default settings and widespread misconfigurations can pose serious security risks.

Why is AD CS dangerous?

By default, Microsoft’s initial setup of AD CS is often insecure, and administrators frequently introduce misconfigured templates (Certificate Templates) that can be exploited.

In many environments, it’s possible for a low-privileged domain user to request a certificate impersonating any user, including a Domain Admin. These certificates can be valid for up to one year, and password changes won’t revoke the certificate’s effectiveness during its lifetime.

That means an attacker with minimal access can potentially generate a certificate and authenticate as a privileged user, undetected.

What Syndis Discovered

In spring 2022, Syndis was asked to assess a client’s AD CS deployment. What began as a routine investigation quickly revealed how easily exploitable this service can be when misconfigured.

Drawing from the work presented by SpecterOps at Black Hat 2021, Syndis confirmed that these misconfigurations—such as overly permissive templates—can allow attackers to issue certificates in the name of privileged accounts and gain unauthorized access to sensitive systems and data.

A Real-World Test: From Low Privilege to Domain Admin in Minutes

In testing, Syndis was granted access to a client’s domain environment as a low-privileged user. Within a few minutes, Syndis was able to escalate privileges to Domain Admin by exploiting the AD CS misconfigurations.

By requesting a certificate under the name of a user with elevated privileges, the Syndis team demonstrated just how devastating this vulnerability can be if left unaddressed.

How Widespread Is the Problem?

Syndis has evaluated numerous client environments, and in nearly every single case, AD CS was misconfigured in a way that allowed domain takeover.

In other words: nearly all AD CS installations Syndis has reviewed since becoming aware of these vulnerabilities have been exploitable.

This issue is not theoretical—it is actively exploitable and frequently overlooked.

What Should You Do?

If you are operating an AD CS instance within your network, you should immediately:

• Review whether AD CS is installed and running

• Audit Certificate Templates for insecure permissions

• Assess who can request and enroll certificates

• Consult technical resources, including the SpecterOps blog and their Black Hat presentation

Organizations should not assume AD CS is secure by default. Instead, treat it as a high-risk component, particularly if your business relies on Active Directory for identity and access management.