Certified
AD box on HTB.
Enumeration:
Port Scanning:
Nmap:
As always we are going to start with nmap scanning:
We can see that the clock skew is too great, so we will sync the time with the target machine:
Lets get the FQDN, and add it with its corresponding IP address to the hosts file:
Also we were provided with credentials to reflect the real world assumed breach scenarios: judith.mader:judith09.
BloodHound:
We will start by ingesting the domain data using bloodhound-python, and rusthound-ce:
I will start BloodHoun, and upload the ingested data into it:
First, we have writeowner over the management group.
That group has genericwrite over management_svc user.
And that user has genericall over ca_operator user.
Finally this user has enrollment rights to multiple templates, and the photo blowe confirm that we have ADCS installed on our target machine:
We can also use netexec to check for ADCS:
Follow along with this path, we will start by earning the ownership of that group using impacket-owneredit:
Then I will use impacket-dacledit to give myself WriteMembers right, so I can add myself to that group:
Add myself to the group via bloodyAD:
Now since we have genericwrite over a user, we can do multiple attacks such as shadow credentials, changing its password, targeted kerberoasting, etc. I will perform the first one.
We can do it via pywhisker, and the PKINIT tools, or simply using certipy:
Again the management_svc user has genericwrite over ca_operator user, and we should always avoid changing user's password, so I will use shadow credentials again:
Nice, now we have ca_operator ntlm hash, we can use certipy to retrieve the CA information, and configurations:
Read the txt file:
We will find that certipy identified a template vulnerable to ESC9 attack.
How we can identify it ourselves or how we know that it is exploitable. We should look for multiple vectors:
Exetended Key Usage (EKU) has client authentication.
As ca_operator, we can enroll into CertifiedAuthentication template.
Enrollment Flag has NoSecurityExtension which will help us to request a certificate on behalf of any user that we choose in our own UPN.
We should first change our own UPN to administrator, so we can request a certificate as him, and since management_svc has rights as shown in the bloodhound data above we can edit the ca_operator UPN using certipy:
If it was ca_operator we can try to change it to administrator@certified.htb.
Next we will request a certificate for the ca_operator user:
We can see that it requested a certificate for the administrator, since it is the value of our UPN.
Next we will use pfx file to authenticate using certipy and dump the administrator hash:
Here we have the administrator ntlm hash, lets winrm to the machine:
And we can get the flags:
Last updated