Steal or Forge Authentication Certificates (T1649) is a Credential Access technique. MITRE lists Windows, Linux, macOS and Identity Provider as platforms. Adversaries steal or forge certificates that are used to authenticate to remote systems or resources.
Certificates are often thought of as plumbing for encryption. MITRE's point is that they are also authentication material. Entra ID device certificates and Active Directory Certificate Services (AD CS) certificates bind to an identity and can work as credentials for domain accounts.
How attackers use it
Certificates can be stolen or forged. AD CS certificates can be taken from encrypted storage in the Registry or in files, from misplaced certificate files (Unsecured Credentials), or from the Windows certificate store through crypto APIs.
With the right enrollment rights, users and machines in a domain can request or renew certificates from enterprise certificate authorities. That process sets the certificate's properties and permissions. Two fields matter. The extended key usage (EKU) values define whether a certificate can sign, encrypt or authenticate. The subject alternative name (SAN) values define the certificate owner's alternate names.
Misconfigurations can let a user impersonate or assume a privileged account through the identity in a certificate's SAN, which enables Privilege Escalation. Abuse of certificates can also support Lateral Movement, and stolen or forged certificates can provide Persistence.
Examples on the page: APT29 abused misconfigured AD CS certificate templates to impersonate admin users and create more authentication certificates. NIMBUS MANTICORE stole and used vulnerable AD CS templates to impersonate higher privileged accounts. AADInternals and Mimikatz can create and export authentication certificates. Mini Shai-Hulud collected victim client certificates to help sign authentication assertions with Azure environments.
How to detect it
MITRE's analytics, by platform:
- Windows: abnormal certificate enrollment and use in AD CS, registry access to certificate storage locations, and unusual processes that try to export or reach private keys.
- Linux: file access to certificate directories, and commands that run OpenSSL or PKCS#12 utilities to export or change certificates, or that touch sensitive key storage paths.
- macOS: security commands and API calls that use the Keychain, and file access to stored certificates and private keys in the user and system Keychains folders under Library.
- Identity providers: abnormal certificate enrollment events, unexpected use of token signing certificates, and unusual changes to certificate authority configuration.
A practical anchor on the CA itself: AD CS records requests and issuance in the Windows Security log (for example Event ID 4886 for a received request and 4887 for an issued certificate). Auditing must be enabled on the CA. Watch for requests that carry a SAN naming someone other than the requester, and for templates that were recently changed.
How to reduce the risk
MITRE lists four mitigations:
- Secure the certificate authority. Treat CA servers and other resources that host CA certificates as tier 0 assets. Harden abusable CA settings and attributes. Consider disabling the use of AD CS certificate SANs within authentication protocol settings, to enforce strict user mappings so certificates cannot authenticate as other identities. Consider requiring CA Certificate Manager approval for templates that include a SAN.
- Remove what you do not need. Disable old or dangerous authentication protocols such as NTLM, and unnecessary certificate features such as vulnerable AD CS web and other enrollment server roles.
- Protect keys. Keep certificates and private keys secured. Consider TPM or hardware security module protection. Enforce HTTPS and enable Extended Protection for Authentication.
- Audit. Check and fix unneeded authentication certificates and common CA misconfigurations, such as enrollment permissions and overly permissive published templates.
Check your own environment
Read-only (Windows, on or against your CA, with appropriate rights):
# List the certificate templates published on the CA
certutil -CATemplates
You can also open the Certification Authority console (certsrv.msc) to review published templates and their permissions.
Then work through:
- Which templates allow the enrollee to supply a SAN, and who can enroll?
- Who has administrative rights on the CA servers, and are they tier 0 accounts?
- Are CA auditing events (4886, 4887) collected centrally?
- Where do exported certificates and PFX files sit on file shares and developer machines?
- Is NTLM still allowed anywhere it does not need to be?
Quick check
Which two certificate fields does MITRE call out?
The extended key usage values, which define use cases such as authentication, and the subject alternative name values, which define the owner's alternate names and can allow impersonation if misconfigured.
Why treat a CA server as tier 0?
Because whoever controls the CA can issue certificates that authenticate as other identities, which is as powerful as controlling the domain.
