CVE-2026-54121 Certighost — AD CS Certificate Abuse and Domain Privilege Risk

Microsoft disclosed CVE-2026-54121 on July 14, 2026, as an improper authorization vulnerability in Active Directory Certificate Services. The formal Microsoft CNA rating is CVSS 8.8 High, with network reachability, low privileges required, no user interaction, and high impact to confidentiality, integrity, and availability. Ten days after the security update, researchers H0j3n and Aniq Fakhrul published technical details and a working proof of concept under the name Certighost. In their tested AD CS configuration, a low-privileged domain user could induce a certification authority to issue a certificate that authenticated as a domain controller, creating a path toward complete domain compromise. (NVD)

The dangerous part is not simply that an attacker could request a certificate. Certificate enrollment is an expected function of an enterprise public key infrastructure. The failure occurred because the CA accepted requester-controlled information about where it should obtain authoritative directory identity data. A host controlled by the attacker could be treated as the directory source for a sensitive identity lookup before the CA had established that the host was a legitimate domain controller.

That distinction makes CVE-2026-54121 different from many familiar AD CS findings. It does not depend on an administrator deliberately enabling a certificate template that lets users supply arbitrary subjects. It is not merely an enrollment ACL mistake. It is not a web enrollment relay by itself. The underlying problem was a broken authorization decision inside the CA’s directory-resolution fallback.

The July update changes that decision. Based on the researchers’ reverse engineering of the patched Windows binary, the CA now checks whether a requester-provided chase target is represented in Active Directory as a real domain controller and adds an identity consistency check before accepting the lookup result. (Gist)

The operational conclusion is straightforward: every organization running an affected Microsoft Enterprise CA should verify the July 2026 update on the CA host, investigate historical certificate requests that contain the relevant chase attributes, and treat evidence of a successfully issued domain controller certificate as a potential domain-compromise incident rather than a routine PKI anomaly.

CVE-2026-54121 at a glance

الحقل	Confirmed information
مكافحة التطرف العنيف	CVE-2026-54121
Researcher name	Certighost
Affected component	Active Directory Certificate Services
الضعف	CWE-285, Improper Authorization
Microsoft CNA score	CVSS 3.1, 8.8 High
ناقل الهجوم	Network
Privileges required	منخفضة
User interaction	لا يوجد
Authentication requirement	A valid domain identity or equivalent authorized foothold is required in the demonstrated chain
Primary security failure	The CA followed requester-controlled directory-routing information without first proving the target was a domain controller
Potential result	A CA-signed certificate mapped to a domain controller identity
Downstream impact	Kerberos authentication as the domain controller and potentially domain-wide compromise
Microsoft update date	July 14, 2026
Public technical disclosure	July 24, 2026
Public PoC	Available
Confirmed exploitation in the wild	No confirmed public reports were identified in current reporting reviewed on July 27, 2026
الإجراء الموصى به	Patch every affected CA, verify the protected behavior, hunt historical requests, and investigate any suspicious issuance

The CVE record describes the issue more narrowly as improper authorization in AD CS that allows an authorized attacker to elevate privileges over a network. Microsoft’s vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, and the assigned CWE is CWE-285. The full domain-takeover path comes from the researchers’ demonstrated configuration and should not be confused with a claim that every affected Windows installation is automatically exploitable in exactly the same way. (NVD)

The disclosure-day CISA SSVC data recorded exploitation as “none,” automatable as “no,” and technical impact as “total.” That assessment was timestamped before the researchers published their working PoC on July 24. It remains useful as a historical record, but it should not be treated as a current statement that exploit code is unavailable. (NVD)

Current reporting states that the PoC is public but that no in-the-wild exploitation had been publicly confirmed at the time of publication. Those are separate questions. A public PoC materially lowers the cost of reproduction, while confirmed exploitation requires independent evidence of malicious use. Defenders should not wait for the second condition before patching a Tier 0 certificate authority. (مساعدة صافي الأمان)

Why an AD CS bug can become a domain compromise

Active Directory Certificate Services is Microsoft’s implementation of enterprise public key infrastructure. An Enterprise CA integrates with Active Directory, publishes information about itself and its certificate templates, accepts enrollment requests, retrieves directory attributes, and signs certificates that are trusted throughout the environment.

That signing authority has consequences far beyond HTTPS.

A certificate can be used to authenticate a person, workstation, server, service, smart card, VPN client, management endpoint, or domain computer. The exact capability depends on the certificate’s enhanced key usages, policy, identity extensions, template, and the relying service. When a certificate is valid for client authentication, Windows can use it in Kerberos PKINIT to request a ticket-granting ticket from a domain controller.

The simplified trust chain is:

The requester controls a private key.
The CA signs a certificate containing a public key and identity information.
The domain trusts the issuing CA.
The KDC maps the certificate to an Active Directory principal.
The requester proves possession of the private key.
The KDC issues Kerberos credentials for the mapped principal.

The KDC does not need to know whether an attacker deceived the CA during issuance. It evaluates the certificate presented to it, the issuing chain, the applicable mapping data, and its configured certificate-authentication policy. If the certificate contains identity information that strongly maps to a domain controller account and the certificate was signed by a trusted enterprise CA, the KDC may be behaving exactly as designed when it accepts the certificate.

This is why the CA is part of the domain’s identity control plane. Compromising a CA private key is one obvious way to abuse that control plane, but it is not the only way. If an attacker can make a legitimate CA sign an illegitimate identity, the resulting certificate can carry much of the same trust as one issued through a valid workflow.

The CA therefore has at least three separate duties:

It must authenticate the requester.
It must authorize the requested operation.
It must obtain identity data from an authoritative source and bind the correct identity to the certificate.

CVE-2026-54121 broke the third duty through a failure in the second. The attacker was allowed to influence the route used for an authoritative identity lookup without being authorized to designate an arbitrary host as a domain controller.

That is not merely input validation. The security question was not only whether the cdc value looked like a syntactically valid hostname. The security question was whether the named system was authorized to act as a domain controller and return identity data that would influence certificate issuance.

Normal certificate enrollment and where directory data enters

In a typical machine enrollment flow, a domain computer generates a key pair and submits a certificate request to an Enterprise CA. The request references a certificate template that defines properties such as intended purpose, cryptographic requirements, validity period, subject construction rules, approval requirements, and enrollment permissions.

The CA does not blindly copy every string from the request into the certificate. Depending on the template and policy module, it may retrieve information from Active Directory, derive the certificate subject, add identity extensions, verify template permissions, and enforce issuance policy.

Microsoft’s Web Certificate Enrollment protocol specification explicitly supports certificate request attributes. The client can submit named attributes alongside the request, and the CA can use them while processing the enrollment. Request attributes are separate from signed certificate extensions: they are inputs to the CA’s policy and processing logic, not automatically trusted identity claims merely because they appear in a request. (مايكروسوفت تعلم)

In some scenarios, the CA may need to query a domain controller specified by the client. Microsoft’s protocol documentation describes a search operation in which DCName is the fully qualified domain name of a domain controller provided by the client, prefixed with backslashes. The CA uses that connection to retrieve Active Directory attributes for an end entity. (مايكروسوفت تعلم)

That capability has legitimate reasons to exist. Large Windows environments may contain multiple domains, domain controllers, sites, trust relationships, replication states, and enrollment paths. A CA may need to continue an identity lookup against a different directory endpoint when the first lookup cannot resolve the object locally.

The existence of a client-provided DC name is therefore not automatically a vulnerability. The vulnerability appears when the CA treats the supplied target as authoritative without proving that the target is actually a domain controller permitted to answer that question.

The chase fallback

The researchers refer to the affected behavior as a chase. During directory-object resolution, the CA may reach a condition in which it needs to continue or repeat a lookup through another directory endpoint.

Two request attributes are central to the disclosed path:

cdc, or Client DC, identifies the host the CA should contact.
rmd, or Remote Domain, identifies the principal the CA should resolve.

When both are present in the vulnerable flow, the CA contacts the host identified by cdc over SMB and LDAP-related paths and searches for the principal identified by rmd. The researchers’ packet capture showed the CA following the requester-controlled target and interacting with services hosted by the attacker. (Gist)

How Certighost Corrupted the AD CS Directory Lookup

Try AI Pentesting Tool Free >>

The attacker did not need to steal the CA’s private key. The CA itself signed the resulting certificate. The attacker’s objective was to corrupt the identity-resolution input used before that signature was created.

Authentication was mistaken for authority

One of the most important lessons from Certighost is the difference between proving that a host has some valid domain identity and proving that the host is a domain controller.

A member workstation can be a valid domain principal. It may have:

A computer object in Active Directory.
A machine-account password.
Service principal names.
The ability to perform Kerberos or NTLM authentication.
A DNS hostname associated with its computer object.

