PKI security | Active Directory Certificate Services | MITRE ATT&CK

From AD CS Misconfiguration to Identity Attack Path: Mapping PKI Risk to MITRE ATT&CK

Certificate findings are often presented as isolated configuration issues: a template permits broad enrollment, a subject name can be supplied by the requester, or a CA private key is poorly protected. For defenders, the important question is what an attacker could do with that condition. Could they obtain a certificate that authenticates as another identity? Steal a machine credential? Forge certificates after compromising a CA? Discover the organization’s infrastructure through public certificate data?

MITRE ATT&CK provides a useful vocabulary for describing those behaviors and connecting a PKI finding to its potential security outcomes. It does not replace a technical assessment, prove that a path is exploitable in a particular environment, or certify that a control is effective. Used carefully, however, ATT&CK mapping helps turn a list of PKI settings into an explainable attack path, supporting evidence, and remediation plan.

This article focuses on three certificate-related techniques—T1649, T1596.003, and T1588.004—and the relevant MITRE mitigations and detection guidance. It also shows how a PKI auditing product can model configuration findings without overstating what ATT&CK says.

Start with behaviors, not labels

MITRE ATT&CK describes adversary behaviors. It is not a catalog of AD CS vulnerabilities, and ESC classifications are not ATT&CK technique IDs. A useful mapping therefore has at least two layers:

• Configuration condition: what was measured, such as an enrollment right, template flag, EKU, CA setting, private-key location, or CA audit configuration.
• Potential adversary behavior: what the condition could enable, such as requesting an authentication certificate for another identity, stealing a credential certificate, or forging certificates with a compromised CA key.

The mapping should be conditional. A risky template is evidence of a configuration weakness; it does not by itself prove that a low-privileged identity can complete an attack. Enrollment rights, template settings, CA publication and policy, domain configuration, certificate mapping rules, patch level, and other controls can change the outcome. Record those prerequisites instead of collapsing them into a generic “domain compromise” finding.

T1649: Steal or Forge Authentication Certificates

MITRE ATT&CK T1649 – Steal or Forge Authentication Certificates is the main technique for AD CS findings that may expose certificate-based authentication. ATT&CK notes that certificates can bind to identities and function as credentials. It describes both theft of existing certificates and abuse that enables an adversary to obtain or forge authentication-capable certificates.

For AD CS, the certificate’s Extended Key Usage (EKU), identity fields such as the Subject Alternative Name (SAN), enrollment permissions, and CA/template configuration can affect whether a certificate can authenticate and which identity it represents. The technique also covers theft from files, registry or certificate stores, and forgery using compromised root or subordinate CA private keys—including what is commonly called a “golden certificate.”

Outcomes may include credential access, privilege escalation, lateral movement, or persistence, depending on the certificate and the environment. A certificate can remain usable after a password reset if it has not expired or been revoked and the relying systems continue to trust it. State the possible outcome and its conditions; do not claim every certificate misconfiguration creates every ATT&CK impact.

Mapping common AD CS findings to T1649

Auditor finding	Relevant ATT&CK mapping	What to validate before assigning risk
Authentication certificate with private key exported or stored insecurely	T1649 – certificate theft / credential access	Does the certificate permit authentication? Is the private key present, exportable, accessible, or actually exposed?
Template permits requester-controlled identity information	T1649 – potential certificate-based impersonation	Check enrollment rights, EKU/application policies, CA issuance settings, certificate mapping behavior, and whether an attacker can request the target identity.
Overly broad enrollment permissions	T1649 – potential acquisition of an authentication certificate	Identify the principals with enrollment rights and combine that with template purpose, subject/SAN behavior, and CA policy.
Weak access control over a certificate template	T1649 when the resulting changes could enable credential certificates	Confirm who can modify the template and which effective changes are permitted; do not equate write access alone with successful impersonation.
CA private key or key-protection boundary compromised	T1649 – certificate forgery / persistence	Determine CA scope, key use, certificate trust and revocation coverage; treat CA private-key exposure as a high-impact incident.
Machine authentication certificate exposed	T1649 – certificate theft; possible lateral movement	Confirm account mapping, machine identity privileges, certificate validity, key accessibility, and which services accept it.
Unexpected publicly visible certificate details	T1596.003 – reconnaissance context	Distinguish routine public certificate transparency from an actual sensitive disclosure or later intrusion indicator.

These are analyst mappings, not a claim that MITRE assigns every ESC label to a particular sub-technique. ATT&CK provides the behavior-level technique; the product should preserve its own finding identifier, evidence, prerequisites, confidence, and remediation alongside the ATT&CK reference.

Where ESC classifications fit

