What happens when NTLM relay reaches Active Directory Certificate Services?

Why NTLM Relay Becomes More Dangerous at AD CS

ntlm relay is already a trust-abuse problem, but AD CS raises the stakes because certificate issuance can turn a relayed authentication into a reusable credential. If the web enrollment path accepts the relayed context, the attacker is no longer limited to the original network session. They can often move from short-lived access to a certificate-backed authentication path that persists beyond the relay window.

This matters because certificate issuance is not just another authorization event. It can create a new identity token with broader reach, especially when templates allow client authentication or when CA settings are too permissive. The risk is not theoretical: machine identity failures are common, and NHI research shows only 5.7% of organisations report full visibility into service accounts, which makes abuse paths harder to notice and contain.

In practice, teams often discover the impact only after a relayed authentication has already been converted into durable access through certificate enrollment.

How Relay Abuse Works Once Enrollment Is Available

When an AD CS web endpoint accepts NTLM relay, the attacker positions themselves as the authentication intermediary and forwards the victim’s NTLM exchange to the certificate service. If the enrollment page or interface does not require protections such as EPA, strict channel binding, or other hardening, the service may accept the relayed identity as legitimate.

That acceptance can let the attacker request a certificate under the relayed account or computer context. If the issued certificate supports Kerberos logon or certificate-based authentication, the attacker can then authenticate without repeatedly relaying NTLM. That shift matters because it changes a one-time interception opportunity into a longer-lived credential path.

• Web enrollment is the usual choke point because it often sits at the boundary between legacy authentication and certificate issuance.
• Template design determines whether the issued certificate is narrowly useful or broadly abusable.
• CA policy determines whether low-friction enrollment becomes a direct path to privileged access.

Environment details matter. If templates require subject alternative name control, client authentication EKUs, or enrollee-supplied subject data, the blast radius can expand beyond the relayed principal. If certificate mapping is permissive, the certificate can be used in places the original NTLM session never reached. NIST SP 800-53 Rev. 5 is useful here because it frames the need to control authentication, access enforcement, and certificate-related trust decisions at the system boundary. NIST SP 800-53 Rev 5 Security and Privacy Controls The NHI lifecycle angle is equally important because certs are machine-bound credentials that need visibility, ownership, and revocation discipline; NHIMG guidance on non-human identities helps frame that operational reality. Ultimate Guide to NHIs — What are Non-Human Identities

These controls tend to break down when legacy enrollment services are exposed broadly and certificate templates are treated as infrastructure defaults rather than privilege-bearing trust objects.

Where the Abuse Pattern Changes, and What Teams Miss

Tighter certificate controls can reduce flexibility for legitimate enrollment, so organisations have to balance service usability against abuse resistance. The main trade-off is that convenience features in AD CS often make relay exploitation easier than teams expect, especially in mixed legacy environments.

There is no universal standard for every AD CS deployment pattern, but current guidance suggests treating any certificate issuance path that accepts network authentication as a high-value trust boundary. The practical difference is whether the issued certificate is scoped narrowly to the intended workflow or can be repurposed for authentication elsewhere. Permissive templates, weak mapping rules, and broad enrollment permissions are the combinations that turn a local relay into broader domain exposure.

A common mistake is focusing only on the relay itself and ignoring the post-issuance chain. The actual problem is not just intercepted NTLM; it is the credential conversion step that follows. That is why certificate inventory, template review, and revocation speed matter as much as endpoint hardening. The organisation must be able to answer which identities can enroll, which templates they can reach, and how quickly an abused certificate can be invalidated.

Practitioners should also remember that certificate-based access often outlives the original incident window. If the environment lacks ownership, logging, or fast revocation, the abuse can persist quietly even after the relay vector is closed.

Risk and Threat Considerations

The material risk is credential transformation: relay does not merely authenticate a session, it can be used to mint a new certificate-backed identity if AD CS enrollment is reachable and insufficiently protected. That creates a durable access path that is harder to detect than the original NTLM exchange.

Failure mechanism: The attacker relays NTLM to a certificate enrollment endpoint, abuses weak endpoint protections or permissive templates, and obtains a certificate that can authenticate through Kerberos or certificate mapping. The abuse becomes more severe when enrollment permissions, template EKUs, or mapping rules allow reuse beyond the original principal.

Impact: A short-lived relay can become longer-lived domain access, potentially extending to broader account impersonation, persistence, and lateral movement if the issued certificate is trusted for authentication.

Practitioner Guidance

What to verify: Confirm whether any AD CS web enrollment or certificate issuance path accepts NTLM and whether protections such as EPA and strict channel binding are actually enforced on the reachable endpoint, not just documented.

What to prioritise: Review templates and enrollment rights before chasing only relay detection. If a template can issue authentication-capable certificates to a relayed identity, treat that as a credential issuance issue, not a narrow web flaw.

Decision rule: If an issued certificate can authenticate to domain services, prioritise template restriction, mapping hardening, and revocation readiness immediately; if it cannot, the risk is still real but the blast radius is more constrained.

What practitioners underestimate: The highest-risk condition is often ordinary-looking enrollment convenience combined with broad trust mapping. That combination makes the abuse path look administrative until it is used for persistence.

Practitioner takeaway: The key question is not whether relay succeeded once, but whether it produced an authenticated credential that the attacker can keep using after the original relay session is gone.

Related resources from NHI Mgmt Group

• How should security teams reduce NTLM relay risk in Active Directory?
• Why does Active Directory Certificate Services increase identity risk?
• What breaks when Active Directory Certificate Services templates are too permissive?
• How should security teams harden certificate templates to prevent ESC1 abuse in Active Directory Certificate Services?