Certighost: AD CS Nightmare? Low-Priv Users to Domain Admin in One Step
Just saw the write-up on Certighost released by H0j3n and Aniq Fakhrul. We’ve all known Active Directory Certificate Services (AD CS) is a messy attack surface (looking at you, ESC1 and ESC8), but this new exploit is terrifying. It allows a standard low-privileged user to obtain a certificate for a Domain Controller computer account.
Since DC accounts have directory replication rights, the resulting Kerberos credential allows for an immediate DCSync attack. That means full domain compromise in minutes without needing to touch the LSASS process on the DC itself.
I'm currently scrambling to update our SIEM detections. We need to flag any certificate requests where the requested Subject or SAN matches a Domain Controller computer account, specifically when the requestor isn't a known service account.
Here is a basic KQL query to start hunting for suspicious issuance events in Azure Sentinel / Defender:
SecurityEvent
| where EventID == 4880 // Certificate Request Issued
| where Subject contains "DC$" or Subject contains "Domain Controller"
| project TimeGenerated, Subject, RequesterAccount, RequesterName
| where RequesterAccount !contains "$" // Exclude machine accounts requesting their own
Curious if anyone else is seeing evidence of this in the wild or if we're all just scrambling to audit our template enrollment rights. How are you handling the mitigation on your AD CS infrastructure?
Solid KQL start. We're taking it a step further and correlating the RequesterAccount against the 'Certificate-Request-Attributes' field in the logs. Usually, if a non-admin requests a cert with a DC subject, the RequesterName won't match the Subject. We're also blocking any non-DC IP addresses from connecting to the Certification Authority Web Enrollment pages as a temporary stopgap.
This changes the pentest game completely. I'm checking if Certipy or Certify has added a module for this yet. It reminds me a lot of the recent SPN spoofing trends, but leveraging PKI is much stealthier. If you haven't already, I'd suggest running certipy ad find -vulnerable to ensure you aren't exposing standard templates that allow arbitrary SANs, which might be a prerequisite for this specific vector.
Is there any indication if this requires specific template configurations or if it works on a vanilla MS-CSRAS setup? The write-up was a bit light on the technical mechanics. I'm worried that simply restricting enrollment rights on the 'DC' template won't be enough if there's a subordinate CA logic flaw involved.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access