Certipy and Certify AD CS Tooling Detection Guide: Catching Certificate Abuse in Active Directory

Certipy and Certify turn a misconfigured certificate template or certificate authority into a domain administrator credential, and the resulting certificate keeps working after the victim's password is reset. Certify is a C# tool released by SpecterOps with the 2021 "Certified Pre-Owned" research; Certipy is a Python toolkit that now covers the ESC1 to ESC17 attack paths, NTLM relay to enrollment endpoints, Shadow Credentials and forged "golden" certificates. Both are used by red teams and by intrusion operators, and both leave evidence in three places: LDAP queries against the configuration partition, certificate authority audit events, and Kerberos certificate logons on domain controllers. This guide sets out what each phase of the tools' workflow looks like in that telemetry, which signals still work when the tool runs from an attacker's own machine, and how to roll out detection safely. It complements the AD CS Security Guide, which covers fixing the misconfigurations themselves, and is written for detection engineers, PKI owners and Active Directory administrators.

This is an independent guide from NHI Mgmt Group, based on the public Certipy and Certify documentation as of November 2026. It is not sponsored or reviewed by either project's maintainers, and it covers detection only.

Key takeaways

• Most Certipy activity never touches a monitored endpoint. Certipy is Python and normally runs off-host, so process and file signatures help mainly against Certify and in-memory loaders; CA and DC logs carry the durable signals.
• CA auditing is off by default. Events 4886, 4887, 4899 and 4900 need the Certification Services audit subcategory and the CA audit filter both set, or the CA records nothing useful.
• The key signal is a mismatch. A certificate whose subject alternative name names a different principal from the requester, followed by a PKINIT logon as that principal, is the core ESC1 style pattern.
• Strong certificate mapping changes what you look for. With domain controllers in Full Enforcement under KB5014754, Kdcsvc events 39, 40 and 41 flag certificates that fail strong mapping, which turns quiet failures into alerts.
• Certificates are persistence. Shadow Credentials writes to msDS-KeyCredentialLink and stolen CA keys let attackers mint certificates at will, so response must include revocation and CA key decisions, not only password resets.

The tools and the workflow they automate

Certify's README describes it as a C# tool to enumerate and abuse misconfigurations in AD CS, built against .NET 4.7.2 and distributed as source only; its authors point to the Certified Pre-Owned whitepaper for prevention and detection guidance and released the defensive PSPKIAudit project alongside it. Certipy's README describes an offensive and defensive toolkit that discovers CAs and templates, identifies misconfigurations, requests and forges certificates, authenticates with them, relays NTLM to AD CS HTTP and RPC endpoints and supports Shadow Credentials, Golden Certificates and certificate mapping attacks.

ATT&CK does not list Certipy as a software entry; the behaviour maps to T1649 Steal or Forge Authentication Certificates, with T1557.001 and T1187 Forced Authentication for the relay paths and T1550.003 for using the resulting tickets.

Telemetry to enable on certificate authorities and domain controllers

Microsoft's "Securing PKI: Appendix A: Events to Monitor" lists the CA events below and the CA audit filter category each one needs. The Windows audit subcategory (Object Access, Certification Services) must also be enabled for success and failure, and the CA audit filter is set with certutil -setreg CA\AuditFilter 127 followed by a Certificate Services restart. The same appendix advises auditing the CA configuration registry key so that changes to EditFlags, including the EDITF_ATTRIBUTESUBJECTALTNAME2 flag behind ESC6, raise event 4657.

See the Active Directory Security Monitoring and Event IDs Guide and the Windows Event Forwarding Guide for collection; CA servers are tier 0 and their Security log belongs in the SIEM alongside the domain controllers.

Detections by attack path

Enrollee-supplied subject (ESC1, ESC6, ESC15, ESC17)