ESC labels are a practical way to classify known AD CS abuse patterns. They complement ATT&CK: an ESC finding describes a configuration pattern; T1649 describes the adversary behavior that may result. Do not present ESC itself as an ATT&CK technique or imply that every vulnerability in an ESC family has identical prerequisites.

ESC1-style requester-controlled identity

A template that allows a requester to supply identity details, combined with enrollment access and authentication-capable certificate use, may enable a requester to obtain a certificate representing another identity. The risk path can be described as:

Low-privileged principal with enrollment access → requests a certificate with a different identity → CA issues it → relying system accepts certificate authentication.

The chain must be validated end to end. Check whether the subject/SAN can be specified, whether the certificate is valid for authentication, whether the requester can enroll, whether the CA will issue the request, and whether current certificate-mapping protections prevent the intended impersonation.

ESC4-style template control

If an identity can change a template’s permissions or security-relevant properties, an attacker may be able to create or enable a more abusable issuance path. Model this as a chain: effective template modification permission → a consequential template change → enrollment and issuance → authentication as an identity. The ATT&CK mapping belongs on the resulting certificate theft/forgery behavior (T1649), with the template-change condition separately recorded and evidenced.

CA control and “golden certificate” risk

Control of a CA signing key is materially different from an unsafe leaf-certificate template. An attacker able to use a trusted CA private key may be able to forge certificates beyond the scope of one template. Treat CA hosts, CA configuration, key stores, backup copies, ceremony systems, and privileged CA operators as part of the trust boundary. A key-compromise finding should have a response path for scoping certificates, removing trust, revoking or replacing material, and reaching clients that do not consume browser blocklists.

T1596.003: certificate data as reconnaissance

MITRE ATT&CK T1596.003 – Search Open Technical Databases: Digital Certificates covers adversaries searching public certificate information to learn about organizations and their infrastructure. Publicly observable certificate data can reveal hostnames, subdomains, organization names, service relationships, and certificate issuers or lifecycle patterns.

This is a different behavior from stealing or forging an authentication certificate. T1596.003 is reconnaissance: publication of a certificate is not itself proof of compromise, and public Certificate Transparency logs are designed to make issuance visible. A defensible product should describe this as external exposure or reconnaissance context, not mark every public certificate as a vulnerability.

For example, certificate inventory can help an organization identify unexpected hostnames or services and understand what information is publicly discoverable. That visibility may support attack-surface management, but prevention and detection are limited because the lookup happens outside the organization’s network. Prioritize reducing unnecessarily sensitive metadata and looking for downstream activity rather than promising that CT searches can be stopped.

T1588.004: certificates used in adversary infrastructure

MITRE ATT&CK T1588.004 – Obtain Capabilities: Digital Certificates describes adversaries obtaining SSL/TLS certificates—by purchasing or stealing them—to support operations such as establishing trusted-looking infrastructure or encrypting command-and-control traffic. ATT&CK places this under Resource Development.

This is not the same as T1649. T1588.004 concerns obtaining a certificate for adversary-controlled operations; T1649 concerns stealing or forging certificates used as authentication credentials to access systems or resources. The certificate artifact is related, but its role in the attack is different. Keep those technique mappings separate in reports and avoid suggesting that a publicly issued TLS certificate is evidence of an authentication attack.

Mitigations: connect the finding to controls

ATT&CK lists several mitigations relevant to T1649. Use the official guidance as a starting point, then translate it into controls the customer can verify in their environment.

• M1015 – Active Directory Configuration: MITRE’s T1649-specific guidance recommends securing CAs as Tier 0 assets, hardening abusable CA settings, enforcing strict identity mappings for certificate authentication, and considering approval for templates that allow SAN values.
• M1047 – Audit: review existing authentication certificates, enrollment permissions, published templates, and CA settings. A product can support this by recording evidence, effective access, affected principals, and remediation state.
• M1041 – Encrypt Sensitive Information: protect certificates and associated private keys. Hardware-backed protections such as TPMs or HSMs may strengthen key protection where appropriate; validate operational controls and access, not just the presence of hardware.
• M1042 – Disable or Remove Feature or Program: reduce exposure from unnecessary or vulnerable features and services. For AD CS, decisions about enrollment endpoints or legacy services should be based on actual business requirements and a safe migration plan.

A mitigation mapping does not mean a scanner can automatically enforce the mitigation, or that a particular setting alone fully addresses the technique. Report control status separately from technique mapping.

Detection: separate certificate misuse from certificate exposure

ATT&CK’s detection strategy DET0240 is associated with T1649 and provides platform-specific analytic guidance. For Windows and AD CS, ATT&CK describes monitoring certificate-related activity, including authentication requests and access to certificate stores. These analytics are starting points, not ready-made rules: organizations must confirm the required telemetry is enabled, collectable, and correctly correlated in their environment.

