ESC8 in Active Directory Certificate Services

ESC8 is an Active Directory Certificate Services exposure involving HTTP-based certificate enrollment endpoints and NTLM relay. ESC8 exists when an attacker can relay NTLM authentication to an AD CS enrollment endpoint and obtain a certificate that may be useful for authentication. This matters because certificates can act like credentials. If an attacker can obtain a certificate for a user or computer account, that certificate may allow authentication as that identity, depending on the environment and certificate configuration.

ESC8 is especially important because it connects several high-impact areas:

NTLM relay
AD CS web enrollment
Certificate-based authentication
Extended Protection for Authentication
IIS authentication settings
Certificate templates
Domain controller authentication behavior

ESC8 is not only a certificate template problem. It is primarily about enrollment endpoints that accept relayed authentication.

What is ESC8?

ESC8 is a common security community label for an AD CS exposure where HTTP-based certificate enrollment endpoints can be abused through NTLM relay.

A typical ESC8 scenario involves:

AD CS web enrollment or enrollment web services are installed.
The enrollment endpoint accepts Windows authentication.
NTLM authentication is allowed.
HTTPS, channel protections, or Extended Protection for Authentication are not enforced correctly.
An attacker can coerce or capture NTLM authentication from a user or computer.
The attacker relays that authentication to the enrollment endpoint.
The endpoint issues a certificate based on the relayed identity.

Microsoft’s KB5005413 specifically addresses mitigation for NTLM relay attacks against AD CS and recommends protections such as disabling NTLM on AD CS IIS endpoints where possible and enabling Extended Protection for Authentication.

Why ESC8 matters

ESC8 matters because it can turn NTLM relay into certificate-based access. In a relay scenario, the attacker does not need to know the victim’s password. The attacker relays a live authentication attempt to another service. If the target service accepts the authentication and performs an action, the attacker benefits from the victim’s identity. With AD CS, the action may be certificate enrollment.

Potential impact may include:

Obtaining a certificate for a user account
Obtaining a certificate for a computer account
Authenticating as the relayed identity
Persistent access through certificate validity
Domain escalation if a high-value computer or privileged account is relayed
Abuse of certificate-based authentication paths
Compromise paths involving domain controllers, servers, or certificate authorities

The impact depends on which identity is relayed and which templates can be issued. A relayed low-privilege user may have limited impact. A relayed domain controller, certificate authority, server, or privileged admin account may be far more serious.

How ESC8 relates to NTLM relay

ESC8 is one specific way NTLM relay can become high impact. NTLM relay works by forwarding an authentication attempt from one connection to another service. The attacker does not need to crack the password. The value comes from making the target service accept the relayed authentication. In ESC8, the target is an AD CS enrollment endpoint.

A simplified flow looks like this:

An attacker causes a user or computer to authenticate.
The attacker receives the NTLM authentication attempt.
The attacker relays that authentication to an AD CS HTTP enrollment endpoint.
The enrollment endpoint accepts the authentication.
A certificate is requested for the relayed identity.
The attacker may use the certificate for authentication.

This is why ESC8 is often discussed alongside NTLM relay, SMB signing, LDAP signing, LDAP channel binding, and Extended Protection for Authentication.

AD CS enrollment endpoints involved in ESC8

ESC8 commonly involves HTTP-based AD CS enrollment services.

Important AD CS role services include:

Role service	Why it matters
Certificate Authority Web Enrollment	Provides a web interface for requesting certificates
Certificate Enrollment Web Service	Allows users and computers to enroll and renew certificates over HTTPS
Certificate Enrollment Policy Web Service	Provides certificate enrollment policy information

The older Web Enrollment interface is often associated with the /certsrv path in IIS. Microsoft documents Certificate Authority Web Enrollment as an AD CS role service for interacting with a CA through a web interface. The presence of these services does not automatically mean the environment is vulnerable. The risk depends on authentication settings, transport protections, EPA configuration, template availability, and whether the services are required.

Why web enrollment is sensitive

Web enrollment is sensitive because it exposes certificate enrollment through IIS.

That means several layers matter:

IIS authentication configuration
Whether NTLM is allowed
Whether HTTPS is required
Whether Extended Protection for Authentication is enabled
Whether the endpoint can issue authentication-capable certificates
Which templates are available
Who can enroll
Whether the service is still needed

A web enrollment endpoint may have been installed years ago for a legacy workflow and then forgotten. If it remains enabled and accepts NTLM without sufficient protections, it can become a high-impact relay target.

What is Extended Protection for Authentication?

Extended Protection for Authentication, often shortened to EPA, helps protect integrated Windows authentication by binding authentication to the intended service or channel. In the context of ESC8, EPA helps reduce the chance that relayed NTLM authentication will be accepted by an AD CS IIS endpoint. Essentially, EPA helps the service determine whether the authentication belongs to the connection and service it is receiving. This makes relay harder because the relayed authentication may not match the expected channel or service binding.