None of those properties grants it authority to answer directory questions on behalf of the domain.

A domain controller has additional security-significant characteristics. Its computer object is marked as a server trust account, it participates in directory replication, it hosts directory services, and it belongs to the set of systems that the domain recognizes as authoritative for Active Directory data.

The vulnerable chase path allowed the CA to cross that boundary incorrectly. Requester-controlled routing information could lead the CA to a host that was capable of participating in Windows authentication but was not authorized to function as a domain controller.

This is why reducing the issue to “the CA did not validate a hostname” is incomplete. Hostname validation is part of the fix, but the central flaw was role authorization. The CA needed to establish that the target was an AD-registered domain controller before accepting identity data from it.

How identity data became a certificate

The researchers demonstrated that an attacker-controlled directory service could return attributes associated with a chosen target, including identity material such as objectSid و dNSHostName. The vulnerable CA then used the returned data while constructing the certificate. (Gist)

Those attributes matter because Windows certificate authentication is not based only on a human-readable subject string. Modern domain controllers consider several mapping mechanisms when connecting a certificate to an account.

Microsoft’s protocol documentation classifies mappings such as SAN UPN, SAN DNS, issuer-and-subject, subject-only, and RFC 822 values as weak mappings because they depend substantially on names. Strong mappings include SID, key trust, issuer and serial number, subject key identifier, a public-key hash, and issuer-plus-SID mappings. (مايكروسوفت تعلم)

For SID-based mapping, Microsoft states that if a certificate contains a SID and that SID matches the account to which the certificate is otherwise mapped, the certificate is considered strongly mapped. If the SID does not match, authentication must fail with KDC_ERR_CERTIFICATE_MISMATCH. (مايكروسوفت تعلم)

That mechanism was introduced to make certificate authentication safer. Microsoft’s KB5014754 guidance followed vulnerabilities including CVE-2022-26923, CVE-2022-26931, and CVE-2022-34691 and moved Windows domains toward stronger certificate-to-account binding. Enterprise CAs began adding a SID security extension to certificates, and domain controllers progressively enforced stronger mappings. (Microsoft Support)

Certighost illustrates an important limitation of downstream hardening: a strong mapping is only as trustworthy as the identity data placed into the certificate.

If the CA correctly obtains Alice’s SID and issues Alice a certificate, SID mapping helps prevent a name-collision attack from turning that certificate into Bob’s identity.

If the CA is deceived into obtaining a domain controller’s SID for an attacker-controlled key, the KDC sees a certificate with a strong domain controller mapping. The KDC’s stricter behavior does not repair the upstream issuance failure. It may make the resulting malicious certificate more reliable because the incorrect identity is now represented using a strong identifier.

Strong mapping answers:

Does this certificate contain identity data that strongly corresponds to this Active Directory object?

It does not answer:

Was the CA’s process for obtaining that identity data authorized and trustworthy?

CVE-2026-54121 lived in the second question.

The demonstrated attack chain

From Low-Privilege Domain Access to Domain Controller Identity

Try AI Pentesting Tool Free >>

The public research includes a complete exploit chain. Reproducing the researchers’ commands, rogue service implementation, credential extraction steps, or replication commands is unnecessary for defensive understanding and would make the material substantially easier to misuse. The important security decisions can be described without providing a production-ready exploit.

The demonstrated chain can be divided into eight stages.

An attacker obtains a low-privileged domain account

The issue is not described as an unauthenticated internet vulnerability. The Microsoft vector requires low privileges, and the research starts with an ordinary domain user. That foothold could come from phishing, credential theft, malware on a member workstation, an exposed remote-access service, a contractor account, or another post-compromise path.

Network access also matters. The attacker must be able to reach the relevant AD CS enrollment interface and interact with domain services needed for the chain.

The attacker obtains a usable machine identity

In many default Active Directory deployments, the ms-DS-MachineAccountQuota value allows an authenticated user to add a limited number of computer accounts to the domain. Microsoft documentation describes a default quota of 10 workstations, although organizations can change it or delegate computer-object creation through other permissions. (مايكروسوفت تعلم)

The researcher PoC created a machine account and registered the service identities needed for its controlled host. The machine account gave the attacker a legitimate domain principal that could participate in the authentication exchanges used by the CA.

The machine account was an enabling condition, not the core vulnerability. An attacker who already controls a machine account, has delegated computer-creation rights, compromises an existing workstation account, or obtains another suitable domain identity may not depend on the default quota.

The attacker prepares a controlled directory responder

The controlled host must answer the CA’s network interactions in a way that allows the chase to proceed. The public PoC implemented the necessary LDAP and LSA-related services and coordinated authentication with the legitimate environment.

The important defensive point is that the CA made outbound connections to a host chosen through the request. That behavior creates valuable network telemetry even when certificate request auditing is incomplete.

The attacker submits crafted chase attributes

The certificate request contains cdc pointing to the controlled host and rmd identifying the target principal. In the demonstrated case, the target was a domain controller.

The attacker is not simply asking the template to issue a certificate with an arbitrary domain controller subject. Instead, the attacker is influencing where the CA goes to obtain the data it uses to construct the subject and identity extensions.

The CA follows the attacker-selected target

On an unpatched CA, the chase path contacts the cdc target before confirming that the target is a real domain controller. The attacker-controlled host can therefore participate in the lookup and return target identity data.

This is the improper authorization decision. The requester was authorized to submit an enrollment request, but was not entitled to turn an arbitrary member host into an authoritative directory endpoint.

The CA issues a certificate for the target identity

If the remaining enrollment and template conditions are satisfied, the CA signs a certificate containing identity information associated with the domain controller while the attacker retains the corresponding private key.

The certificate is cryptographically valid. It chains to the enterprise CA. Its signature is not forged. The authorization failure happened before signing.

The attacker uses PKINIT as the domain controller

The attacker presents the certificate and proves possession of its private key to a domain controller’s KDC. If certificate mapping succeeds, the KDC issues Kerberos credentials for the mapped domain controller account.

Event 4768 is relevant here because it is generated on domain controllers when the KDC receives a request for a ticket-granting ticket. Updated versions of the event include fields for certificate issuer, serial number, and thumbprint when certificate authentication information is available. (مايكروسوفت تعلم)

Domain controller identity enables highly privileged operations

A domain controller computer account is not a normal workstation identity. Domain controllers possess directory replication capabilities and participate in the highest-trust operations in the domain.

The researchers used the resulting identity to demonstrate directory replication and retrieval of the krbtgt secret. Once an attacker obtains material that can be used to forge or maintain domain-wide Kerberos trust, the incident should be treated as domain compromise. (Gist)

The chain can be summarized defensively:

المرحلة	Attacker requirement	Primary evidence	Control that can break the chain
Domain foothold	Valid low-privilege account	Logons, endpoint telemetry, VPN or remote-access records	MFA, credential hygiene, endpoint detection
Machine identity	Existing or newly created machine account	Event 4741, AD object creation, SPN changes	Set appropriate MachineAccountQuota, controlled delegation
CA access	Network path to enrollment services	RPC, DCOM, HTTP, or enrollment-service logs	Segmentation and enrollment ACLs
Chase request	`cdc` و `rmd` request attributes	Events 4886 and 4887, CA database	July 2026 update, chase mitigation
CA outbound lookup	LDAP and SMB to controlled host	Network flow, firewall and EDR telemetry	Restrict CA egress to approved DCs
Malicious issuance	CA-signed target certificate	Event 4887, certificate serial, CA database	Patched authorization checks
PKINIT	Certificate-based TGT request	Event 4768 and KDC telemetry	Certificate revocation, mapping controls, detection
Domain replication	DC identity used for replication	Directory-service telemetry and replication anomalies	Rapid containment and forest-recovery response

No single defensive control in this table should be treated as a substitute for the security update. The value of the additional controls is that they can prevent prerequisites, expose attempts, reduce blast radius, or provide evidence when patch deployment is incomplete.

Exploitation prerequisites and boundaries

The public PoC is compelling, but risk assessment still requires separating confirmed prerequisites from assumptions.

A valid domain identity is required

Microsoft’s CVSS vector lists privileges required as Low. That means the vulnerability is not modeled as reachable by a completely unauthenticated attacker.

An external actor may still reach it after compromising a user, service account, workstation, VPN session, or identity provider. In an incident-response context, a low-privilege prerequisite should not be interpreted as a major barrier. Ordinary domain credentials are a common outcome of the first stage of an enterprise intrusion.

The attacker needs a path to the CA

The affected enrollment interfaces are normally internal. Network segmentation, firewall policy, enrollment endpoints, and RPC restrictions can influence reachability.