In ESC1 a low-privileged user enrols in a template that lets the requester supply the subject, has an authentication EKU and needs no manager approval, and puts an administrator's UPN or SID in the request. Detect it in 4887 by comparing the requester account with the SAN or subject of the issued certificate; outside a short list of templates designed for this, they should match. ESC6 is the same outcome through the CA-wide EDITF_ATTRIBUTESUBJECTALTNAME2 flag, so also alert on SAN supplied in request attributes. ESC15 (CVE-2024-49019, patched November 2024) injects application policies into version 1 templates such as WebServer; a certificate from a server template later used for client logon in 4768 is the follow-up signal.

Template and CA permission abuse (ESC4, ESC5, ESC7)

Template hijacking changes a template to make it vulnerable, enrols, then often restores it. Alert on every 4899 and 4900 outside a change window, and on 5136 changes to objects under CN=Certificate Templates and CN=OID in the configuration partition. Defender for Identity raises "Suspicious modifications to the AD CS security permissions/settings" (external ID 2435).

Relay to enrollment endpoints (ESC8, ESC11)

Relay attacks coerce a domain controller or server to authenticate, relay that NTLM to web enrollment or the RPC interface and receive a certificate for the machine account. Look for 4887 issuing a DomainController or Machine template certificate where the request came from an IP address that is not the machine itself, and for a DC account's 4768 with certificate fields shortly after. SigmaHQ's "PetitPotam Suspicious Kerberos TGT Request" rule looks for 4768 by a machine account with a certificate thumbprint. Defender for Identity raises "Suspicious Domain Controller certificate request (ESC8)" (2432). Microsoft KB5005413 is the prevention: Extended Protection for Authentication set to Required and Require SSL on Certificate Authority Web Enrollment and the Certificate Enrollment Web Service, and NTLM restricted on AD CS servers. See the NTLM Relay Guide.

Weak mapping (ESC9, ESC10, ESC14, ESC16)

These paths rely on certificates lacking the SID security extension (OID 1.3.6.1.4.1.311.25.2) or on weak explicit mappings. Kdcsvc event 39 shows authentications without a strong mapping and event 41 shows a SID extension that does not match the user. Any certificate template with the msPKI-Enrollment-Flag bit 0x00080000 set (no security extension) or a CA with the extension in its DisableExtensionList should be treated as a finding. See the Kerberos PKINIT and Certificate Mapping Guide.

Shadow Credentials and CA key theft

Certipy's shadow auto mode adds a key credential to a target's msDS-KeyCredentialLink, authenticates with PKINIT, retrieves the NT hash and then removes the key again. A 5136 on that attribute, by an account that is not the Windows Hello for Business or device registration service, is the signal; SigmaHQ's "Possible Shadow Credentials Added" rule keys on it, and it needs a SACL on user and computer objects. The Certipy wiki notes that its CA private key backup creates a temporary service on the CA that runs certutil to export the key, then retrieves the file over SMB: any new service on a CA server is critical. A stolen CA key means forged certificates that never appear in 4887, so the response is CA rebuild or key rollover. See the If your internal PKI and certificate authority is compromised playbook.

Host-side signals for Certify and loaders

• Process metadata: SigmaHQ's "HackTool - Certify Execution" and "HackTool - Certipy Execution" rules match original file names and argument combinations such as find /vulnerable, request /ca: /template: /altname: and auth -pfx. They catch unmodified binaries only.
• In-memory .NET loading: the Certify README itself shows loading the assembly from Base64 in PowerShell; PowerShell script block logging (4104) of [System.Reflection.Assembly]::Load with a large Base64 string is a generic and more durable signal.
• Certificate files: new .pfx files in user profiles or temp folders on workstations, and PFX imports by non-administrative users, are worth a hunting query.

Rolling out detection

