Executive TL;DR
- Active Directory exploitation increasingly relies on abusing trusted identity infrastructure rather than exploiting software vulnerabilities. Active Directory Certificate Services (ADCS) has become one of the most valuable targets because attackers can leverage legitimate certificate services for privilege escalation, persistence, and stealth.
- Compromised templates can issue valid certificates that give attackers persistent, detection-resistant access that survives password resets, credential rotation, and many identity remediation efforts.
- Attackers routinely find and exploit ADCS misconfigurations that security teams have never reviewed — often because the service has been running quietly for years without a formal security assessment.
- Traditional monitoring and SIEM tooling are largely blind to certificate-based authentication abuse, giving attackers a durable foothold that blends into normal PKI operations.
- Security teams face significant operational complexity when they remediate ADCS exposure. Revoking certificates, hardening templates, and restructuring enrolment permissions can disrupt business-critical services, which is precisely why action often gets delayed.
The only way to understand your actual exposure is to test it, because certificate abuse paths don’t announce themselves through alerts.
The Trust Infrastructure Attackers Love Most
Every enterprise has critical infrastructure that quietly does its job and never gets a second look. Active Directory Certificate Services falls squarely into that category for most organisations.
ADCS is the Microsoft PKI framework that issues digital certificates across the enterprise for user authentication, machine identity, code signing, encrypted communications, and more. It is foundational, deeply integrated, and in most environments, largely invisible to day-to-day security operations. An administrator may have configured it years ago and since left the organisation. The service has continued running quietly ever since.
That lack of visibility is the problem.
Security researchers have documented widespread ADCS misconfigurations. Attackers can use them to reach domain administrator, forge authentication material, and establish long-term persistence. That access may survive conventional incident response. SpecterOps established the foundation for this research in its 2021 whitepaper Certified Pre-Owned, which introduced a taxonomy of attack primitives — which researchers now catalogue as ESC1 through ESC16 — describing how enrolment permissions, template configurations, and CA trust relationships can be abused.
What makes this operationally significant isn’t the novelty of the techniques. It’s how common the enabling conditions are, paired with how little visibility most enterprise security programmes have to detect or respond to their abuse.
The question isn’t whether your ADCS environment is configured correctly. The question is whether you’ve ever tested it under adversarial conditions to find out.
Table of Contents
- Why Organisations Misread ADCS Risk
- How Attackers Realistically Abuse ADCS
- Where Exposure Hides
- Why Remediation Assumptions Often Fail
- Operational and Business Implications
- Why Offensive Validation Matters
- Operational Takeaways
- FAQ
Why Active Directory Exploitation Through ADCS Is Often Overlooked
ADCS Is an Identity Problem, Not an Infrastructure Problem
The most common misunderstanding about ADCS risk is categorical: security teams tend to classify it as an infrastructure problem rather than an identity problem. That distinction matters a great deal for how — or whether — exposure gets managed.
When organisations think about Active Directory security, attention typically flows toward privileged account management, domain controller hardening, Kerberos configuration, and lateral movement detection. Security teams usually treat ADCS as a supporting service rather than an attack surface in its own right. Certificate templates don’t typically show up on vulnerability dashboards. Misconfigured enrolment permissions don’t typically generate alerts. CA audit logs, where they exist, rarely feed into SIEM correlation rules in any meaningful way.
Hidden Trust Creates Hidden Privilege
That blind spot mirrors another recurring problem inside Active Directory environments: hidden privilege relationships. As discussed in our article on shadow admins in active directory, attackers don’t always need Domain Admin membership to obtain effective administrative control. ADCS misconfigurations create another class of hidden privilege paths that often remain invisible until they’re actively tested.
This creates a visibility gap that’s structural, not incidental. This does not mean security teams are careless — the tooling and monitoring frameworks most organisations rely on simply were not designed with certificate-based identity abuse as a primary threat model.
Legacy PKI Rarely Receives a Second Look
Compounding this, ADCS environments have historically been reviewed once at deployment and rarely again. Once certificates are issued and authentication is working, security and infrastructure teams tend to consider the PKI infrastructure solved. Templates accumulate over time, often carrying forward permissive configurations that administrators created years ago to solve an enrolment problem — without ever being revisited as the threat landscape evolved.
In our red team assessments, we routinely encounter misconfigured ADCS services, which we go on to abuse during the exercise — either for privilege escalation or for persistence.
In our experience, it is not uncommon to find certificate templates open to any domain user. Some of these templates can lead directly to full domain compromise. For example, ESC1 may allow a standard user to request a certificate on behalf of a privileged account.
How Active Directory Exploitation Uses ADCS
Understanding the operational risk means understanding attacker decision-making, not just the technical mechanics.
From Initial Access to Certificate Abuse
Once attackers establish an initial foothold, they begin enumerating the environment. That foothold may come from phishing, compromised credentials, or lateral movement from a perimeter system. In many environments, that initial access begins with stolen credentials rather than sophisticated exploitation. As we explored in our article on modern credential theft, compromising identities has become a preferred entry point because it allows attackers to blend into legitimate authentication activity long before they begin abusing services like ADCS.
ADCS is attractive for a specific reason: it offers a path to persistent, high-privilege access that operates through the same trust mechanisms the organisation relies on for legitimate authentication. An attacker abusing a misconfigured certificate template isn’t exploiting a bug. They’re using the enrolment system exactly as it was designed to work — they’re just not supposed to be the one using it.
This reflects a broader trend we explored in our article on living-off-the-land attacks. Rather than deploying custom malware, adversaries increasingly abuse legitimate enterprise functionality that already exists inside the environment. ADCS applies that same philosophy to the identity layer, allowing attackers to weaponize trusted infrastructure instead of introducing obviously malicious tooling.
The most consequential abuse paths share a common structure. A certificate template allows requester-supplied subject information, meaning an enrolling user can specify whose identity the certificate should represent. Combined with enrolment permissions broader than intended, this lets a low-privileged attacker request a certificate that authenticates as a domain administrator. The domain accepts the certificate as valid and allows the attacker to use it for authentication without ever requiring the administrator’s password.
Why Certificates Survive Password Resets
What makes this operationally severe is persistence. Unlike a stolen password, a certificate isn’t invalidated by a password reset. This mirrors a pattern we explored in attacker persistence after remediation, where organisations remove the initial compromise but leave behind trusted authentication mechanisms that allow attackers to return.
Similar to stolen authentication tokens or trusted sessions, certificates represent another form of inherited trust that traditional incident response frequently overlooks. We examined this challenge in our article, Token Theft and Trusted Sessions, where inherited trust becomes the attacker’s greatest advantage.
Even after an organisation detects the compromise and rotates credentials—the most common immediate response—certificates issued before that event keep working until they expire or are explicitly revoked. In environments where certificate lifetimes run one, two, or even five years, that’s a significant window.
A Realistic Red Team Scenario
During one of our exercises, we landed in a network as a standard user. Upon enumerating ADCS, we identified a misconfigured certificate template that allowed us to escalate privileges. We requested the vulnerable certificate as our standard user, issued on behalf of a more privileged one.
Using the acquired privileged certificate, we impersonated the associated privileged account and continued our progress. Some of that activity triggered alerts, and the blue team investigated. But they only revoked the account’s password — not the certificate. That blind spot let us maintain persistence on the account and keep moving, eventually reaching full domain compromise.
From Privilege Escalation to Domain Persistence
Beyond privilege escalation, ADCS abuse also supports domain persistence. An attacker with temporary domain administrator access can use it to create certificate-based backdoors capable of regenerating administrative credentials indefinitely. Certipy is the primary open-source framework used to enumerate and abuse ADCS by both red teams and threat actors. Forged certificates can authenticate as any domain principal, including krbtgt, allowing persistence even after a full domain password reset. These techniques are particularly difficult to detect because they abuse legitimate Certificate Authority (CA) infrastructure rather than relying on novel malicious tooling.
Common ADCS abuse conditions observed in enterprise environments:
- Certificate templates configured to allow Subject Alternative Name specification by the enrollee
- Enrolment permissions granted to broad groups (Domain Users, Authenticated Users) without business justification
- Certificate Authority configurations that allow manager approval to be bypassed
- Absence of certificate revocation infrastructure or CRL monitoring
- No audit logging on enrolment or issuance events
How Attackers Assess ADCS Exposure
In our engagements, identifying the Active Directory services in use — especially ADCS — is one of the first tasks during the situational awareness phase. As above, ADCS can be a quick win from an attacker’s perspective.
Practically, we’d enumerate whether certificate authorities and templates are present and enabled. If they are, the next step is determining whether the current setup is vulnerable in any of the documented ways affecting certificate authorities and templates. When we identify a vulnerable component, we assess whether it is exploitable from our current foothold. We also determine whether it supports the exercise objective. Depending on the scenario, that objective may be privilege escalation or persistence.
Where Active Directory Exploitation Opportunities Hide
Dormant Templates Still Create Active Risk
One consistent finding from enterprise offensive security engagements: ADCS misconfigurations frequently exist in certificate templates that are no longer actively used but were never decommissioned. These dormant templates retain their enrolment permissions and configurations, which means they stay exploitable even though no legitimate business process depends on them.
That’s a meaningful distinction. Organisations can’t remediate exposure they aren’t aware of, and there’s no automated process that identifies and retires misconfigured templates on their behalf. The exposure simply accumulates, silently.
ADCS Expands the Hybrid Identity Surface
Hybrid environments add further complexity. As organisations extend Active Directory into Azure and integrate cloud identity through Entra ID (formerly Azure AD), the trust surface expands with them. Certificate-based authentication paths that exist on-premises may have implications in cloud-connected environments, depending on federation configuration. The attack surface is no longer cleanly bounded at the domain boundary the way it might have been five or ten years ago in a fully on-premises environment.
How On-Premises Certificate Abuse Reaches the Cloud
With the rise of hybrid environments — the coupling of AD and Entra ID — more complex attacks become possible. Consider an attacker seeking access to a specific cloud-connected resource owned by a hybrid user (an AD user synced with an Entra ID counterpart). By abusing a vulnerable certificate template to compromise that hybrid user’s on-premises identity, and then leveraging the sync relationship, the attacker can reach the cloud-connected objective. In this scenario, ADCS becomes both a shortcut and an accelerator. Without it, the attacker would likely need more steps and more complex techniques to reach the same objective.
Why Standard Monitoring Misses Certificate Abuse
There’s also a detection problem worth acknowledging directly. Windows logs certificate enrolment and authentication events. However, detecting abuse requires specific audit settings and correlation rules. Most security operations teams have not implemented them. A certificate enrolment event representing an attacker escalating to domain administrator looks, in the logs, identical to a legitimate enrolment — because from the CA’s perspective, it is one. Distinguishing malicious from authorised enrolment requires contextual correlation that standard monitoring doesn’t provide out of the box. The joint guidance on detecting and mitigating Active Directory compromises was co-authored by the NSA, CISA, and allied agencies. It identifies the event IDs, CA audit settings, and correlation logic required to detect abuse. Few organisations establish this baseline before an incident forces them to do so.
Why Remediation Assumptions Often Fail
Security teams that identify ADCS misconfigurations frequently run into a challenging operational reality: fixing them is more disruptive than it looks.
Hardening Can Disrupt Business-Critical Services
Certificate templates misconfigured for years may be relied upon by business processes that are poorly documented. Tightening enrolment permissions or disabling a template can break authentication for application services, VPN configurations, or internal tools that nobody clearly owns. Remediation requires understanding the blast radius of the change before making it — and that understanding often simply doesn’t exist.
Remediation Friction Benefits the Attacker
This creates a risk tolerance problem. The organisation knows the misconfiguration is exploitable. However, fixing it may require service disruption, application testing, and stakeholder coordination. Those costs are immediate and concrete, while the exploitation risk may still feel abstract. The result is a tracked finding that quietly ages in a remediation backlog, sometimes for years.
What organisations often underestimate is that sophisticated attackers are explicitly aware of this dynamic. Groups running long-duration intrusion campaigns — nation-state actors, advanced ransomware operators — invest time enumerating PKI infrastructure specifically because they understand certificate-based persistence is likely to survive an incident response event. The attacker is counting on the remediation friction most enterprises experience.
Revocation Alone Is Not Enough
The other failure mode is assuming revocation alone addresses the exposure. Even when an organisation revokes compromised certificates, persistence mechanisms that allow re-issuance — through domain backdoors established using certificate authority trust — may remain intact. Remediation that treats the symptoms without understanding the full exposure chain frequently leaves the underlying risk in place. The same joint guidance provides a structured baseline for CA hardening, template review, and enrolment governance. However, organisations must first understand their existing misconfigurations. A hardened target state is less useful when the current exposure has not been mapped.
Operational and Business Implications
The business consequences of ADCS exploitation extend well beyond the initial compromise.
An attacker who achieves domain administrator access through certificate abuse has, effectively, reached the operational control level of the enterprise. The scope of that access — file systems, backup infrastructure, communication platforms, financial systems, and SaaS environments with federated authentication — is bounded only by what’s connected to the domain. In most modern enterprises, that’s most of the organisation.
The persistence dimension compounds the exposure timeline. If an organisation’s incident response effort doesn’t specifically address certificate infrastructure — which most standard playbooks don’t — an attacker can re-establish administrative access after being evicted, using pre-positioned certificate material. This is a documented pattern in long-duration intrusion campaigns, where organisations believe they’ve resolved a compromise only to experience re-entry through a mechanism they never addressed.
Regulatory implications are relevant too. Frameworks including DORA, NIS2, and various data protection regulations increasingly require organisations to demonstrate that identity controls work as intended and that unauthorised access can be reliably detected. Certificate-based persistence that survives incident response creates a meaningful gap between what an organisation can demonstrate about its security posture and what’s actually true. The joint guidance was developed by the Australian Signals Directorate, CISA, NSA, and other allied agencies. It identifies certificate-based persistence as one of the most difficult compromise categories to detect and remediate fully.
Why Offensive Validation Reveals Active Directory Exploitation Risks
The core operational lesson of ADCS exploitation is straightforward: the risks that matter most are often the ones that have never been tested.
Organisations invest significantly in vulnerability management, endpoint detection, and perimeter security. Those investments are reasonable and defensible. But they don’t address the class of risk represented by ADCS misconfigurations, because that risk doesn’t surface through patch compliance reports, vulnerability scans, or CVE tracking. It surfaces when an attacker with network access enumerates the certificate infrastructure and finds an enrolment path that hands them domain administrator credentials in minutes.
The only way to know whether that path exists is to test the environment under adversarial conditions. An offensive security team can enumerate ADCS configurations as an attacker would. It can then map the realistic exploitation chain from initial access to persistence, rather than flagging template misconfigurations in isolation.
Red team engagements and adversary simulations can include a review of PKI infrastructure. This provides something vulnerability management programmes cannot: a realistic assessment of what an attacker can achieve with your level of network access. That’s a different, and more operationally meaningful, question than whether known CVEs are patched.
The organisations that manage this exposure well tend to share one characteristic: they’ve validated their assumptions rather than relied on them.
Operational Takeaways
For executive and security leadership:
- Treat ADCS as an identity risk, not just an infrastructure service. Certificate infrastructure warrants the same security attention as privileged account management and directory services hardening.
- Assume your ADCS environment has never been reviewed under adversarial conditions unless you have evidence to the contrary. Most haven’t been.
- Patch compliance and vulnerability scanning don’t address this exposure class. ADCS abuse is primarily a configuration and trust problem, not a CVE problem.
- Incident response playbooks should explicitly address certificate infrastructure. Credential rotation that doesn’t include certificate revocation and PKI review may leave persistence mechanisms intact.
- Remediation friction is a known attacker advantage. Sophisticated threat actors exploit the operational difficulty of PKI remediation by establishing certificate-based persistence specifically because they expect it to survive response efforts.
- Visibility requires deliberate configuration investment. Standard SIEM deployments don’t detect certificate-based authentication abuse without tuning to the PKI threat model.
A Quiet Question for Security Leaders
If your organisation experienced an intrusion today, and an attacker had been inside your certificate infrastructure for the past ninety days — would your current monitoring tell you?
If the honest answer is “we’re not sure,” that uncertainty is itself an exposure worth examining.
wizlynx group works with enterprise security teams to evaluate exactly this kind of question, through adversary simulation, red team engagements, and identity security assessments that reflect how modern attackers actually operate. If you’re reassessing your identity security posture or want to understand your exposure to Active Directory exploitation, we’d welcome the conversation.
FAQ
Is Active Directory exploitation only relevant to large enterprises?
No. ADCS is deployed across organisations of all sizes running Windows Server environments with Active Directory. The misconfigurations that enable exploitation aren’t size-dependent — they reflect how the service was configured at deployment and how it’s been managed since. Mid-market organisations with smaller security teams may actually face higher exposure, since PKI infrastructure tends to receive less regular review in the absence of a dedicated identity security function.
Does patching Windows Server address ADCS exploitation risk?
Partially, and often not for the highest-impact scenarios. Microsoft has released patches addressing specific ESC-class vulnerabilities, but most ADCS abuse paths described in the research literature are configuration and trust issues rather than software defects. A fully patched ADCS environment can still be exploitable through template misconfiguration and enrolment permission abuse. Patch management is necessary but not sufficient.
How do attackers find ADCS misconfigurations?
Using the same enumeration tooling security teams and red teamers use. Manual or automated enumeration — with tools like Certipy — lets an attacker query certificate services for exploitable template configurations, enrolment permission issues, and CA vulnerabilities from a standard domain user account. This enumeration is fast, low-noise, and doesn’t require elevated privileges to perform initial discovery. An attacker with domain user credentials can typically map exploitable ADCS conditions within minutes of gaining access. The fact that defenders use the same tooling is instructive: the visibility an offensive team builds during an assessment is the visibility that was previously absent.
Can our SIEM detect ADCS abuse?
Possibly, but only with deliberate configuration. Out-of-the-box SIEM deployments and standard Windows event logging don’t generate or correlate alerts for the specific enrolment and authentication patterns that indicate ADCS abuse. Detecting certificate-based privilege escalation and persistence requires specific audit policy configuration on the CA, custom detection logic, and familiarity with what malicious enrolment activity looks like compared to a normal baseline. Most organisations haven’t implemented this.
What does remediation actually require?
Effective ADCS remediation requires a structured review of all certificate templates — including inactive ones — to identify misconfigured enrolment permissions and subject specification settings; audit and hardening of CA configuration; assessment of certificate lifetimes and revocation infrastructure; and integration of CA audit logging into detection workflows. The joint NSA/CISA/ASD guidance on ADCS hardening provides a useful configuration baseline, but applying it to an environment with years of accumulated misconfiguration means first understanding what’s currently exploitable, not just what the hardened state should look like. Where specific templates are actively exploitable, remediation also requires evaluating whether certificates already issued through those templates should be treated as potentially compromised and revoked. This is operationally complex, which is why organisations benefit from having the exposure fully mapped before attempting remediation.
What’s the difference between an ADCS review and a full red team exercise?
An ADCS security review focuses specifically on PKI configuration, template permissions, CA settings, and certificate abuse paths — a targeted assessment that identifies exploitable conditions and maps remediation priorities. A red team exercise simulates the full adversary lifecycle, from initial access through privilege escalation, lateral movement, and persistence, using ADCS exploitation as one of several potential attack paths. Both are valuable; the right scope depends on whether the organisation wants focused PKI assurance or a broader validation of resilience against realistic adversary behaviour.
How often should ADCS environments be reviewed?
At minimum, when the environment undergoes significant change — domain restructuring, hybrid identity integration, major application deployments — and following any security incident involving identity or credential compromise. Proactively, an annual offensive assessment of the identity environment, including ADCS, reflects reasonable security hygiene for organisations where Active Directory is a critical dependency. Organisations operating under NIS2, DORA, or similar regulatory frameworks may have more specific obligations around identity security validation.
This article was co-authored with Raphaël Naegert, Senior Security Consultant and Red Teamer at wizlynx group. Raphaël specialises in offensive security, with a focus on assessing the security of organisations from different angles. This includes focused assessments, such as web application security testing, and broader engagements, such as end-to-end Red Team exercises. His work is centred on playing the devil’s advocate by challenging assumptions to identify vulnerabilities, weaknesses, and flaws. He has contributed to security assessments and adversary simulation engagements across industries, including the financial sector and other highly sensitive sectors.
wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specialises in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.