A CA that is unreachable from ordinary workstation networks has a smaller attack surface than one broadly accessible across the domain. It is not automatically safe, because compromised servers, administrative networks, trusted segments, or legitimate enrollment proxies may still provide a path.

An Enterprise CA is the relevant asset

The research concerns an AD-integrated Enterprise CA and directory-backed certificate enrollment. Merely finding an affected Windows build on a workstation does not prove that the workstation is exploitable as a CA.

The CVE record lists Windows client and server products because the vulnerable code is shipped in supported Windows packages. Actual exposure depends on role installation, service configuration, and whether the affected request path is reachable.

Asset teams should therefore ask:

Is the Certification Authority role installed?
Is this host an Enterprise CA?
Is the CA actively issuing certificates?
Which enrollment interfaces are reachable?
Which principals can enroll?
Has the July update been applied?
Is the chase behavior enabled?
Is request and issuance auditing retained?

The public test configuration is not a universal formula

The researchers documented a lab with a Windows Server 2016 or later forest functional level, an Enterprise CA, the default Machine template and ACL, and a MachineAccountQuota of 10. That environment proves a serious path under realistic conditions. It does not prove that those are the only conditions under which the vulnerability can be triggered. (Gist)

Conversely, one difference from the lab does not prove safety. A customized template may still permit suitable enrollment. An existing compromised machine identity may replace machine-account creation. A delegated provisioning service may provide equivalent rights even where MachineAccountQuota is zero.

The CA does not have to be a domain controller

Many PKI designs place the issuing Enterprise CA on a dedicated member server, which is generally preferable to co-locating it with a domain controller. CVE-2026-54121 still matters because the CA’s certificate is trusted by the domain and because it queries Active Directory during issuance.

Patching only domain controllers will not remediate a vulnerable dedicated CA.

Public PoC does not prove active exploitation

A working PoC means reproduction has become easier and the technical ambiguity around impact has decreased. It does not establish that a threat actor has used the flaw against a real organization.

As of July 27, 2026, current public reporting reviewed for this analysis had not identified confirmed in-the-wild exploitation. That status can change quickly and should be checked against Microsoft, CISA, and trusted incident-response reporting when making future decisions. (مساعدة صافي الأمان)

Affected Windows versions and safe build boundaries

The NVD record, based on Microsoft’s CNA data, lists the following affected version ranges. The safest operational approach is to install the latest cumulative security update available for the relevant supported Windows release rather than targeting only the minimum July build.

المنتج	Versions below this build are listed as affected
Windows Server 2012	6.2.9200.26226
ويندوز سيرفر 2012 R2	6.3.9600.23291
Windows Server 2016	10.0.14393.9339
ويندوز سيرفر 2019	10.0.17763.9020
ويندوز سيرفر 2022	10.0.20348.5386
ويندوز سيرفر 2025	10.0.26100.33158
Windows 10 Version 1607	10.0.14393.9339
Windows 10 Version 1809	10.0.17763.9020

Server Core variants are included in the affected Microsoft record. NVD also lists the corresponding client architectures for the Windows 10 releases. (NVD)

Windows Server 2022 build 20348.5386 is delivered by the July 14, 2026 cumulative update KB5099540. Windows Server 2025 build 26100.33158 is delivered by KB5099536. Microsoft describes both packages as cumulative updates containing the latest security fixes. (Microsoft Support)

The table should not be converted into a simplistic rule such as “every Windows 10 1809 host is a domain-takeover target.” The vulnerable component and role must be present and reachable. For prioritization, identify CA servers first, then use the full product list to support patch and package management.

Older Windows Server releases require special care. A build may be technically identifiable while the operating system’s ordinary support lifecycle, ESU entitlement, or update channel differs from modern versions. A Tier 0 CA running an old platform should be treated as both an immediate patching problem and an architectural migration risk.

Disclosure timeline

Date	Event
May 14, 2026	The researchers reported the issue and a case was assigned
May 22, 2026	The report was confirmed
July 14, 2026	Microsoft released the security update and public CVE record
July 24, 2026	The researchers published the Certighost analysis and PoC

The dates above come from the researchers’ disclosure timeline and Microsoft’s CVE publication record. (Gist)

At release time, public patch summaries marked the vulnerability as not publicly disclosed and not known to be exploited. That was accurate for the information available on July 14. The publication of a working PoC on July 24 changed the public-disclosure state even though it did not, by itself, prove malicious exploitation.

This timing matters for vulnerability-management systems. A ticket created on Patch Tuesday may still contain a stale exploitability label ten days later. Organizations should re-score high-impact identity vulnerabilities when technical details, exploit code, or new threat intelligence becomes available.

How the July update changes the decision

Microsoft’s public CVE description is brief. The most detailed explanation of the fix currently comes from the researchers’ reverse engineering of the June and July Windows binaries.

According to that analysis, the patched path introduces a validation routine before the CA follows the requester-provided chase target. The new checks include:

Removing leading backslashes before evaluation.
Rejecting an empty target.
Rejecting an overlong hostname.
Rejecting IPv4 and IPv6 literals.
Rejecting a set of characters that could be dangerous in an LDAP query.
Searching Active Directory for a computer object whose dNSHostName matches the supplied target.
Requiring the computer object to have the SERVER_TRUST_ACCOUNT flag, represented by userAccountControl value 8192.
Requiring a unique matching result.
Performing a subsequent SID consistency check in the resolved-object path. (Gist)

The central security change is not the IP-literal filter. It is the authoritative role check.

Before the update:

requester supplies host
        |
        v
CA follows host as directory target
        |
        v
host supplies identity data

After the update’s intended protected path:

requester supplies host
        |
        v
CA validates hostname form
        |
        v
CA queries authoritative AD data
        |
        v
host must uniquely map to a computer marked SERVER_TRUST_ACCOUNT
        |
        v
CA follows the verified DC
        |
        v
resolved identity is checked for consistency

The first model lets the requester nominate an authority. The second asks the existing authority whether the nominee is authorized.

The servicing feature-gate observation

The researchers also observed a servicing feature check in the patched binary. In their reverse-engineered control flow, the new target validation occurred behind a feature identified as Feature_3185813818, while a legacy branch remained visible when the feature was disabled. (Gist)

This observation deserves careful handling.

It does not prove that fully updated production systems are unprotected by default. Microsoft uses servicing feature controls for deployment, compatibility, and staged behavior, and the public research does not establish every possible runtime state across every supported Windows release.

It does mean that defenders should avoid treating “update installed” as the only possible validation signal. A strong verification program should confirm:

The CA is on or above the documented secure build.
The Certificate Services service was restarted as required by servicing.
The expected updated binary is loaded.
An isolated negative test shows that an unregistered chase target is rejected.
The CA does not make LDAP or SMB connections to the invalid target during that test.
The result is recorded as evidence for change management.

That test should be performed in a disposable lab or staging PKI that does not participate in production trust. Running the public exploit against a production CA is unnecessary and creates avoidable domain-compromise risk.

Safe PoC — modeling the broken authorization decision

The following demonstration is intentionally non-operational. It does not connect to Active Directory, contact a CA, submit a certificate request, implement LDAP or LSA, generate a certificate, perform PKINIT, or obtain domain credentials.

It uses only fictional .invalid hostnames and fake SIDs. Its purpose is to show the difference between:

Trusting a requester-provided routing target.
Authorizing that target against an independent directory of legitimate domain controllers.
Verifying that the returned identity remains consistent.

from __future__ import annotations

from dataclasses import dataclass
from ipaddress import ip_address
from typing import Mapping


SERVER_TRUST_ACCOUNT = 8192


@dataclass(frozen=True)
class DirectoryHost:
    hostname: str
    user_account_control: int


@dataclass(frozen=True)
class Principal:
    name: str
    sid: str
    dns_hostname: str


class AuthorizationError(RuntimeError):
    pass


def normalize_hostname(value: str) -> str:
    """Normalize the toy cdc value without performing any network action."""
    return value.lstrip("\\").strip().lower()


def is_ip_literal(value: str) -> bool:
    try:
        ip_address(value)
        return True
    except ValueError:
        return False


def vulnerable_chase(
    cdc: str,
    rmd: str,
    responders: Mapping[str, Mapping[str, Principal]],
) -> Principal:
    """
    Toy version of the unsafe decision:
    use the requester-selected host as the authority.
    """
    target = normalize_hostname(cdc)

    if target not in responders:
        raise AuthorizationError("The selected responder is unavailable")

    if rmd not in responders[target]:
        raise AuthorizationError("The responder did not return the principal")

    return responders[target][rmd]


