AD CS
Last updated
Last updated
Enrolee can request cert for ANY user
ESC2
Any purpose or no EKU (potentially dangerous)
Request an enrollement agent certificate and use it to request cert on behalf of ANY user
ESC4
Overly permissive ACLs on templates
ESC5
Poor access control on CA server, CA server computer object, etc.
EDITF_ATTRIBUTESUBJECTNAME2 setting on CA - Request certs for ANY user
ESC7
Poor access control on roles on CA authority like "CA Administrator" and "Certificate Manager"
NTLM relay to HTTP enrollement endpoints
If you have admin privilege, the module will impersonate all users connected -> ask a certificate (ADCS) -> retrieve the NT hash using PKINIT
AD CS in the target forest
Templates
Vulnerable templates
Vulnerable template
Only ESC1 to ESC8
"VulnTemplate" has ENROLLEE_SUPPLIES_SUBJECT value for msPKI-Certificates-Name-Flag
"VulnTemplate" allows enrollment to RDPUsers group.
Request a certificate for DA (or EA) as a user1 (member of RDP group)
Convert cert.pem to pfx and use it to request a TGT for DA (or EA)
If Got error while trying to request certificate: code: 0x80094811 - CERTSRV_E_KEY_LENGTH - The public key does not meet the minimum size required by the specified certificate template, Go back to the certipy find result and get the RSA Key Length. Append it to the command: -key-size
Find vulnerable templates
Exploit
Request an enrollement agent certificate and use it to request cert on behalf of ANY user
"VulnTemplateEnrollement-Agent" allows Domain users to enroll and has 'Certificate Request Agent' EKU
"VulnTemplateEnrollement-Users" has an Application Policy Issuance Requirement of Certificate Request Agent and has an EKU that allows for domain authentication
child.parent.local: child domain
parent.local: parent domain
Request a certif for Certificate Request Agent from "VulnTemplateEnrollement-Agent" template
Convert cert.pem to pfx and use it to request a cert on behalf on DA using "VulnTemplateEnrollement-Users"
Convert from cert.pem to pfx, request DA TGT and inject it
Request a certif for Certificate Request Agent from "VulnTemplateEnrollement-Agent" template - see Escalation to DA
Convert cert.pem to pfx and use it to request a cert on behalf on EA using "VulnTemplateEnrollement-Users
Request EA TGT and inject it
Clean up
EDITF_ATTRIBUTESUBJECTNAME2 setting on CA - Request certs for ANY user from a template that allow enrollment to low-priv user
"Vuln-Integration" grants enrollment to RDPUsers group.
Request a certificate for DA (or EA) as a user1 (member of RDP group)
Convert cert.pem to pfx and use it to request a TGT for DA (or EA)
NTLM relay to HTTP enrollement endpoints
On the attacker system:
On a domain-joined system:
Relay with ntlmrelayx.py to the ADCS Web enrollment Endpoint:
The TrustedSec team tested the CVE-2024-49019 vulnerability across multiple clients, finding that 10 out of 15 environments were at risk
Detection: Bloodhound query
The following security controls should be implemented to mitigate an ESC1 AD CS compromise:
Remove the Enrolee Supplies Subject flag. Do not allow users to provide their own SAN in the certificate signing request for templates configured for client authentication. Templates configured with the Enrolee Supplies Subject flag allow a user to provide their own SAN.
Restrict standard user object permissions on certificate templates. Standard user objects should not have write permissions on certificate templates. User objects with write permissions may be able to change enrolment permissions or configure additional settings to make the certificate template vulnerable.
Remove vulnerable AD CS CA configurations. Ensure that the CA is not configured with the EDITF_ATTRIBUTESUBJECTALTNAME2 flag. When configured, this allows a SAN to be provided on any certificate template.
Require CA Certificate Manager approval for certificate templates that allow the SAN to be supplied. This ensures certificate templates that require CA certificate manager approval are not issued automatically when requested; instead, they must be approved using certificate manager before the certificate is issued.
Remove EKUs that enable user authentication. This prevents malicious actors from exploiting the certificate to authenticate as other users.
Limit access to AD CS CA servers to only privileged users that require access. This may be a smaller subset of privileged users than the Domain Admins security group and reduces the number of opportunities for malicious actors to gain access to CA servers.
Only use AD CS CA servers for AD CS and do not install any non-security-related services or applications. This reduces the attack surface of AD CS CA servers as there are fewer services, ports and applications that may be vulnerable and used to compromise an AD CS CA server.
Encrypt and securely store backups of AD CS CA servers and limit access to only Backup Administrators. Backups of AD CS CA servers need to be afforded the same security as the actual AD CS CA servers. Malicious actors may target backup systems to gain access to critical and sensitive computer objects, such as AD CS CA servers.
Centrally log and analyse AD CS CA server logs in a timely manner to identify malicious activity. If malicious actors gain privileged access to a CA server, this activity should be identified as soon as possible to respond and limit the impact.
ADCS Honeypot
Or run PingCastle or
Source:
Credit:
Restrict privileged access pathways to AD CS CA servers to jump servers and secure admin workstations using only the ports and services that are required for administration. AD CS servers are classified as ‘Tier 0’ assets within Microsoft’s ‘’.
