AD CS Containment: Follow the Certificate, Not the Password

In a hypothetical incident handoff, the workstation-isolation task is already closed. The user’s password has been reset. Then a domain controller records another successful TGT request with certificate information populated. The analyst has to stop treating the password as the only credential that matters. Event 4768 provides the certificate fields needed to investigate that distinction.^[8]

This is the uncomfortable part of AD CS certificate containment: the response team can finish its familiar account-recovery checklist while an independently issued credential remains outside it. Microsoft’s October 30, 2026 investigation describes two intrusions that moved from help desk impersonation and remote access into AD CS abuse. The useful follow-up is not another enrollment walkthrough. It is deciding what evidence actually closes the certificate-backed path.^[1]

Follow the identity conversion

Microsoft observed different certificate paths after a similar initial foothold. One incident involved ESC1 template abuse and DCSync; another relayed a domain controller’s NTLM authentication to Web Enrollment, obtained a domain-controller certificate, and used PKINIT. Those are observed outcomes, not a claim that every modern domain permits either path.^[1]

For an operator, the important transition is from access to a workstation into possession of a credential usable as a different identity. For a responder, start a separate evidence record at that transition: issuing CA, request ID, certificate serial, requester, intended identity, template, validity period, and observed authentication. Preserve the actual certificate when available. A screenshot of an enrollment tool is a poor substitute for its issued artifact.

The same discipline applies to the identity and trust-boundary model: track which authority creates the credential and which service later accepts it. An endpoint alert describes one location in that graph. It does not describe the entire authorization path.

Separate issuance from successful authentication

Legacy ESC1 demonstrations often jump from a requester-supplied UPN to an administrator identity. That shortcut is unsafe analysis in 2026. Microsoft’s KB5014754 distinguishes strong mappings and the certificate SID extension from weak name-based mappings. Its enforcement timeline ended support for the compatibility registry override with the September 9, 2025 updates.^[3]

Inspect the certificate’s extensions, the relevant mapping, and the actual DC update state. Successful enrollment proves issuance; it does not prove that a particular KDC accepted the intended privileged identity. Conversely, a failed mapping attempt does not make a permissive template acceptable. It can leave another authentication consumer or deployment state untested. Record those as separate findings rather than inferring a domain-wide result from a single tool message.^[3]

ESC8 requires a different question: which identity authenticated to which enrollment endpoint, from which source? Build the comparison from CA records and network context. A machine identity appearing from an unexpected workstation is a hypothesis worth testing, not an automatic conviction. Proxies, enrollment services, and legitimate management systems need to be accounted for before escalation.

For the HTTP enrollment path, KB5005413 recommends EPA, with Required as the stronger option, and disabling HTTP through the SSL requirement. It also covers reducing NTLM where feasible. HTTPS alone is not a substitute for the documented relay protections. Nor does enabling SMB signing establish that an IIS enrollment endpoint has EPA configured correctly. Validate each enabled role and its effective configuration.^[2]

Close three different states

First, stop replacement issuance. Restrict the abused template or enrollment route with the PKI owner, preserving the prior configuration and the incident evidence. Test that the same unauthorized enrollment condition is now denied using an approved nonproduction identity. Avoid indiscriminately shutting down a CA that also supports critical machine authentication.

Second, revoke the right certificate and deliver that decision. Microsoft separates the CA database action, CRL publication, transfer, and retrieval. A successful certutil -CRL operation does not prove that the distribution endpoint serves the new bytes. Existing certificates also retain their embedded CDP URLs; changing the CA configuration does not rewrite them.^[4]

Third, investigate access already obtained. Certificate revocation and Kerberos-ticket containment are separate tasks. A password reset or workstation rebuild does not revoke an issued certificate or invalidate tickets already issued, a distinction Microsoft explicitly calls out in its investigation. Preserve the ticket-use timeline and contain affected identities, devices, and resource sessions through the relevant response procedures.^[1]

Assign an owner and a verification result to each state. “Template fixed” must not silently become “certificate unusable.” “Certificate rejected” must not become “all resource access terminated.” That separation also makes the business decision clearer: the PKI team can measure enrollment impact while incident command assesses whether privileged access remains active.

Test what the relying party consumes

Revocation is partly a distribution and cache problem. Microsoft’s Windows path-validation guidance describes time-valid CRLs and OCSP responses in Cryptnet caches, including the identity context that retrieved them. It explicitly warns against assuming every application uses the same validation logic. A successful test from an administrator’s desktop is therefore evidence about that test context, not proof about a domain controller or every application.^[6]