def patched_chase_model(
    cdc: str,
    rmd: str,
    expected_sid: str,
    authoritative_ad: Mapping[str, DirectoryHost],
    responders: Mapping[str, Mapping[str, Principal]],
) -> Principal:
    """
    Defensive toy model:
    1. Validate the hostname shape.
    2. Prove through independent AD data that it is a domain controller.
    3. Require the returned object to match the expected SID.
    """
    target = normalize_hostname(cdc)

    if not target:
        raise AuthorizationError("Empty chase target")

    if len(target) > 260:
        raise AuthorizationError("Overlong chase target")

    if is_ip_literal(target):
        raise AuthorizationError("IP literals are not accepted")

    forbidden = set("()*[]\\")
    if any(character in forbidden for character in target):
        raise AuthorizationError("Unsafe hostname characters")

    registered_host = authoritative_ad.get(target)
    if registered_host is None:
        raise AuthorizationError("Target is not registered in authoritative AD")

    if not registered_host.user_account_control & SERVER_TRUST_ACCOUNT:
        raise AuthorizationError("Target is not registered as a domain controller")

    response = responders.get(target, {}).get(rmd)
    if response is None:
        raise AuthorizationError("Principal was not resolved")

    if response.sid != expected_sid:
        raise AuthorizationError("Resolved SID does not match expected identity")

    return response


def main() -> None:
    real_dc = "dc01.corp.invalid"
    attacker_host = "worker77.corp.invalid"
    target_name = "DC01$"
    target_sid = "S-1-5-21-111111111-222222222-333333333-1001"

    authoritative_ad = {
        real_dc: DirectoryHost(
            hostname=real_dc,
            user_account_control=SERVER_TRUST_ACCOUNT,
        ),
        attacker_host: DirectoryHost(
            hostname=attacker_host,
            user_account_control=4096,  # Ordinary workstation trust account
        ),
    }

    forged_target = Principal(
        name=target_name,
        sid=target_sid,
        dns_hostname=real_dc,
    )

    responders = {
        attacker_host: {
            target_name: forged_target,
        },
        real_dc: {
            target_name: forged_target,
        },
    }

    unsafe_result = vulnerable_chase(
        cdc=attacker_host,
        rmd=target_name,
        responders=responders,
    )
    print(f"Unsafe model accepted identity: {unsafe_result.name}")

    try:
        patched_chase_model(
            cdc=attacker_host,
            rmd=target_name,
            expected_sid=target_sid,
            authoritative_ad=authoritative_ad,
            responders=responders,
        )
    except AuthorizationError as error:
        print(f"Defensive model rejected attacker host: {error}")


if __name__ == "__main__":
    main()

Expected output:

Unsafe model accepted identity: DC01$
Defensive model rejected attacker host: Target is not registered as a domain controller

The toy model is deliberately simpler than Windows. It should not be interpreted as source-compatible pseudocode for Certificate Services. It illustrates three controls that matter across security systems:

Requester input cannot establish authority. A user may suggest a route, but an independent trusted source must authorize it.
Authentication is not role authorization. A valid workstation identity is not a valid domain controller identity.
The resolved object must match the expected object. Even an approved route should not be able to substitute a different SID.

These principles apply beyond AD CS. Similar failures occur when a cloud service trusts a caller-selected tenant endpoint, an application follows an unverified identity-provider URL, or an agent treats tool output from an untrusted source as authoritative security state.

Read-only exposure validation

Defenders do not need to execute the public exploit to determine whether they have an urgent patching problem.

The following PowerShell and Windows commands are intended for authorized administrators. Most are read-only. They should be run on a suspected CA host from an elevated administrative session. The Active Directory query requires the AD PowerShell module and suitable directory-read permissions.

# 1. Record the operating-system edition, version, and build.
Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, OSArchitecture

# 2. Check whether the Certification Authority role is installed.
# Available on Windows Server with the ServerManager module.
Get-WindowsFeature ADCS-Cert-Authority |
    Select-Object Name, InstallState

# 3. Display the current CA when run locally on a CA.
certutil

# 4. Inspect the Certification Services audit-policy state.
auditpol /get /subcategory:"Certification Services"

# 5. Inspect the CA's internal audit filter.
certutil -getreg CA\AuditFilter

# 6. Inspect policy-module EditFlags.
certutil -getreg policy\EditFlags

# 7. Read the domain's machine-account quota.
Import-Module ActiveDirectory
$domain = Get-ADDomain
Get-ADObject -Identity $domain.DistinguishedName `
    -Properties ms-DS-MachineAccountQuota |
    Select-Object DistinguishedName, ms-DS-MachineAccountQuota

The commands answer different questions.

Get-CimInstance establishes the build that must be compared with the safe boundary. Get-WindowsFeature determines whether the CA role is installed. Running certutil without parameters on a CA displays the current CA configuration. auditpol checks whether Windows is prepared to generate Certification Services audit events. CA\AuditFilter determines which categories the CA itself is configured to emit. policy\EditFlags exposes policy behavior, including whether chase-related functionality may be enabled. Microsoft documents certutil as an administrative tool for viewing and configuring CA information, while warning that it should not be treated as a supported production-programming interface. (مايكروسوفت تعلم)

A complete inventory should not rely on local inspection alone. Organizations may have:

Root CAs that are normally offline.
Enterprise issuing CAs in separate administrative domains.
CAs used only by network, VPN, Wi-Fi, MDM, or smart-card teams.
Legacy CAs retained for certificate renewal.
Test CAs accidentally trusted by production.
CAs registered in Active Directory but no longer present in the central CMDB.
Cloud-hosted Windows CAs managed outside the primary server team.

Useful discovery sources include:

The Active Directory Enrollment Services container.
Published CA objects and NTAuth stores.
Group Policy enrollment settings.
Certificate templates and their issuing-CA relationships.
Network flows from enrollment clients.
Endpoint-management inventories.
CA certificates found in enterprise trust stores.
Backup and disaster-recovery inventories.

The vulnerability-management unit should be the CA instance, not merely the Windows host. Record the CA name, host, certificate thumbprint, role, hierarchy position, OS build, update state, issued templates, reachable enrollment interfaces, audit state, owner, and incident-response contact.

A safe post-patch negative test

A post-patch behavior test can provide stronger evidence than version detection, but it must be designed so that failure cannot produce a privileged certificate.

A safe test plan uses a disposable forest with:

No trust to production.
A test Enterprise CA.
Fictional users and computers.
No reused production credentials.
No production CA certificates.
No routing from the test network into production.
Packet capture on the CA.
A fake chase target that does not run directory services.
A request whose issuance cannot grant access to any real resource.

The expected protected result is:

The CA receives the test request.
The supplied chase target is not found as an AD computer marked SERVER_TRUST_ACCOUNT.
The request fails or is denied before the CA follows the target.
Packet capture shows no LDAP or SMB session from the CA to the fake target.
No certificate is issued.
CA and Security logs preserve the failure evidence.

The negative test does not need to impersonate a domain controller. It does not need a rogue LDAP server. It does not need PKINIT. Its purpose is to show that the CA refuses an unauthorized routing target before the dangerous stage.

Hunting for suspicious certificate requests

Microsoft’s Certification Services audit events provide the most direct host-level telemetry.

Event 4886 records that Certificate Services received a certificate request and includes the request ID, requester, and attributes. Event 4887 records approval and issuance and includes the request ID, requester, attributes, disposition, subject key identifier, and subject. Events 4888 and 4889 represent denied and pending requests. Microsoft’s PKI monitoring guidance also identifies events for request-attribute changes, CA security changes, audit-filter changes, configuration changes, and database-row deletion. (مايكروسوفت تعلم)

The two most relevant strings are:

cdc:
rmd:

A read-only PowerShell hunt can begin with:

$startTime = (Get-Date).AddDays(-30)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4886, 4887, 4888, 4889
    StartTime = $startTime
} -ErrorAction Stop |
    Where-Object {
        $_.Message -match '(?im)\bcdc\s*:' -or
        $_.Message -match '(?im)\brmd\s*:'
    } |
    Select-Object TimeCreated, Id, MachineName, RecordId, Message

This query is intentionally broad. Event rendering differs by Windows version, language, logging pipeline, and SIEM parser. Some systems may store the useful values in structured XML fields rather than the localized message.

A parser-independent workflow should extract event XML:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4886, 4887
    StartTime = (Get-Date).AddDays(-30)
} |
    ForEach-Object {
        [xml]$xml = $_.ToXml()

        [pscustomobject]@{
            TimeCreated = $_.TimeCreated
            EventId     = $_.Id
            Computer    = $_.MachineName
            RecordId    = $_.RecordId
            Xml         = $xml.OuterXml
        }
    }

Security teams can normalize the resulting XML in their SIEM and search all event-data values for case-insensitive cdc أو rmd attribute names.

The presence of either attribute is not automatic proof of exploitation. Microsoft documents legitimate scenarios in which a client provides a DC name for an end-entity attribute query. The detection value comes from context:

Was the target a registered domain controller?
Was it a newly created machine?
Did the CA connect to it?
Was the request issued?
What identity appeared in the certificate?
Did the certificate map to a domain controller?
Was PKINIT performed from an unusual source?
Did directory replication follow?

Enabling the required audit trail

On many Windows systems, Audit Certification Services is not enabled by default. Microsoft’s advanced audit-policy documentation notes that the policy controls events generated for certificate requests, issuance, revocation, service operations, and other AD CS activity. (مايكروسوفت تعلم)

Microsoft Defender for Identity guidance recommends configuring success and failure auditing under:

Computer Configuration
  Policies
    Windows Settings
      Security Settings
        Advanced Audit Policy Configuration
          Audit Policies
            Object Access
              Audit Certification Services

The CA’s internal audit filter must also permit the events. Microsoft provides the following configuration for complete CA auditing:

certutil -setreg CA\AuditFilter 127
Restart-Service certsvc

Microsoft warns that enabling some start-and-stop auditing on a CA with a very large database can increase restart time, so organizations should test the operational impact and tune retention appropriately. (مايكروسوفت تعلم)

A local command can enable the operating-system audit subcategory:

auditpol /set /subcategory:"Certification Services" `
    /success:enable /failure:enable