1. Inventory CAs and templates: list every enterprise CA, every published template and its enrollment rights. Run your own enumeration with PSPKIAudit or Certipy find in an authorised assessment so you know which ESC paths exist. See How to audit AD CS certificate templates.
2. Turn on CA auditing: enable the Certification Services subcategory, set the audit filter, add the registry SACL and forward the CA Security log. Expect 4886 and 4887 volume proportional to auto-enrolment.
3. Turn on DC signals: confirm 4768 is collected with certificate fields, collect the System log for Kdcsvc events and add SACLs for msDS-KeyCredentialLink and altSecurityIdentities.
4. Write mismatch rules first: requester versus subject in 4887, machine template issued to a requester that is not that machine, template and CA permission changes, new services on CAs.
5. Validate: in a lab or with an authorised red team, exercise ESC1, ESC4 and ESC8 against a test CA and check every rule fires. Keep the events as regression fixtures.
6. Tune and promote: run in alert-only mode for two to four weeks, exclude by template and requesting service account rather than by CA, then page on the high-fidelity rules. Rolling back a rule never means disabling CA auditing.

Decision guidance

Where identity fits

Certificates are credentials, and machine and service identities hold most of them. ESC8 and ESC11 target domain controller and server machine accounts; Shadow Credentials targets any account whose msDS-KeyCredentialLink an attacker can write, including computers and service accounts; and certificates outlive password resets. Treat the CA, its templates and every authentication-capable certificate as part of your non-human identity inventory, with owners and lifetimes. See the Machine Identity, PKI and Certificate Lifecycle Guide and the Securing the internal PKI and certificate authority itself guide.

Detection and measurement

• CA audit coverage: share of enterprise CAs with the audit subcategory, audit filter 127 and log forwarding confirmed; target 100%.
• Vulnerable templates: count of published templates matching any ESC condition in your own enumeration; trend to zero.
• Weak mapping events: weekly count of Kdcsvc 39 and 41 events; investigate every 41.
• Mismatch alerts reviewed: percentage of requester versus subject mismatch alerts triaged within one business day.
• Validation: number of ESC paths exercised in the last authorised test that produced an alert.

Framework mapping

Common failure patterns

• CA logs never collected: DCs are in the SIEM but the CA is not, so ESC1 issuance is invisible and only the later logon is seen.
• Audit subcategory on, audit filter off: the CA records nothing until the AuditFilter value is set and the service restarted.
• Password reset as the only response: certificates and key credentials keep working; revoke the certificates, clear msDS-KeyCredentialLink and check the CA key.
• Staying in Compatibility mode: registry overrides that kept StrongCertificateBindingEnforcement at 1 hid weak mappings; per KB5014754 that option ended with the September 2025 updates.
• Trusting template clean-up: an ESC4 attacker restores the template afterwards, so a clean current state proves nothing without 4899 and 4900 history.

Practitioner checklist

• Enable the Certification Services audit subcategory and set the CA audit filter on every enterprise CA.
• Forward CA Security logs and the DC System log (Kdcsvc) to the SIEM.
• Alert on 4887 where the requester differs from the certificate subject or SAN on authentication templates.
• Alert on 4899, 4900, 4882, 4890 and any new service on a CA server.
• Add SACLs and alert on 5136 changes to msDS-KeyCredentialLink and altSecurityIdentities.
• Apply KB5005413 mitigations to web enrollment and CES, and restrict NTLM on CA servers.
• Confirm domain controllers are in Full Enforcement and investigate every Kdcsvc event 41.
• Run an authorised enumeration and fix every ESC finding, starting with ESC1, ESC4 and ESC8.
• Write a response step for certificate revocation and CA key compromise into the AD incident playbook.

Standards and references

• MITRE ATT&CK: Steal or Forge Authentication Certificates (T1649)
• Microsoft: KB5014754 Certificate-based authentication changes on Windows domain controllers
• Microsoft: KB5005413 Mitigating NTLM Relay Attacks on Active Directory Certificate Services
• Microsoft Learn: Securing PKI, Appendix A: Events to Monitor
• Microsoft Learn: Microsoft Defender for Identity classic security alerts
• SpecterOps GhostPack: Certify repository and defensive considerations
• Certipy: project wiki
• SigmaHQ: Sigma detection rule repository

Related NHI Mgmt Group resources: AD CS Security Guide · Kerberos PKINIT and Certificate Mapping Guide · Impacket Detection Guide · Active Directory Domain Compromise Response Playbook · ITDR Guide