For public-certificate reconnaissance, DET0831 maps to T1596.003. MITRE notes that this behavior may be common, have high false-positive rates, and occur outside the target’s visibility. Treat it as external threat-intelligence context and pivot toward subsequent activity, rather than presenting it as an endpoint alert that can reliably identify who queried a public database.

For PKI teams, useful monitoring questions include:

• Are certificate requests, issuance, denial, pending status, revocation, and template/CA changes logged?
• Are unusual authentication-capable certificates, SAN values, enrollment volume, requester identities, or CA administrative actions reviewed?
• Can certificate issuance be correlated with authentication events and the certificate serial or thumbprint?
• Are certificate stores and private-key access monitored on workstations, servers, build systems, and CA infrastructure?
• Are logs retained and protected long enough to investigate a suspected issuance or theft?

These are operational questions, not universal event IDs or detection rules. Validate event semantics, audit configuration, Windows versions, CA role, and available data before writing an analytic. Avoid claiming a specific event is always generated or that ATT&CK guarantees detection in every deployment.

A product model for PKI attack paths

A practical data model for PKI Trust Auditor can connect technical evidence to attack behavior without hiding the underlying facts:

1. PKI asset: CA, template, enrollment endpoint, certificate, key store, or relying service.
2. Configuration finding: exact measured setting, access control, certificate property, or missing audit signal.
3. ESC classification: applicable AD CS misconfiguration family, if supported by evidence.
4. Prerequisites: effective enrollment rights, authentication EKU, identity control, CA issuance policy, mapping behavior, or key exposure.
5. Attack path: a human-readable sequence from principal or asset to possible certificate-based access.
6. ATT&CK mapping: technique or sub-technique with a clear rationale—T1649, T1596.003, or T1588.004 as applicable.
7. Impact and confidence: potential consequences, business context, evidence quality, and unresolved assumptions.
8. Mitigation and remediation: mapped ATT&CK mitigation plus concrete environment-specific steps.
9. Verification: owner, remediation status, supporting evidence, and rescan result.

For example, a report might say: “Template permits requester-supplied identity information. The template is published by CA X, and group Y has enrollment rights. The template includes an authentication-capable EKU. This combination may enable certificate-based identity impersonation, mapped to T1649. Validate certificate mapping and CA issuance controls before confirming exploitability.” That is more useful—and more accurate—than simply declaring “ESC1 means Domain Admin.”

How PKI Trust Manager and PKI Trust Auditor fit

PKI Trust Auditor can surface configuration and audit evidence: templates, effective permissions, CA settings, certificate properties, issuance activity, and the trust boundaries around CA private keys. PKI Trust Manager can support lifecycle operations such as inventory, issuance, renewal, monitoring, and policy-driven workflows. Together, they can help organizations see where a risk exists and maintain control over certificate lifecycle changes.

ATT&CK provides a common language for describing adversary behavior; it is not a vulnerability scanner, a compliance certification, or proof that an attack path is exploitable. The product should show the observed condition, explain assumptions, map only the relevant behavior, and distinguish a potential path from a validated exploit or incident.

Conclusion

Certificate-related risks span several stages: public certificate data can assist reconnaissance (T1596.003); adversaries can obtain certificates for their infrastructure (T1588.004); and authentication certificates can be stolen or forged to access identities and systems (T1649). The same object—a digital certificate—can play very different roles in those behaviors.

For AD CS findings, T1649 is the central mapping when evidence suggests authentication certificate theft, abuse, or forgery. Use M1015, M1047, M1041, and M1042 as mitigation references where their guidance applies. Treat ESC classifications as technical context, DET0240 and DET0831 as detection-strategy guidance, and validate all environment-specific prerequisites before assigning severity or claiming impact.

Sources

• MITRE ATT&CK: T1649 – Steal or Forge Authentication Certificates
• MITRE ATT&CK: T1596.003 – Search Open Technical Databases: Digital Certificates
• MITRE ATT&CK: T1588.004 – Obtain Capabilities: Digital Certificates
• MITRE ATT&CK: M1015 – Active Directory Configuration
• MITRE ATT&CK: M1047 – Audit
• MITRE ATT&CK: M1041 – Encrypt Sensitive Information
• MITRE ATT&CK: M1042 – Disable or Remove Feature or Program
• MITRE ATT&CK: DET0240 – Detection Strategy for Steal or Forge Authentication Certificates
• MITRE ATT&CK: DET0831 – Detection of Digital Certificates
• MITRE ATT&CK: DS0026 – Active Directory