For domain-managed CAs, Group Policy is preferable because it makes the desired state auditable and repeatable. Microsoft’s PKI monitoring guidance also explains that the Windows audit policy and the CA audit filter are separate controls: enabling only one may still leave gaps. (مايكروسوفت تعلم)

Log forwarding should send CA Security events to a system that CA administrators cannot casually erase. Events 4885 and 4896 are especially important because they may indicate an audit-filter change or deletion of CA database rows. An attacker who has progressed beyond Certighost into administrative control may attempt to destroy local evidence.

Network detection on the CA

The chase mechanism creates a distinctive network question:

Why is a certificate authority initiating directory and file-service connections to this host?

Based on the disclosed flow, defenders should review outbound connections from CA servers to:

TCP 389 for LDAP.
TCP 636 for LDAPS where applicable.
TCP 445 for SMB and related authentication behavior.
Any RPC traffic associated with the enrollment and lookup sequence.

The strongest anomaly is not “the CA connected to LDAP.” Enterprise CAs legitimately communicate with domain controllers. The anomaly is that the destination is not in the approved domain-controller inventory.

A generic detection condition is:

source_host is in ENTERPRISE_CA_SERVERS
and destination_port is one of 389, 636, 445
and destination_host is not in APPROVED_DOMAIN_CONTROLLERS

A higher-confidence correlation is:

certificate request contains cdc or rmd
and CA connects to the cdc target within a short time window
and the destination is not an approved domain controller
and a certificate is issued for a domain controller identity

Another useful signal is a CA making its first-ever connection to a workstation subnet. A legitimate topology change may produce that behavior, but it deserves investigation when it occurs near a certificate request from the same user or newly created machine account.

Firewall enforcement can convert this detection into prevention. A well-understood CA often needs outbound directory access only to a finite set of domain controllers, DNS services, CRL or AIA publication targets, update infrastructure, monitoring systems, and backup services.

Before imposing an allowlist, administrators must map:

All domains and forests served by the CA.
Sites used for enrollment.
Disaster-recovery domain controllers.
Cross-forest trusts.
Enrollment agents and policy servers.
CRL and AIA publication destinations.
Time synchronization, DNS, update, backup, HSM, and monitoring dependencies.

A hastily configured firewall can interrupt certificate issuance, revocation publication, or domain operations. Network restriction is valuable defense in depth, but it requires PKI-aware testing.

Detecting machine-account preparation

The public PoC uses a machine account. Event 4741 is generated on domain controllers whenever a new computer object is created. It records the account that requested creation, the new computer SID, SAM account name, DNS hostname, service principal names, and other attributes. (مايكروسوفت تعلم)

High-value conditions include:

A normal user creating a computer account outside an approved provisioning workflow.
A new computer account whose DNS hostname resolves to a user workstation.
A computer object created shortly before a suspicious certificate request.
A computer object deleted soon after issuance.
New SPNs associated with unusual LDAP, host, or restricted-host services.
A machine password set from an unexpected source.
A computer account created outside business hours by an account that has never joined machines before.

A simple starting query on a domain controller is:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4741
    StartTime = (Get-Date).AddDays(-30)
} |
    Select-Object TimeCreated, MachineName, RecordId, Message

The event should be joined to:

The subject account’s logon events.
The source workstation or IP.
Event 4742 computer-account changes.
Directory Service Change events where SACLs are configured.
DNS registration.
SPN changes.
CA request and issuance events.
CA outbound network connections.

Machine-account creation by a low-privileged user is not necessarily malicious. Some organizations still use the default domain-join model. The detection should learn approved join services, help-desk groups, provisioning hosts, and expected naming conventions.

Detecting certificate-based Kerberos authentication

After malicious issuance, the attacker needs to use the certificate.

Event 4768 is generated on a domain controller when the KDC receives a TGT request. Microsoft updated the event schema for Windows Server 2016 and later systems receiving the January 14, 2025 or later cumulative update. The updated version contains certificate issuer, serial number, and thumbprint fields, although those fields may be empty when certificate authentication is not involved. (مايكروسوفت تعلم)

A useful detection model looks for:

TargetUserName ending in $ and belonging to a domain controller.
Certificate fields populated.
Source IP not matching any current domain controller address.
Certificate serial or thumbprint corresponding to a recent CA issuance.
TGT request shortly after a certificate request containing cdc أو rmd.
TGT request from the same host associated with a newly created machine account.
Subsequent directory replication or privileged service access.

A conceptual SIEM correlation is:

CA event 4887
  where request attributes contain cdc or rmd
  and issued identity is a domain controller
join KDC event 4768
  where target account equals issued identity
  and certificate serial or thumbprint matches
  and source IP is not a domain controller
within 15 minutes

Not every environment will expose all fields in one data source. The request ID may exist only on the CA, while the certificate serial appears in the KDC event. The investigation may require retrieving the issued certificate from the CA database and comparing its serial number, thumbprint, SID extension, DNS names, and validity window.

Inspecting the CA database

The CA database remains valuable when event-log retention is short. Microsoft’s certutil documentation supports views of issued, denied, pending, revoked, extension, and attribute data. The local schema can be displayed because available columns and naming can vary by version. (مايكروسوفت تعلم)

Safe exploratory commands include:

# Display the request and certificate database schema.
certutil -schema

# Display the attribute-table schema.
certutil -schema Attrib

# Review a known request ID.
certutil -view -restrict "RequestId==123"

# Review request attributes.
certutil -view Attrib

For large CAs, do not dump the entire database into an interactive console during peak operation. Use a tested export workflow, restrict by request ID or date where supported, and work from a protected forensic copy when investigating a suspected compromise.

The investigation should preserve:

Request ID.
Requester name.
Submission and issuance time.
Disposition.
Template.
Request attributes.
Certificate subject and SAN values.
SID security extension.
Serial number.
Thumbprint.
Public-key identifier.
Revocation state.
Any administrative modifications after submission.

The request ID is the most useful pivot between events 4886, 4887, 4888, 4889, attribute changes, and the CA database.

Detection priorities

الإشارة	Confidence alone	What raises confidence	Main false-positive source
Request contains `cdc`	Low to medium	Target is not a registered DC	Legitimate cross-domain enrollment
Request contains `rmd`	Low to medium	Paired with suspicious `cdc`	Legitimate remote-domain lookup
CA connects to non-DC over LDAP	متوسط	Connection follows chase request	Inventory gap or CA migration
CA connects to workstation over SMB and LDAP	عالية	Certificate issued immediately after	Unusual lab or troubleshooting
Normal user creates computer account	منخفضة	Account used as chase target	Standard domain join
Domain controller certificate issued	متوسط	Requester is unrelated low-privilege user	Normal DC renewal
DC account receives certificate-based TGT from workstation IP	عالية	Matches suspicious issuance	Misclassified network or recovery activity
Replication request from non-DC host	عالية	Follows suspicious PKINIT	Legitimate identity-management product
CA audit filter changed	متوسط	Occurs before suspicious requests	Planned administration
CA database rows deleted	عالية	Occurs after suspicious issuance	Approved database maintenance

The most reliable detection is a chain, not a keyword. A cdc attribute provides a lead. A CA connection to a non-DC provides context. An issued DC certificate provides evidence. PKINIT from an unexpected address and replication activity establish impact.

المعالجة

Patch every CA first