Why HTTPS matters

HTTPS is important because channel binding protections depend on TLS. For AD CS enrollment endpoints, HTTPS should be required where web enrollment services are used. Without proper transport protection, authentication and enrollment workflows may be exposed to additional risk.

However, HTTPS alone is not the same as EPA.

Control	What it provides
HTTPS	Encrypts the HTTP session
EPA	Strengthens integrated Windows authentication binding
Disabling NTLM	Removes NTLM relayability for that endpoint
Kerberos authentication	Reduces reliance on NTLM where configured correctly

For ESC8 risk reduction, HTTPS, EPA, and NTLM reduction should be reviewed together.

ESC8 vs ESC1

ESC8 and ESC1 are different AD CS risks, but they can overlap.

Risk	Main issue
ESC1	A certificate template allows dangerous enrollment behavior, such as requester-supplied identity information and authentication-capable certificates
ESC8	An HTTP enrollment endpoint can be abused through NTLM relay
Overlap	A relayed identity may request a certificate from a risky or authentication-capable template

ESC1 is mostly about template configuration. ESC8 is mostly about enrollment endpoint exposure.

Common ESC8 conditions

Common ESC8 exposure may involve:

Certificate Authority Web Enrollment installed
Certificate Enrollment Web Service installed
IIS Windows Authentication enabled
NTLM allowed
EPA not enabled or not enforced
HTTPS not required
Enrollment endpoint reachable by untrusted systems
Authentication-capable templates available
Broad enrollment permissions
Lack of monitoring for certificate requests
Legacy web enrollment services still enabled without a current business need

The highest risk usually comes from a combination of relayable authentication, reachable enrollment endpoints, and useful certificate templates.

How to identify AD CS web enrollment

Start by identifying where AD CS enrollment role services are installed.

On a suspected CA or enrollment server, run:

Get-WindowsFeature ADCS-Web-Enrollment, ADCS-Enroll-Web-Svc, ADCS-Enroll-Web-Pol

Relevant role services include:

ADCS-Web-Enrollment
ADCS-Enroll-Web-Svc
ADCS-Enroll-Web-Pol

If these are installed, review whether they are still required.

PowerShell: Find enterprise certificate authorities

Use this to identify enterprise CAs from Active Directory:

$ConfigNC = (Get-ADRootDSE).configurationNamingContext

Get-ADObject `
  -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKIEnrollmentService)" `
  -Properties dNSHostName, certificateTemplates |
  Select-Object Name, dNSHostName, certificateTemplates

This helps identify CA servers and the templates they publish.

PowerShell: Check installed AD CS services remotely

If you have a list of CA or enrollment servers, you can check installed role services remotely.

$Servers = @("CA01","CA02","PKI-WEB01")

Invoke-Command -ComputerName $Servers -ScriptBlock {
    Get-WindowsFeature ADCS-Web-Enrollment, ADCS-Enroll-Web-Svc, ADCS-Enroll-Web-Pol |
        Select-Object Name, DisplayName, InstallState
}

Review any server where web enrollment or enrollment web services are installed.

PowerShell: Review IIS Windows Authentication

On an AD CS web enrollment server, review IIS authentication configuration.

Import-Module WebAdministration

Get-WebConfigurationProperty `
  -Filter /system.webServer/security/authentication/windowsAuthentication `
  -PSPath "IIS:\" `
  -Name enabled

If Windows Authentication is enabled, review whether NTLM is allowed and whether EPA is configured.

PowerShell: Review IIS Windows Authentication providers

Import-Module WebAdministration

Get-WebConfigurationProperty `
  -Filter /system.webServer/security/authentication/windowsAuthentication/providers `
  -PSPath "IIS:\" `
  -Name Collection

If NTLM is listed as a provider, determine whether it is required. Do not remove NTLM without testing. Some legacy enrollment workflows may depend on it.

PowerShell: Review SSL requirement in IIS

Import-Module WebAdministration

Get-WebConfiguration `
  -Filter /system.webServer/security/access `
  -PSPath "IIS:\"

Review whether SSL is required for AD CS enrollment paths.

Common paths to review include:

