Why do NTLM relay attacks against AD CS create such high privilege risk?

They let an attacker turn a coerced authentication into certificate issuance, then use that certificate to impersonate a machine or gain access as that identity. In a privileged environment, that can lead to directory secret theft, service ticket abuse, or domain compromise. The risk is not the relay alone, but the trust chain it can hijack.

Why the relay step becomes a privilege boundary, not just an authentication trick

ntlm relay against AD CS is dangerous because it can convert a momentary, coerced authentication into a durable credential-bearing artifact. Once a certificate is issued, the attacker is no longer limited to forwarding a challenge response, they can often authenticate later as the relayed identity and use that access across multiple systems. That is what turns a transport abuse into a high-impact identity event.

The reason this is so severe is that AD CS sits inside the trust fabric. Certificate issuance can inherit whatever authority the template and enrollment path allow, so the attacker may gain an identity proof that is stronger and longer-lived than the original NTLM exchange. In practice, that can bridge from a single reachable service to directory-level access if the issued certificate maps to a privileged machine or user context.

A useful way to think about it is that relay attacks exploit the gap between authentication and authorization. The relayed NTLM session proves reachability and responsiveness, while AD CS can turn that proof into an enterprise-trusted token. NHIMG’s Ultimate Guide to NHIs is a good companion for understanding why issued credentials, rotation, visibility, and overprivilege matter once an identity is transformed into reusable access material.

What makes AD CS the force multiplier in the attack path

AD CS becomes the force multiplier because certificate issuance can outlast the original network session and can be replayed in ways that simple NTLM forwarding cannot. If the template accepts the relayed identity and the resulting certificate is useful for authentication, the attacker has effectively upgraded a transient relay into a reusable authentication factor.

That upgrade matters most in privileged environments where the issued certificate can authenticate as a machine account, a service account, or another identity with broad directory reach. From there, the attacker can pursue directory secret theft, impersonation, service ticket abuse, or lateral movement with a level of persistence that makes containment much harder.

Real-world evidence shows how damaging credential or secret compromise can become once privileged identity material is exposed. NHIMG’s Cisco Active Directory credentials breach and BeyondTrust API key breach both illustrate the same core pattern, where one compromised trust anchor can create broad downstream access.

Risk and Threat Considerations

NTLM relay against AD CS is risky because it lets attackers hijack a trusted issuance path rather than break through a single account directly. The exposure rises sharply when templates, enrollment permissions, or certificate mappings allow the resulting certificate to authenticate as a highly privileged identity, because the attacker can pivot from one coerced connection to durable enterprise access.

Failure mechanism: The attack succeeds when a relayed NTLM authentication is accepted by AD CS and converted into a certificate that can be reused for authentication, especially where enrollment policies or template settings permit privileged identity mapping.

Impact: The attacker may gain persistent access as the mapped identity, enabling impersonation, directory secret access, service ticket abuse, or domain compromise, with blast radius determined by the privilege attached to the issued certificate.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Relay-to-certificate abuse converts authentication into reusable credential material.
	NHI-03 — Access Governance and Least Privilege	Privileged certificate mappings can grant excessive access after relay success.
	NHI-06 — Lifecycle and Rotation	Issued certificates create durable access that must be expired or revoked quickly.
Recommendation — Restrict certificate and credential issuance paths to reduce relay-to-authentication abuse. Limit certificate templates and mappings to the minimum identity privileges required. Enforce short-lived certificates and rapid revocation for abused issuance paths.
CIS Controls v8	6 — Access Control Management	AD CS relay risk depends on who can obtain and use privileged access paths.
	5 — Account Management	Attack impact is governed by the accounts and identities a certificate can impersonate.
Recommendation — Restrict enrollment and authentication paths to the smallest necessary access set. Review and remove unnecessary privileged account mappings and reuse conditions.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	The issue is a trust-chain failure in identity proofing and access enforcement.
Recommendation — Harden identity-to-certificate bindings and verify authentication pathways end to end.
MITRE ATT&CK	T1550 — Use Alternate Authentication Material	A relayed certificate becomes alternate material for authenticating as the victim identity.
	T1649 — Steal or Forge Authentication Certificates	AD CS abuse can forge or obtain certificates that enable persistent impersonation.
Recommendation — Detect and block reuse of issued certificates as alternate authentication material. Monitor certificate issuance and mapping paths for signs of forged or abused authentication certificates.

Practitioner Guidance

What to verify: Confirm which certificate templates accept enrolment from accounts that can be reached through relay paths, and check whether the resulting certificates can authenticate as machine or privileged identities. If you cannot explain exactly which identity a certificate can become, the control is not understood well enough to trust.

What to prioritise: Treat template hardening, enrollment restriction, and certificate mapping review as higher priority than broad network blocking alone. The practical question is not whether NTLM exists somewhere, but whether a reachable service can be converted into reusable authentication for a privileged identity.

Practitioner takeaway: The decisive risk is not NTLM relay by itself, it is relay plus a trust service that can mint long-lived, reusable identity proof, because that combination turns one coerced connection into a durable privilege path.