Install the July 14, 2026 security update or a later cumulative update on every affected CA host. Verify that the resulting build is at or above the safe threshold documented for the operating-system release.

Prioritize:

Online Enterprise issuing CAs.
CAs that issue authentication-capable machine certificates.
CAs reachable by broad domain-user populations.
CAs in forests where ordinary users can create machine accounts.
CAs with weak logging or unrestricted outbound access.
Legacy CAs whose ownership or operational state is unclear.

Root CAs that remain offline and do not process Enterprise enrollment requests have a different immediate exposure profile, but their operating systems should still be assessed and serviced according to the PKI maintenance plan before they are brought online.

Confirm the running build

Use:

Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber

Compare the result with the affected-version table and the latest Microsoft update history for that platform. Do not rely only on a vulnerability scanner’s software inventory if it cannot distinguish an installed-but-pending update, a failed reboot, a stale image, or a host that was restored from backup after patching.

Where practical, record the loaded Certificate Services binary version and verify it against the approved post-update baseline.

Restart and validate services

Cumulative updates may require a system restart. Configuration changes to Certificate Services may require restarting CertSvc.

After maintenance:

Confirm the CA service is running.
Submit a normal low-risk enrollment request.
Confirm certificate issuance remains functional.
Confirm CRL and AIA publication.
Confirm HSM connectivity where used.
Confirm audit events are generated.
Confirm enrollment endpoints remain available.
Perform the isolated negative chase test.
Preserve test evidence.

Temporary mitigation by disabling chase

The researchers describe a temporary mitigation that clears the chase fallback flag:

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

They explicitly state that this is a mitigation rather than a patch and that it was validated only in a controlled lab. Legitimate enrollment that depends on the chase fallback may fail after the flag is cleared. The researchers recommend testing it on a staging CA that mirrors production and applying the July security update as the primary remediation. (Gist)

Because the command changes CA policy, administrators should:

Export the current configuration.
Record the original EditFlags value.
Identify cross-domain and remote-domain enrollment dependencies.
Apply the change during a controlled window.
Restart the service.
Test all critical enrollment workflows.
Monitor denied and failed requests.
Schedule the permanent security update.
Remove the temporary exception process after patch validation.

Disabling chase on an unpatched CA reduces exposure only while the flag remains disabled. A configuration-management job, restored system image, administrator action, or undocumented dependency could re-enable it.

Restrict CA outbound access

A CA should not have unrestricted east-west access merely because it is a trusted server.

Build an outbound policy that permits only documented destinations and services. At minimum, evaluate:

Approved domain controllers.
DNS resolvers.
Time sources.
CRL and AIA publication servers.
HSM and key-management systems.
Backup targets.
Monitoring and log collectors.
Update infrastructure.
Administrative management hosts.

For directory traffic, compare every allowed destination with the authoritative domain-controller inventory. A request should not be able to turn an ordinary member host into a permitted LDAP or SMB destination.

Network restrictions may prevent or expose future vulnerabilities that also rely on a CA contacting attacker-selected infrastructure.

Reassess MachineAccountQuota

Setting ms-DS-MachineAccountQuota to zero can remove the default ability for ordinary users to create computer accounts. Organizations that already use a controlled domain-join service, delegated organizational-unit permissions, or identity-governance workflow often have no need for the default quota.

A read-only check is:

Import-Module ActiveDirectory

$domain = Get-ADDomain

