Unit 42's recent write-up on Active Directory Certificate Services exploitation is worth treating as more than another Windows domain-hardening note. The useful signal is not that certificates can be abused. That has been known for years. The signal is that AD CS has become a practical identity-escalation route that defenders often monitor less closely than passwords, privileged groups or Entra ID sign-in events.
There is no single CVE to anchor this topic. There is no canonical CloudSigma rule to name. The right unit is the behaviour: certificate template misuse, shadow credential registration and certificate-backed Kerberos authentication that can turn a low-privileged foothold into domain control.
Why AD CS belongs in identity monitoring
AD CS issues and manages certificates for Windows environments. In healthy deployments, that gives users, machines and services a controlled way to prove identity, sign traffic and authenticate without falling back to passwords for every exchange. The problem is that the same machinery can become an escalation layer when certificate templates, enrolment rights or account key mappings are too broad.
Unit 42 describe AD CS as a foundational PKI component with a large security gap: certificate templates define who can request certificates and what those certificates can do. If a low-privileged account can enrol in a template that permits authentication as another identity, the attacker has not exploited memory corruption or dropped malware. They have used the identity system as configured.
That distinction matters for detection. A lot of SOC alerting still treats identity compromise as password theft, suspicious MFA prompts or privileged group membership changes. AD CS misuse can sit outside that mental model. The artefacts are certificate requests, template loads, directory attribute changes and Kerberos activity. They look administrative because they are administrative. That is why a certificate services finding should sit next to identity-provider telemetry, not in a forgotten PKI backlog.
The cloud angle is indirect but real. Many organisations now bridge old Active Directory estates into cloud control planes through synchronisation, federation and hybrid administration. A domain escalation path that starts with AD CS may end with access to cloud administration, source repositories, SaaS consoles or privileged service accounts. The first suspicious event might be in a domain controller log, but the blast radius is no longer limited to the domain.
The attack chain
The pattern Unit 42 describe has five useful stages for defenders.
First, the attacker needs a starting account. That can come from phishing, infostealer logs, password reuse, exposed remote access or any other initial access path. It does not need to be a domain admin. AD CS abuse is attractive because the first credential can be modest.
Second, the attacker enumerates the certificate infrastructure. They look for certificate authorities, certificate templates, enrolment permissions and account key attributes. Tools such as Certify and Certipy exist because this discovery phase is repeatable. From a monitoring point of view, that makes LDAP search volume and template enumeration useful early warning. A user account that rarely performs directory administration should not suddenly ask the directory for sensitive certificate objects at volume.
Third, the attacker abuses a weak template or account mapping. One common path is a template that lets the requester supply the subject in the certificate signing request. Another is broad enrolment rights, for example giving Domain Users access to a template that can produce authentication material with higher impact than intended. The template may have been created for a legitimate business process years ago, then left in place after the process changed.
Fourth, the attacker converts certificate material into access. With PKINIT, a certificate can be used in Kerberos authentication. That lets the attacker request tickets and impersonate the target identity. The resulting activity may not contain the stolen-password fingerprints defenders expect. It is alternate authentication material doing the work.
Fifth, the attacker looks for persistence. Shadow credentials are the important case here. By modifying msDS-KeyCredentialLink, an attacker can associate their own key material with a target account. Password resets and ordinary account lockouts may not remove that access path. If the defender only rotates passwords, the back door can remain.
What to collect
A useful AD CS detection plan starts with log coverage, not with a single rule. Unit 42 list several event families that matter: certificate request and issuance events, certificate template load events, directory service object modifications, Kerberos ticket requests and LDAP client or server search events. In Windows event terms, that means looking at events such as 4886, 4887, 4898, 5136, 4768 and 4769, plus LDAP telemetry where available.
Those events need correlation. Event 4886 on its own may be normal. Event 5136 on its own may be a harmless account change. LDAP queries against certificate templates may be part of an administrator's review. The useful signal appears when a non-administrative identity enumerates certificate infrastructure, a risky template is loaded or used, a key credential attribute changes, and Kerberos authentication follows from the same identity or host.
The first practical control is a template inventory. List every template that can be used for client authentication. For each one, record who can enrol, whether manager approval is required, whether authorised signatures are required and whether the requester can supply subject information. Anything available to broad groups deserves review before it becomes detection logic. A SIEM cannot compensate for a template that gives the whole domain an escalation path.
The second control is change monitoring. Template changes, certificate authority configuration changes and modifications to msDS-KeyCredentialLink should be treated like privileged identity changes. They are not routine noise. If a helpdesk account, workstation account or service account changes key credential material for a privileged identity, that deserves the same urgency as a direct group membership change.
The third control is Kerberos context. PKINIT-backed TGT requests are not suspicious by default, especially in environments using smartcards or Windows Hello for Business. The question is whether the request matches the normal population of certificate-backed authentication. A new host, a new user, a new certificate template or a request immediately after suspicious LDAP discovery is the pattern to chase.
Detection engineering notes
Map the behaviour to ATT&CK before writing rules. The main technique is T1649, Steal or Forge Authentication Certificates. Shadow credential registration also sits close to T1556, Modify Authentication Process, because the attacker changes how an account can authenticate. PKINIT and certificate-backed ticket requests align with T1550, Use Alternate Authentication Material. The reconnaissance stage maps to T1087, Account Discovery, when the attacker enumerates users, groups and identity objects.
That split avoids a common rule-writing mistake: trying to make one alert cover the whole chain. A better approach is staged detection. One low-severity analytic catches unusual AD CS enumeration. Another watches risky certificate template use. A third watches msDS-KeyCredentialLink changes. A fourth watches certificate-backed Kerberos authentication from unusual hosts or users. The incident is raised when these signals converge.
False positives are mostly administrative. PKI administrators review templates. Identity engineers test smartcard flows. Endpoint management platforms may trigger certificate enrolment across large device groups. That does not make the signals useless. It means the allowlist must be explicit: known PKI admins, known management hosts, known enrolment services and known smartcard or Windows Hello deployment windows. Everything else should remain visible.
Cloud security teams should care because hybrid identity is often the bridge between a quiet domain compromise and a noisy cloud event. If on-prem Active Directory can mint or map authentication material for identities that administer cloud-connected systems, AD CS becomes part of cloud incident response. A cloud-only view will see the later privileged action. The certificate-services logs explain how the identity became privileged enough to do it.
What to do now
Start with a read-only review of AD CS rather than a template clean-up spree. Inventory certificate authorities, templates, enrolment rights and templates that permit client authentication. Identify broad enrolment groups and templates where the requester can supply subject details. Mark which templates are genuinely required for production workflows.
Next, turn on the audit events needed to see certificate requests, template use, directory modifications and Kerberos authentication. If those logs are not in the SIEM, route them before writing correlation logic. A rule that depends on missing event IDs is theatre.
Then write three small detections: unusual AD CS enumeration by non-admin users, msDS-KeyCredentialLink modification outside known administration paths, and certificate-backed Kerberos requests that appear after certificate template activity. Treat the first as a hunt signal, the second as high-severity, and the third as a correlation signal that raises confidence.
Finally, rehearse the response. A suspected shadow credential case is not fixed by resetting the user's password. The responder must inspect and clean key credential links, review certificate issuance, revoke malicious certificates where possible, and check downstream access that used the forged or alternate authentication material. If the environment links Active Directory to cloud administration, the cloud audit log review belongs in the same incident, not in a later ticket.
The core lesson from Unit 42's research is blunt: certificate services are identity infrastructure. If they are monitored like background plumbing, attackers get an escalation path that looks like normal administration until the damage is already done.
References
Unit 42: Inside AD CS Escalation - https://unit42.paloaltonetworks.com/active-directory-certificate-services-exploitation/
Microsoft Active Directory Certificate Services overview - https://learn.microsoft.com/windows-server/identity/ad-cs/active-directory-certificate-services-overview
MITRE ATT&CK T1649 Steal or Forge Authentication Certificates - https://attack.mitre.org/techniques/T1649/
MITRE ATT&CK T1556 Modify Authentication Process - https://attack.mitre.org/techniques/T1556/
MITRE ATT&CK T1550 Use Alternate Authentication Material - https://attack.mitre.org/techniques/T1550/
MITRE ATT&CK T1087 Account Discovery - https://attack.mitre.org/techniques/T1087/