Use an authorized test host on the relevant network and compare normal access, a controlled clean-cache baseline, unreachable revocation endpoints, and a revoked test certificate. Record issuer retrieval separately from revocation retrieval. Do not weaken production revocation policy to make a test pass, and do not clear caches across the estate as an improvised incident-response experiment.^[6]

For a collected certificate, these administrative inspection commands are useful starting points. The second command retrieves URLs embedded in the certificate, so run it only from an approved analysis host after reviewing those destinations. They are not a PKINIT containment test.^[5]

certutil -dump incident.cer
certutil -verify -urlfetch incident.cer

For this article, an offline fixture used a disposable CA, one leaf certificate, and two signed CRLs. OpenSSL accepted the leaf against the first CRL, rejected it with error 23 against the CRL containing its serial, and accepted it again when explicitly given the earlier, still-valid CRL. The certificate itself did not change. The verification input did.^[9]

# Offline fixture files; no network service or domain required.
openssl verify -crl_check -CAfile ca.pem -CRLfile before.pem leaf.pem
# leaf.pem: OK
openssl verify -crl_check -CAfile ca.pem -CRLfile after.pem leaf.pem
# error 23 at 0 depth lookup: certificate revoked
openssl verify -crl_check -CAfile ca.pem -CRLfile before.pem leaf.pem
# leaf.pem: OK

This demonstrates CRL consumption, not an AD CS exploit, Windows cache behavior, or Kerberos-ticket invalidation. OpenSSL was given each CRL explicitly. Its result cannot establish how a production KDC retrieves or caches revocation data. The disposable fixture directory was removed after execution; no server or listener was started.

Build the correlation before writing the alert

On the CA, distinguish request receipt (4886), issuance (4887), and denial (4888). Also collect revocation and CRL-publication evidence appropriate to the configured audit scope. Microsoft’s CA administration guidance requires validating generation locally and delivery to the collector; forwarding does not enable auditing or prevent local log overwrite. A silent collector cannot prove that no certificate was issued.^[7]

On DCs, parse 4768 by named XML fields rather than positional indexes. Useful pivots include TargetUserName, IpAddress, Status, CertIssuerName, CertSerialNumber, and CertThumbprint. Microsoft documents newer event versions and the certificate-information fields. Check the schema and field population on your actual DC build before deploying a rule; an empty certificate field is not a universal proof that no certificate authentication occurred.^[8]

The detection proposal is a correlation, not a signature: a newly issued authentication certificate, an unusual enrollment source or requester relationship, and subsequent successful certificate-backed TGT activity for a sensitive identity. Join on issuer and serial where available, enrich with CA request records, and preserve the raw values before normalizing formatting. A serial number by itself is not a globally unique identifier.

Baseline legitimate smart-card use, enrollment infrastructure, and machine-certificate renewal first. Then prioritize mismatches that cross roles: a workstation source associated with a DC identity, an unexpected template for a requester, or certificate-backed activity after the incident’s stated containment time. Keep missing CA telemetry visible as an evidence gap rather than treating it as a negative result.

This is narrower than the device-trust problem around synced passkeys, but the response mistake is related: the credential’s lifecycle must be examined separately from the user’s current password. It also follows the evidence-gate approach used for generated fuzzing harnesses: define what a result proves before allowing it to close the next decision.

Make containment a falsifiable claim

Before declaring this path closed, the incident record should identify the issued credentials, show that the abused issuance condition is blocked, demonstrate rejection with current revocation data in the relevant relying-party context, and document how existing access was handled. If one of those tests is unavailable, state which access remains uncertain and who owns the next check.

A certificate serial, a CA disposition, and a failed authentication attempt answer different questions. Keeping them separate is less convenient than a single “account recovered” checkbox. It is also how the response team avoids closing the incident while a usable credential remains unexamined.

Sources and validation scope

Primary sources retrieved November 4, 2026. The lab tests only offline X.509 CRL consumption, not an AD CS deployment.

1. From help desk impersonation to AD CS abuse: Investigating ESC1 and ESC8 intrusion paths | Microsoft Security Blog
2. KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) | Microsoft Support
3. KB5014754: Certificate-based authentication changes on Windows domain controllers | Microsoft Support
4. Revoke Certificates and Publish CRLs in AD CS – Windows Server | Microsoft Learn
5. certutil | Microsoft Learn
6. Configure AIA and Path Validation in AD CS – Windows Server | Microsoft Learn
7. Secure, Delegate, Audit AD CS Administration – Windows Server | Microsoft Learn
8. 4768(S, F) A Kerberos authentication ticket (TGT) was requested. – Windows 10 | Microsoft Learn
9. openssl-verification-options – OpenSSL Documentation