The public Certighost proof-of-concept exploit highlights a serious risk in one of the most sensitive parts of Microsoft enterprise environments: Active Directory Certificate Services.

Active Directory is the identity foundation for many organizations. It controls users, computers, groups, authentication, permissions, Kerberos, policies, and access to business systems. When Active Directory Certificate Services is deployed, certificates become part of that trust model. If attackers can abuse certificate issuance, they may be able to impersonate privileged identities without needing to steal their passwords.

Certighost is concerning because it shows how an authenticated attacker with relatively low privileges may be able to abuse AD CS behavior to obtain a certificate that lets them authenticate as a more privileged identity, including potentially a Domain Controller. Once an attacker can impersonate a Domain Controller, the situation can move quickly from privilege escalation to full domain compromise.

A Domain Controller is not just another Windows server. It is responsible for authentication, directory replication, Kerberos trust, password-hash storage, group membership, and identity policy. If attackers can authenticate as a Domain Controller, they may be able to perform privileged Active Directory operations, including DCSync-style attacks to extract sensitive secrets.

DCSync is especially dangerous because it abuses legitimate directory replication behavior. Domain Controllers replicate password-related data between each other. If an attacker can convince Active Directory that they have replication rights, they may be able to pull password hashes and secrets from the domain, including highly sensitive Kerberos material. At that point, the attacker is not merely inside the domain. They may be able to own it.

The release of a public proof-of-concept changes the urgency. Before a PoC is available, exploitation may require specialist knowledge. After a PoC is released, the barrier drops sharply. Attackers, ransomware groups, access brokers, red teams, and opportunistic operators can test environments far more easily. Naturally, the internet saw “identity infrastructure” and decided it needed a copy-paste exploit button.

This vulnerability should not be dismissed because it requires authentication. In real breaches, attackers often obtain low-privileged domain access through phishing, stolen VPN credentials, malware, exposed RDP, password reuse, helpdesk compromise, or an infected workstation. Once they have a basic domain account, they look for ways to escalate. Certighost provides exactly the kind of path attackers want.

Organizations running AD CS should immediately verify whether their Certificate Authorities are patched according to Microsoft’s guidance. Enterprise CA servers, subordinate CAs, old CA systems, test CAs, backup CAs, and disaster-recovery certificate servers should all be included. The forgotten CA is usually the one still trusted by production, because enterprise architecture has a dark sense of humor.

Patching is essential, but it should not be the only action. Certificate Services configuration should be reviewed carefully. Administrators should examine certificate templates, enrollment permissions, subject-name controls, authentication settings, manager approval requirements, certificate issuance logs, and whether ordinary users can request certificates that could be abused.

Organizations should review the Machine certificate template and any templates allowing client authentication, domain authentication, or broad enrollment. Templates that allow low-privileged users to influence subject names, request certificates for other identities, or enroll without sufficient approval can become escalation paths.

Machine-account creation rights should also be reviewed. In many Active Directory environments, ordinary authenticated users may be able to create a limited number of computer accounts because of the default machine account quota. That default behavior may be convenient in some environments, but it can also support attack chains when combined with certificate abuse.

Administrators should consider reducing or disabling unnecessary machine-account creation by ordinary users. Computer-account creation should be controlled through defined provisioning processes, not left open because a decades-old default decided everyone deserved a small computer-account allowance.

Security teams should hunt for suspicious certificate activity. This includes unusual certificate requests, unexpected Machine certificate enrollment, certificate requests tied to Domain Controller names, enrollment from unusual workstations, requests by low-privileged users, and certificate issuance events followed by abnormal Kerberos authentication.

Certificate Authority logs should be reviewed in detail. Defenders should identify what certificates were issued, who requested them, which templates were used, what subject names were included, and whether any requests involved high-value identities such as Domain Controllers, domain administrators, service accounts, or infrastructure hosts.

Organizations should also monitor for DCSync activity. Directory replication requests should come only from legitimate Domain Controllers and authorized replication systems. DCSync-like behavior from a workstation, newly created machine account, unexpected server, or ordinary user context should be treated as a critical alert.

If exploitation is suspected, incident response must go beyond applying the patch. Malicious certificates should be revoked. Certificate revocation lists should be updated and published. Suspicious certificates should be traced to their requesters. Domain Controller authentication activity should be reviewed. Replication logs should be examined. Privileged credentials may need to be rotated.

If attackers accessed the `krbtgt` secret or equivalent Kerberos material, the organization may need a controlled `krbtgt` reset process. This must be done carefully, because Kerberos trust is central to domain operation. However, failing to rotate compromised Kerberos material can allow attackers to maintain long-term access through forged tickets.

Security teams should also check for follow-on persistence. Domain compromise can lead to new privileged accounts, modified group memberships, rogue Group Policy Objects, altered ACLs, shadow credentials, new service principal names, scheduled tasks, remote management changes, and hidden backdoors.

The incident reinforces a broader lesson: AD CS is often deployed once and then ignored for years. That is dangerous. Certificate infrastructure is identity infrastructure. It should be treated with the same seriousness as Domain Controllers, privileged access management, Kerberos, and administrator accounts.

Organizations should maintain a regular AD CS security review program. That includes auditing templates, reducing broad enrollment rights, enforcing manager approval where appropriate, monitoring issuance, disabling unused templates, restricting CA administration, protecting private keys, and documenting all trust relationships.

Least privilege is critical. Not every user needs certificate enrollment rights. Not every template needs client authentication. Not every system needs access to request certificates freely. Certificate issuance should be deliberate, monitored, and justified.

Strong logging is also essential. Without CA logs, Kerberos logs, Windows event logs, and identity telemetry, defenders may not know whether certificates were abused. A certificate-based attack can be quieter than password theft because it uses trusted authentication paths. That is the whole problem: the attacker is not breaking the door. They are getting the certificate authority to print them a key.

Organizations should also validate whether security tools can detect certificate abuse. Many teams monitor failed logins, password spraying, and administrator group changes, but miss certificate enrollment anomalies. Identity detection needs to include AD CS events, PKINIT activity, certificate issuance patterns, and suspicious domain replication behavior.

For executives and risk teams, the business impact is straightforward. A weakness in AD CS can become a domain-wide compromise. That means ransomware risk, data theft, identity takeover, privilege abuse, operational disruption, and costly recovery.

The key lesson is that public exploit code for an AD CS privilege-escalation path should be treated as urgent. This is not only a Windows patching issue. It is an identity security issue.

Organizations should patch Certificate Authorities immediately, audit AD CS templates, restrict enrollment rights, review machine-account creation, monitor certificate issuance, hunt for DCSync, and prepare incident-response steps for certificate-based domain compromise.

Active Directory trust is only as strong as the systems allowed to issue credentials inside it. If attackers can abuse a certificate authority to impersonate a Domain Controller, the domain’s own trust model starts working against the organization. That is not a minor configuration problem. That is the identity layer quietly signing the attacker’s promotion letter.

A proof-of-concept exploit for "Certighost," a Windows Active Directory Certificate Services vulnerability, has been released that can allow authenticated attackers to potentially compromise a Windows domain. [...]

Source: New Certighost PoC exploit lets attackers hijack Windows domains via Bleeping Computer — published 27 Jul 2026.