Certighost: Escalating AD User to DC via Certificate Services
Just caught the release of the 'Certighost' exploit by H0j3n and Aniq Fakhrul. It's a pretty significant finding regarding Active Directory Certificate Services (ADCS).
The exploit allows a low-privileged user to request a certificate for a Domain Controller account. Since DCs have directory replication rights, obtaining a valid cert for that machine account lets an attacker perform a Kerberos authentication as the DC. Once they have that context, they can run DCSync to dump the krbtgt hash and effectively own the domain.
This feels like a severe variation of the ESC8/ESC1 vulnerabilities we've seen, but specifically targeting the high-privilege DC objects. If an attacker can specify a Subject Alternative Name (SAN) for the DC, the game is over.
You should immediately audit your certificate templates to ensure low-privileged users do not have enrollment rights on templates that allow for client authentication or EKU usage suitable for domain authentication.
Here is a quick PowerShell snippet to find templates that allow the enrollee to supply the subject name (a common prerequisite for this attack type):
Get-ADObject -LDAPFilter "(objectClass=pKICertificateTemplate)" -Properties msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag | Where-Object {
$_."msPKI-Certificate-Name-Flag" -band 0x0001 # CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
} | Select-Object Name, DistinguishedName
Is anyone seeing this in the wild yet, or are we all scrambling to patch ADCS configurations before the PoCs become widespread?
This is why ADCS is often called 'Active Directory's second backdoor.' I ran the Certify tool in my lab against a default 2022 instance, and the number of templates vulnerable to SAN spoofing is still way too high. If you haven't checked your 'User' or 'Machine' templates for 'Enroll' permissions for 'Authenticated Users', you need to do it now. This Certighost method just streamlines the weaponization of that misconfig.
From a SOC perspective, detecting the initial certificate request is key. You want to monitor Event ID 4886 (Certificate Request - Pending) and 4887 (Certificate Request - Issued) on your CA servers. Specifically, watch for requests where the 'Requester' is a standard user, but the 'Certificate Template' or 'Subject' fields reference a Domain Controller account.
We've started using PSPKIAudit for this exact scenario. It automates the checks for dangerous template configurations. Also, verify if you have the 'Domain Controllers' group explicitly listed with Enroll permissions on templates that aren't strictly for the DC itself. The rule of thumb should be: if you don't need it, disable enrollment.
Definitely a critical vector. Once you have the certificate, leveraging Rubeus to request a TGT is the standard play. Here's the command to convert that PFX into a Kerberos ticket:
Rubeus.exe asktgt /user:DC01$ /certificate:base64encodedcert /ptt
Also, don't sleep on ESC8. If "Manage CA" permissions are weak, you can edit the msPKI-Certificates-Name-Flag on a template without needing approval, making this even harder to detect in some environments.
Beyond just auditing, specifically check for the ENROLLEE_SUPPLIES_SUBJECT flag on your templates. This setting (bitmask 0x00000001) allows the requester to define the Subject Alternative Name, which is the core enabler of the impersonation. You can query AD for this misconfiguration using the following:
Get-ADObject -LDAPFilter "(objectClass=pKICertificateTemplate)" -Properties msPKI-Certificate-Name-Flag | Where-Object { $_."msPKI-Certificate-Name-Flag" -band 1 }
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access