Get-ADObject -Identity $domain.DistinguishedName `
    -Properties ms-DS-MachineAccountQuota |
    Select-Object ms-DS-MachineAccountQuota

Changing the value should be part of a domain-join design review, not an emergency command copied blindly into production.

A quota of zero does not:

Patch CVE-2026-54121.
Remove existing attacker-controlled computer accounts.
Remove delegated computer-object creation permissions.
Prevent compromise of an existing machine identity.
Prevent abuse by an account that already owns a computer object.
Validate chase targets on the CA.

Treat it as prerequisite reduction and general AD hardening.

Review machine certificate enrollment

The public research used the default Machine template and default ACL in its lab. That does not make the template the root cause, but enrollment scope affects who can reach the vulnerable path.

مراجعة:

Which CAs issue the Machine template.
Whether Domain Computers or other broad groups have Enroll or Autoenroll.
Whether the template permits client authentication.
Whether issuance requires approval.
Whether unused authentication templates remain published.
Whether service accounts can enroll.
Whether computer-object ownership creates unexpected enrollment rights.
Whether legacy templates have overly broad ACLs.
Whether enrollment agents or policy servers expand access.

Do not disable essential machine enrollment without understanding operational dependencies. TLS, IPsec, Wi-Fi, VPN, network access control, device management, smart-card infrastructure, and service authentication may depend on the PKI.

Protect the CA as Tier 0

An Enterprise CA that can issue domain-authentication certificates belongs in the highest administrative tier.

Controls should include:

Dedicated administrative accounts.
Privileged access workstations.
No routine web browsing or email on the CA.
Restricted interactive logon.
Restricted remote administration.
Application control.
Strong backup protection.
HSM use where appropriate.
Offline protection for root CA keys.
Independent log forwarding.
Monitored configuration changes.
Documented break-glass procedures.
Regular certificate-template and CA ACL review.
Tested recovery of the CA database, keys, and configuration.

CVE-2026-54121 is a software authorization defect, but weak CA administration magnifies both exploitation and recovery risk.

Patch, workaround, and defense-in-depth comparison

التحكم	Blocks the root cause	Operational risk	Should it be permanent
July 2026 or later security update	نعم	Normal update and restart risk	نعم
Disable `EDITF_ENABLECHASECLIENTDC`	Avoids the affected fallback while disabled	May break legitimate chase-dependent enrollment	Temporary unless the feature is not needed
Set MachineAccountQuota to zero	لا يوجد	May disrupt unmanaged domain join	Useful hardening where compatible
Restrict CA egress to known DCs	May block demonstrated attacker path	Can break multi-domain or recovery workflows if incomplete	Yes, after dependency mapping
Restrict enrollment permissions	لا يوجد	Can interrupt certificate-dependent services	Yes, least privilege
Enable CA auditing	لا يوجد	Log volume and storage	نعم
Strong certificate mapping	No, because issuance is upstream	Legacy certificate compatibility	Yes for broader certificate security
Remove unused authentication templates	لا يوجد	Application compatibility	Yes where safely validated
Network segmentation around CA	لا يوجد	Management and enrollment complexity	نعم
Vulnerability-scanner version check	Detects likely exposure only	False confidence if role or runtime state is wrong	Useful as one evidence source

Incident response when suspicious issuance is found

A suspicious request is not the same as a successful domain compromise. Response should determine how far the chain progressed.

Preserve evidence before changing the CA

Collect:

Security logs from the CA.
Microsoft-Windows-CertificationAuthority logs.
CA database and database logs.
Current CA registry configuration.
Certificate template definitions and ACLs.
Network flow and packet data.
EDR telemetry from the CA.
Domain controller Security logs.
Active Directory object changes.
DNS logs.
Firewall logs.
Authentication logs for the requester.
Copies of suspicious issued certificates.
Current CRLs and publication history.

Do not delete suspicious CA database rows. Event 4896 exists specifically to record row deletion, and deletion can destroy the easiest link between a request and its issued certificate. (مايكروسوفت تعلم)

Reconstruct the certificate request

For each request containing cdc أو rmd, determine:

Request ID.
Requester.
Source host and IP.
Submission time.
cdc target.
rmd principal.
Certificate template.
Disposition.
Issuance time.
Certificate subject.
DNS names.
SID extension.
Serial number.
Thumbprint.
Validity period.
Whether the certificate was revoked.
Whether the private key could have remained with the requester.

Confirm whether the cdc target was a legitimate domain controller at that time. Historical accuracy matters: a host may have been promoted, demoted, renamed, or rebuilt.

Revoke suspicious certificates

Microsoft’s certutil supports certificate revocation by serial number and CRL publication. For a confirmed compromised certificate, an administrator can use the key-compromise reason and then publish an updated CRL:

certutil -revoke <SERIAL_NUMBER> 1
certutil -CRL

The exact operational procedure should follow the organization’s PKI runbook. Verify that CRL distribution points are reachable and that relying services retrieve the new CRL. Microsoft documents reason code 1 as key compromise and provides -CRL for publishing new certificate revocation lists. (مايكروسوفت تعلم)

Revocation is necessary but not sufficient.

A Kerberos TGT that was already issued does not disappear merely because the source certificate is later revoked. Cached credentials, service tickets, extracted secrets, changed group memberships, scheduled tasks, service-account keys, added trust relationships, and other persistence may survive.

Determine whether PKINIT occurred

Search domain controller event 4768 for:

The target domain controller account.
Certificate authentication fields.
The suspicious certificate’s serial or thumbprint.
Source IP addresses outside the DC inventory.
Timestamps after certificate issuance.
Repeated TGT requests.
Ticket encryption and pre-authentication details.

Also review endpoint telemetry on the suspected attacker host for certificate files, private-key access, Kerberos cache activity, and unusual authentication libraries. Evidence collection should be performed by responders who understand the legal, operational, and evidentiary requirements of the environment.

Determine whether directory replication occurred

If the certificate was used as a domain controller, review directory replication telemetry and sensitive account access.

Questions include:

Did a non-DC IP request replication?
Did the target DC machine account appear from an unexpected host?
Were secrets for krbtgt, domain administrators, service accounts, or trust accounts accessed?
Were new privileged users or groups created?
Were ACLs changed on the domain root, AdminSDHolder, configuration partition, or PKI objects?
Were new certificates issued after the initial event?
Were trust relationships or delegation settings changed?
Was security logging disabled?
Were CA database records removed?
Were endpoint protections modified?

If replication of sensitive credentials is confirmed or cannot be ruled out, the incident should move from “malicious certificate” to “Active Directory compromise.”

Handle possible KRBTGT exposure as forest recovery

Microsoft’s forest-recovery guidance requires a complete KRBTGT password-reset procedure during recovery from a malicious Active Directory compromise. Microsoft states that the password should be reset twice, with an interval longer than the configured maximum ticket lifetimes and sufficient time for replication. The published forest-recovery procedure uses 10 hours as the default interval because that corresponds to default ticket lifetimes. (مايكروسوفت تعلم)

Do not perform two rapid KRBTGT resets as an isolated reaction without understanding replication health and application impact. Before the reset:

Contain the attacker.
Close initial-access paths.
Remove persistence.
Validate domain controller integrity.
Confirm AD replication health.
Reset privileged credentials.
Prepare application owners for Kerberos reauthentication.
Follow Microsoft or qualified incident-response guidance.
Preserve evidence.
Establish a recovery authority that the attacker cannot access.

Resetting KRBTGT alone does not remove a compromised CA certificate, malicious administrator, rogue federation trust, stolen service-account key, or attacker-controlled domain controller.

Why MachineAccountQuota is not the fix

MachineAccountQuota receives attention because the public PoC uses it. That can lead to the wrong remediation decision.

Consider four environments.

Environment A

MachineAccountQuota is 10.
Ordinary users can create computers.
CA is unpatched.

The demonstrated prerequisite is readily available. Risk is high.

Environment B

MachineAccountQuota is zero.
Help-desk users have delegated rights to create computer objects.
One help-desk account is compromised.
CA is unpatched.

The quota does not prevent machine-account creation through delegated permissions. Risk remains.

Environment C

MachineAccountQuota is zero.
Attacker compromises an existing workstation and obtains its machine identity.
CA is unpatched.

No new computer account is required. Risk remains.

Environment D

MachineAccountQuota is 10.
CA is patched and rejects any chase target that is not an AD-registered domain controller.
CA egress is restricted to approved DCs.

The machine-account creation capability still deserves review, but the Certighost root cause is addressed.

Reducing MachineAccountQuota is valuable because machine accounts have been relevant to multiple Active Directory attack techniques. It should be part of a broader plan that inventories delegated object creation, computer-object ownership, SPNs, resource-based constrained delegation, stale machines, and domain-join workflows.

Why strong certificate binding is not the fix

KB5014754 and strong certificate mapping significantly improve Windows certificate authentication. They reduce ambiguity and make it harder to map a certificate to a different account using only a weak name.

Certighost is not evidence that those controls are useless. It is evidence that security controls at different layers solve different problems.

الطبقة	Security question	Relevant control
Enrollment authorization	May this requester obtain this kind of certificate?	Template and CA ACLs
Directory routing	Is this lookup endpoint authorized to provide AD identity data?	CVE-2026-54121 fix
Object resolution	Did the CA retrieve the correct object?	SID and object consistency checks
Certificate construction	Does the certificate accurately encode the approved identity?	CA policy module
Certificate mapping	Does the certificate strongly correspond to the AD account?	KB5014754 and KDC mapping
المصادقة	Does the client possess the certificate’s private key?	PKINIT cryptographic proof
Authorization after logon	What may the mapped account do?	AD ACLs, group membership and machine role

The failure was in directory routing and object resolution. A downstream KDC cannot reliably infer that the upstream CA was misled if the signed certificate contains internally consistent identity data.

مكافحة التطرف العنيف	المكوّن	Trust failure	Typical prerequisite	Primary defensive direction
CVE-2022-26923	AD DS and certificate authentication	Certificate identity could be bound unsafely to directory objects	Authenticated domain access and enrollment conditions	Patch, strong certificate binding, machine identity hardening
CVE-2022-34691	Windows certificate authentication	Certificate-to-account mapping could permit spoofing	Certificate-authentication conditions	Strong mappings and enforcement
CVE-2022-26931	Windows certificate authentication	Certificate mapping and identity binding weakness	Domain and certificate conditions	Microsoft updates and mapping hardening
CVE-2026-25177	AD DS	Security-significant names were insufficiently restricted	Low-privilege authenticated access	Patch and monitor identity-attribute changes
CVE-2026-54121	AD CS	Requester-controlled chase routing was accepted before DC authorization	Low-privilege domain foothold, CA access and vulnerable enrollment path	Patch CA, validate chase targets, hunt requests and restrict egress

Continuous validation without turning testing into exploitation

CVE-2026-54121 exposes a common weakness in vulnerability management: a scanner can report an installed build, but the organization still needs to prove that the right assets were scanned, the service is running the patched path, the logging required for retrospective analysis exists, and no prior abuse occurred.

Useful automated checks include:

Discovering Enterprise CAs from Active Directory.
Mapping CA names to current hosts.
Recording OS builds and update state.
Identifying published authentication templates.
Reviewing broad Enroll and Autoenroll permissions.
Checking Certification Services auditing.
Checking the CA AuditFilter.
Recording EditFlags.
Comparing CA outbound destinations with the DC inventory.
Searching historical events for cdc و rmd.
Correlating issued DC certificates with event 4768.
Confirming that temporary mitigations remain in the intended state.
Repeating the checks after patching.
Preserving command output and log references as evidence.

In an authorized security program, an agentic testing platform such as بنليجنت can be used to organize that evidence-driven workflow: asset discovery, scoped configuration checks, correlation of findings, controlled validation, and retesting after remediation. The appropriate goal for a production AD CS environment is not to automate domain takeover. It is to automate the non-destructive checks around the dangerous path and reserve any active negative testing for an isolated lab with explicit authorization and rollback controls. (بنليجنت)

Automation also requires strict boundaries. A system should know:

Which CA hosts are in scope.
Which commands are read-only.
Whether service restarts are allowed.
Whether registry changes are allowed.
Whether any enrollment request may be submitted.
Which test identities may be used.
Which networks are prohibited.
Which results require immediate human escalation.
Which evidence must be retained.
Which actions are destructive or domain-impacting.

An autonomous workflow that downloads and runs the public PoC against a production CA would be irresponsible. An autonomous workflow that inventories CAs, verifies builds, checks audit configuration, searches request attributes, and creates a remediation report can reduce response time without crossing into unsafe exploitation.

Common mistakes

Patching domain controllers but not CAs

The CA may be a dedicated member server. Domain controller compliance does not establish CA compliance.

Treating every affected Windows CPE as an exploitable CA

The vulnerable package may be present in the operating system record, but practical exposure depends on the AD CS role and reachable request-processing path.

Treating MachineAccountQuota zero as remediation

It removes one common prerequisite. It does not repair the CA’s authorization logic.

Assuming strong SID mapping prevents malicious issuance

Strong mapping protects against some forms of identity ambiguity. It cannot detect that a trusted CA was deceived into signing the wrong SID for an attacker-controlled key.

Reviewing templates only

Template review is essential for AD CS security, but CVE-2026-54121 affected CA request processing even in the researchers’ default-template test. A clean ESC assessment does not prove the CA is patched.

Checking only event 4887

Event 4887 is valuable because it records issuance. Event 4886 may preserve attempted requests that were denied or failed. Network traffic can reveal a chase even when issuance evidence is absent.

Declaring every `cdc` attribute malicious

The client-provided DC behavior exists for legitimate directory searches. Confirm whether the target was a valid DC and correlate the full chain.

Running the public PoC in production

A successful test may produce a real domain controller certificate and enable domain compromise. Version inspection, log analysis, egress controls, and a safe lab negative test provide defensible validation without creating that risk.

Leaving the temporary mitigation in place indefinitely

Clearing the chase flag can reduce exposure, but an unpatched CA remains dependent on configuration state. Patch and verify the updated authorization behavior.

Revoking the certificate and closing the incident

Revocation does not undo an issued TGT, extracted secret, changed ACL, new administrator, or replication of krbtgt material.

Waiting for CISA KEV

KEV is an authoritative list of vulnerabilities known to have been exploited in the wild, not a complete list of vulnerabilities that are technically exploitable or urgent. A public domain-compromise PoC against Tier 0 infrastructure is sufficient reason for immediate remediation even before any KEV entry. (CISA)

A 24-hour, 7-day, and 30-day response plan

أول 24 ساعة الأولى

Identify every Enterprise CA and its host.
Record the OS version and build.
Patch online issuing CAs to the July 2026 or later cumulative update.
If patching is impossible, assess the lab-validated chase-disable mitigation and network isolation.
Verify Certification Services auditing and CA AuditFilter.
Search at least the available Security-log retention period for cdc و rmd.
Review CA outbound LDAP and SMB connections to non-DC destinations.
Identify domain controller certificates issued since the earliest plausible exposure date.
Escalate any suspicious issuance to incident response.
Preserve evidence before restarting, reconfiguring, or cleaning systems.

First 7 days

Review the CA database beyond local event-log retention.
Correlate suspicious request IDs with certificate serials.
Search event 4741 for machine accounts created by unusual users.
Search event 4768 for certificate-based authentication as DC accounts.
Review directory replication activity.
Build a CA-to-domain-controller network allowlist.
Evaluate MachineAccountQuota and delegated computer-creation rights.
Review Machine and other client-authentication template permissions.
Perform the isolated negative test against the patched behavior.
Document the result for audit and change control.
Confirm CRL and AIA publication after updates.
Update incident-response runbooks for malicious certificate issuance.

First 30 days

Move Enterprise CAs formally into the Tier 0 asset model.
Establish continuous CA build and configuration monitoring.
Forward all relevant CA events to protected central storage.
Baseline legitimate cdc and remote-domain enrollment activity.
Correlate CA, AD, KDC, DNS, firewall, and EDR telemetry.
Remove stale computer accounts and unused certificate templates.
Replace broad machine-join permissions with controlled delegation.
Restrict CA administrative logon and outbound access.
Exercise certificate-compromise and domain-compromise recovery.
Review the PKI hierarchy, ownership, backup protection, and legacy dependencies.
Establish a recurring process for safe post-update behavioral validation.
Track public exploitability changes for identity and PKI vulnerabilities.

Practical resources worth keeping

Microsoft’s NVD-linked CVE record is the best concise source for the official description, CVSS vector, CWE, affected products, and build boundaries. (NVD)

The Microsoft MS-WCCE protocol documentation explains that the CA can perform an end-entity attribute search against a client-provided domain controller name, which is essential context for understanding why the chase feature exists. (مايكروسوفت تعلم)

The Certighost researcher disclosure provides the detailed technical root cause, tested attack chain, reverse-engineered patch behavior, temporary mitigation, and disclosure timeline. Its exploit commands should be reserved for isolated, explicitly authorized research environments. (Gist)

Microsoft’s KB5014754 and MS-PKCA documentation explain strong certificate mapping and SID-based identity binding, which are necessary for understanding why a maliciously issued certificate can be accepted by the KDC. (مايكروسوفت تعلم)

Microsoft’s CA auditing guidance provides the event IDs and configuration required to preserve request, issuance, revocation, and CA configuration evidence. (مايكروسوفت تعلم)

Frequently asked questions

Can CVE-2026-54121 be exploited by an unauthenticated internet attacker?

Not according to the published attack model. Microsoft assigns PR:L, meaning low privileges are required.
The demonstrated chain begins with a valid low-privilege domain user.
The attacker also needs network access to the relevant CA enrollment path and supporting domain services.
An external attacker may reach that position after compromising VPN credentials, a workstation, a service account, or another internal identity.
Internet exposure is not required for the vulnerability to be urgent because ordinary domain credentials are a common post-compromise asset. (NVD)

Is every Windows Server vulnerable to Certighost?

No. The affected Windows version record identifies software ranges, but practical exposure centers on systems running the relevant AD CS Certification Authority functionality.
A dedicated Enterprise CA can be vulnerable even when it is not a domain controller.
A normal member server with no CA role does not provide the demonstrated certificate-issuance path merely because its build appears in the CVE record.
Inventory the AD CS role, CA type, enrollment reachability, template availability, update state, and chase configuration.
Server Core variants are included in the affected record. (NVD)

Does setting MachineAccountQuota to zero completely fix CVE-2026-54121?

No. It does not change the vulnerable CA code.
It can prevent ordinary users from using the default quota to create new machine accounts.
An attacker may still control an existing machine account or have delegated computer-creation rights.
Stale, compromised, or pre-created computer objects may provide equivalent prerequisites.
Use a quota reduction as defense in depth after reviewing domain-join operations, not as a substitute for the Microsoft update. (مايكروسوفت تعلم)

Why did strong certificate mapping not stop the attack?

Strong mapping validates the relationship between certificate identity data and an AD object.
CVE-2026-54121 allowed the CA to obtain the wrong identity data from an unauthorized lookup source before signing.
A certificate containing a matching SID for the target can therefore appear strongly mapped even though issuance was malicious.
The KDC cannot reliably reconstruct the CA’s original directory-query path.
Both layers are required: trustworthy issuance and strong certificate-to-account mapping. (مايكروسوفت تعلم)

How can a team validate the patch without running the public exploit?

Confirm that every CA host meets or exceeds the documented safe build.
Verify that the updated Certificate Services binary is loaded after servicing.
Check that Certification Services auditing is enabled.
Use a disposable test forest and submit a harmless request with an unregistered chase target.
Confirm that the request is rejected before the CA contacts the target.
Capture CA logs and network traffic as evidence.
Do not request a certificate for a privileged production identity or perform PKINIT as a domain controller.

Which Windows events are most useful for detection?

4886 records a received certificate request and its attributes.
4887 records approval and issuance.
4888 records denial.
4889 records a request placed in pending state.
4741 records creation of a computer account on a domain controller.
4768 records a Kerberos TGT request and can contain certificate details.
4885, 4891, and 4896 help detect audit-filter changes, CA configuration changes, or database-row deletion.
The best result comes from correlating events with CA outbound LDAP and SMB traffic. (مايكروسوفت تعلم)

Does finding a suspicious domain controller certificate prove the domain was compromised?

It proves a severe certificate-issuance failure if the certificate was issued to an unauthorized requester.
It does not alone prove the certificate was used.
Search event 4768 and other KDC telemetry to determine whether PKINIT occurred.
Review directory replication activity to determine whether DC privileges were exercised.
If sensitive replication or krbtgt access occurred, treat the event as domain compromise.
Revoke the certificate, but do not assume revocation removes existing Kerberos tickets or persistence.

Should organizations disable the chase fallback?

Install the Microsoft security update first.
The researchers provide a chase-disable command as a temporary mitigation when patching cannot occur immediately.
They validated the workaround only in a controlled lab.
Disabling the fallback may break legitimate cross-domain or remote-domain enrollment.
Test it on a staging CA, record the original configuration, and monitor failed requests.
Do not leave an unpatched CA dependent indefinitely on a reversible configuration flag. (Gist)

Final assessment

CVE-2026-54121 is dangerous because it violated an identity-system rule that should be absolute: the subject of a certificate may influence a request, but the requester must not be able to choose the authority that defines who the subject is.

The vulnerable AD CS chase path accepted requester-controlled routing data before proving that the target was a domain controller. In the demonstrated configuration, that mistake let a low-privileged domain user obtain a CA-signed certificate representing a domain controller and use the certificate as a path toward domain-wide privilege.

The correct response is not to debate whether the formal 8.8 score should have been a 9.0 or higher. Enterprise CAs are Tier 0 systems. A public PoC exists. The affected path can cross from an ordinary domain identity into domain controller authentication.

Patch the CA hosts, not only the domain controllers. Confirm the secure build and actual protected behavior. Hunt historical cdc و rmd requests. Review CA outbound connections to non-DC systems. Correlate issuance with machine-account creation, certificate-based TGT requests, and directory replication. If a malicious domain controller certificate was used, respond as though the domain’s trust fabric may already have been breached.

شارك المنشور:

منشورات ذات صلة

CVE-2026-59084, Tomcat EncryptInterceptor Risk and Safe Upgrade Guidance

CVE-2026-59084 is easy to misread. It is not a newly disclosed pre-authentication remote code execution primitive in Apache Tomcat, and

قراءة المزيد

Claude Jailbreak Risk Has Moved Beyond Chat

A Claude jailbreak used to mean a prompt that persuaded the model to produce content its safety training was supposed