Detect AD Certificate Services attack tools such as Certify and Certipy by watching for unusual certificate template enumeration, enrolment abuse, CA configuration changes, and unexpected certificate requests from administrative or non-administrative hosts. Correlate those events with privileged account activity and certificate issuance patterns. Focus on behaviour rather than tool names, because the same abuse can be performed with different tooling.
What patterns reveal AD CS reconnaissance and abuse?
Tooling such as Certify and Certipy usually leaves a behavioural trail before it leaves a forensic one. The most useful signal is not a process name, but a sequence: certificate template discovery, directory and CA enumeration, followed by requests that match abuse-prone templates or unusual enrollment paths. In mature environments, that sequence stands out because legitimate administration is usually narrower, scheduled, and tied to known host identities.
Detection gets stronger when you correlate the template and CA activity with the source host, the account used, and the timing. Administrative workstations may query many objects, but they should not routinely generate repeated template probing, certificate request failures, or requests from systems that do not normally manage PKI. For background on the control surface that attackers probe, see the AD CS Security Guide.
Watch for changes that alter the trust boundary, especially CA configuration edits, template permission changes, enrollment service adjustments, and unexpected publication or renewal behaviour. Those events matter because AD CS abuse often depends on combining discovery with a configuration weakness. A request that looks ordinary in isolation can become highly suspicious when it follows template enumeration from the same endpoint and account.
Which telemetry matters most for hunting Certify and Certipy?
Prioritise certificate template access, CA administrative actions, and certificate issuance logs, then enrich them with endpoint and identity telemetry. Look for bursty enumeration, repeated access to high-value or vulnerable templates, and certificate requests that come from hosts or principals that are not known enrollment clients. It is especially important to compare the requester, the subject name, and the certificate template against normal issuance patterns for that environment.
On the identity side, correlate privileged account activity with the issuance event itself. A certificate request initiated after privileged logon, remote administration, or directory reconnaissance is more meaningful than the same request in isolation. If your logging includes request attributes such as subject alternative name, requester information, and template name, those fields help separate normal enrollment from attempts to obtain a certificate that can be used for impersonation or persistent access.
Host-based telemetry also helps. Certify and Certipy are often run from operator workstations, jump hosts, or compromised internal systems, so look for command-line anomalies, script execution, and short-lived tooling activity around PKI-related queries. The goal is to build a time-linked chain from discovery to enrollment to privilege use, not to wait for a named binary to appear in isolation.
How should defenders validate and respond to suspicious certificate activity?
When the behaviour looks abnormal, validate the scope of exposure first: which templates were queried, which templates were requested, what certificate was issued, and whether the issuing CA accepted a request that should have been denied. That analysis determines whether you are seeing harmless reconnaissance or a path to impersonation, persistence, or domain escalation. The more permissive the template, the more urgent the review.
If you find a suspicious request that succeeded, inspect whether the certificate could authenticate to sensitive services, whether the subject mapping is stronger than it should be, and whether the resulting certificate is still valid and usable. If the request failed, that does not make it harmless, because the same actor may already have learned enough about the environment to refine the next attempt. For lifecycle and cryptographic handling considerations around certificates, Machine Identity, PKI and Certificate Lifecycle Guide is a useful companion reference.
Response should also include review of the CA, template ACLs, and any accounts that may have been exposed through issued certificates. Where abuse is confirmed or strongly suspected, treat the certificate like stolen authentication material: revoke or invalidate what you can, review related sessions and dependent trust paths, and search for earlier use of the same template or host pattern. If the same request pattern appears across multiple machines, the issue is likely systemic rather than isolated.
Risk and Threat Considerations
AD CS abuse is attractive because certificate-based trust can outlive the initial access path. A single weak template, overbroad enrollment right, or misconfigured CA can turn reconnaissance into durable impersonation without repeated password theft. Detection has to catch the preparatory steps early, because once a usable certificate is issued, the attacker may no longer need the original foothold.
Failure mechanism: Attackers enumerate templates and CA settings to find enrollment paths that allow subject control, weak mapping, or unauthorized issuance, then use the resulting certificate to authenticate as a more privileged identity.
Impact: The result can be persistent access, privilege escalation, and harder-to-detect lateral movement because the activity now looks like legitimate certificate-based authentication rather than obvious password abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1552 — Unsecured Credentials | Cert tools often seek certificate-based credentials and impersonation paths. |
| T1649 — Steal or Forge Kerberos Tickets | AD CS abuse can enable certificate-backed impersonation and downstream ticket abuse. | |
| Recommendation — Map certificate abuse activity to credential-access patterns and hunt for unauthorized certificate use. Correlate certificate issuance with privilege use and investigate forged authentication paths. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | Detecting Certify or Certipy requires monitoring enumeration and issuance behaviour. |
| PR.AA-05 — Access permissions, entitlements, and authorizations are managed | Abuse often depends on excessive template and CA permissions. | |
| Recommendation — Instrument certificate and identity telemetry to detect anomalous AD CS activity. Review and tighten template and CA permissions that enable unauthorized enrollment. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | AD CS detection depends on reviewing CA and directory audit events for abuse patterns. |
| Recommendation — Review CA audit data for template enumeration, enrollment anomalies, and privileged issuance. | ||
Practitioner Guidance
What to verify: Check whether your logs can distinguish template enumeration from normal enrollment, and whether CA events include enough detail to tie a request back to the host and account that made it. If you cannot make that distinction, your current telemetry is not sufficient for reliable hunting.
Decision rule: If you see template probing plus a successful certificate issuance from an unusual host, treat it as a potential compromise path and investigate identity use immediately, rather than waiting for downstream authentication failures or endpoint alerts.
What good looks like: Legitimate enrollment is predictable, inventoryable, and tied to known requesters, while suspicious activity shows a clear mismatch between source host, requester role, template choice, and issuance timing.
Practitioner takeaway: The strongest detections focus on the abuse chain, not the tool, because the same AD CS pattern can be executed with different binaries, scripts, or operator workflows.