/certsrv
/*_CES_*
/*CEP*

Exact paths may vary by installation.

GUI: Review IIS authentication settings

Open IIS Manager on the AD CS enrollment server.

Review:

Internet Information Services Manager
  Sites
    Default Web Site
      certsrv or CES/CEP application
        Authentication

Check whether:

Windows Authentication is enabled
Anonymous Authentication is disabled where appropriate
NTLM is present as a provider
Negotiate is present as a provider
Extended Protection is enabled
HTTPS is required
The endpoint is still needed

GUI: Review Extended Protection for Authentication

In IIS Manager:

Site or Application
  Authentication
    Windows Authentication
      Advanced Settings
        Extended Protection

Common EPA values include:

Off
Accept
Required

For sensitive AD CS enrollment endpoints, EPA should be reviewed carefully and tested before enforcement.

How to reduce ESC8 exposure

ESC8 mitigation usually involves reducing or protecting relayable authentication to AD CS enrollment endpoints.

Common remediation options include:

Remove AD CS web enrollment services if they are not required.
Disable NTLM for IIS on AD CS enrollment endpoints where feasible.
Require HTTPS.
Enable Extended Protection for Authentication.
Prefer Kerberos authentication where possible.
Restrict network access to enrollment endpoints.
Limit which templates are available for enrollment.
Remove unnecessary authentication-capable templates from issuing CAs.
Review enrollment permissions on published templates.
Monitor certificate requests and IIS logs.
Review whether legacy workflows still require web enrollment.

Microsoft’s KB5005413 lists disabling NTLM on AD CS IIS endpoints where possible and enabling EPA as mitigation options for NTLM relay attacks against AD CS.

Safe remediation workflow

Do not blindly remove enrollment services or change authentication settings without testing. AD CS may support VPN, Wi-Fi, smart cards, device certificates, application certificates, and non-domain enrollment workflows.

A safer workflow looks like this:

Identify all AD CS enrollment endpoints.
Determine which endpoints are still required.
Identify who uses each endpoint.
Review IIS authentication settings.
Review whether NTLM is enabled.
Review whether HTTPS is required.
Review EPA configuration.
Test changes in a non-production or limited scope.
Enable EPA where appropriate.
Disable NTLM where feasible.
Remove unused web enrollment services.
Monitor certificate enrollment and authentication failures after changes.

The goal is to reduce relay exposure without breaking legitimate certificate enrollment.

What not to overlook

ESC8 review should not stop at IIS settings.

Also review:

Which templates are published
Whether templates support authentication
Who can enroll
Whether domain controllers can be coerced to authenticate
Whether certificate requests are monitored
Whether certificates have long validity periods
Whether certificate revocation works as expected
Whether enrollment endpoints are reachable from unnecessary networks
Whether old AD CS role services are still installed

The endpoint is the relay target, but the certificate template determines what can be issued.

Detection opportunities

ESC8 detection should include authentication, certificate enrollment, and IIS activity.

Monitor for:

NTLM authentication to AD CS web enrollment servers
Certificate requests from unusual source systems
Certificate issuance involving machine accounts
Certificate issuance involving privileged users
Certificate requests shortly after coerced authentication indicators
Certificate requests from web enrollment endpoints
IIS logs for /certsrv or CES endpoints
Changes to IIS authentication settings
Changes to EPA settings
New AD CS enrollment role services
Templates newly published to CAs

Useful log sources include:

Source	Purpose
IIS logs	Web enrollment access and request patterns
CA logs	Certificate requests, issuance, failures, and denials
Security logs	Authentication and account activity
Directory Service logs	AD object and configuration changes
Defender for Identity	Certificate posture assessments and identity-related detections

Common mistakes

Assuming AD CS is safe because templates look fine

ESC8 is about enrollment endpoint exposure. Even if templates are reviewed, web enrollment services may still create relay risk.

Assuming HTTPS alone solves the issue

HTTPS is important, but EPA and NTLM configuration still matter.

Leaving web enrollment installed because it was always there

Old enrollment services are often forgotten. If they are not required, removing them may be safer than maintaining them.

Disabling NTLM without testing

Some environments still depend on NTLM for legacy workflows. Test before removing it from enrollment endpoints.

Ignoring machine accounts

Relayed computer authentication can be high impact, especially if the computer is a domain controller, certificate authority, server, or management system.

Not reviewing templates

The endpoint may enable relay, but templates determine what certificates can be issued.

Not monitoring certificate issuance

Certificate requests should be visible, especially for authentication-capable templates and sensitive identities.

Practical recommendation

A practical ESC8 review should include:

Identify all AD CS HTTP enrollment endpoints.
Confirm whether Web Enrollment, CES, or CEP are installed.
Determine whether each endpoint is still needed.
Review IIS Windows Authentication settings.
Determine whether NTLM is enabled.
Require HTTPS where enrollment services remain in use.
Enable Extended Protection for Authentication where appropriate.
Disable NTLM for AD CS IIS endpoints where feasible.
Restrict network access to enrollment endpoints.
Review published templates.
Review authentication-capable templates.
Monitor certificate requests and IIS logs.
Remove unused AD CS web enrollment services.

Summary

ESC8 is an AD CS exposure where vulnerable HTTP-based certificate enrollment endpoints can be abused through NTLM relay. The attacker does not need to crack a password. The attacker relays authentication to an enrollment endpoint that accepts it and may obtain a certificate for the relayed identity. The most important controls are reducing NTLM exposure, requiring HTTPS, enabling Extended Protection for Authentication, removing unused web enrollment services, restricting access, reviewing published templates, and monitoring certificate requests.

ESC8 is important because it turns certificate enrollment into a relay target. In environments where certificates can be used for authentication, that can create serious impersonation, persistence, and privilege escalation paths.