HTB - Haze

Recon - CVE-2024-36991

Scanning the target ip address 10.10.11.61 with nmap , gives us the following results

1. our target host is a windows domain controller dc01.haze.htb
2. LDAP over SSL is enabled (ADCS may be in use)
3. unusual services running on ports 8000, 8088, 8089 the service running on port 8000 displays the Splunk login page. as this is not a custom software, we can start by looking online for default credentials and cves with proof of concept available. searching in the nuclei-templates github repo, there is a cve that we can check for here is the proof of concept let’s verify if this splunk instance is vulnerable, yes it is.

   Paul.Taylor - password decryption

   the splunk instance running on the domain controller has an lFI vulnerability, now its time to think of what files we can read from the host. why not starting with splunk’s log and configuration files. looking online, this gist contains several splunk configuration filenames. one interesing config file is authentication.conf, its purpose is to configure authentication settings for users. let’s grab this file and see what is in there, it is located at the following path /Program Files/Splunk/etc/system/local/ there is an ldap authentication configured using paul taylor user and the password looks like it is hashed or encrypted. splunksecrets from HurricaneLabs can be used to decrypt paul’s password the only requirement is the splunk secret key that we can retrieve from splunk.secret file decrypting paul’s password let’s verify this password and see if it is valid, yes it is

   Paul.Taylor - restricted user

   with valid domain user credentials in our hands, we can perfrom an authenticated domain enumeration. i will use the tool godap. checking all the computers in the domain, there are two computers, DC01$ and Haze-It-Backup$. it seems like the user paul is the only user in the domain, and it is inside an OU called restricted users. interesting. checking the members of the remote management users group, we can see that there two users, edward and mark,however we were not able to retrieve them when we tried to get all users in the domain. from the above data, it looks like the user paul does not have much to do as it is hinted in the OU name restricted users. it’s time to think of something else.

   Mark.Adams - password spraying

   because of the restrictions applied to the user paul, we don’t have read permissions over other users and groups. however, we discovered two users, mark and edward by looking directly at the members of the remote management users group. sparying paul’s password for this two users resulted in mark using the same password as paul.

   Haze-it-backup$ - read gMSA password.

   the user mark uses the same password as paul, if we try to enumerate the domain as mark we can see a lot more data then we did when using paul. the Haze-it-backup$ is a gMSA account, and only domain admins can read its password as we can see below. checking Haze-it-backup$’s DACL, we can see that members of the gMSA_Managers group have write permission over the attribute msDS-GroupMSAMembership, and this attribute specifies who can read gMSA’s password and mark is a member of gMSA_Managers group. also, mark is a member of the remote management users group as we can see above. now, with the information we collected above, we will access the domain controller using winrm to update the msDS-GroupMSAMembership attribute of haze-it-backup$ account to allow mark to read its password. now let’s read haze-it-backup$’s ntlm hash. haze-it-backup$ account is now compromised, let’s see where this account can led us to ?

   Edward.Martin - shadow credentials

   previously, when we were enumerating the domain using paul account, we saw that there is a user called edward who is a member of the remote management users group, however he still did not show up even when we switched to mark to do the domain enumeration. as we can see below there is no user edward when we query for all domain users. interesting, let’s try switching again from mark to haze-it-backup$ account for domain enumeration. and here it is, we can see now the user edward after switching to haze-it-backup$ checking edward’s DACL, we can see that members of support_services group can read and write to the msDS-KeyCredentialLink attribute. this attribute allows an account to have an alternative authentication method like using public-private key for authentication instead of a password. looking at the support_services group’s DACL, the haze-it-backup$ account can change support_services group owner. that’s good. so far, this is what we know:

   • the account haze-it-backup$ is able to change the owner of the support_services group.
   • members of the support_services group are able to write to the msDS-KeyCredentialLink attribute for the user edward from the collected information above, here are the steps we will take to compromise edward.
4. change the owner of the support_services group to haze-it-backup$ account.
5. give mark the necessary rights to add members in the support_services group.
6. switching to mark account, add haze-it-backup$ to the members of the support_services group.
7. switching back to haze-it-backup$, we will set up shadow credentials by writing a public key to the msDS-KeyCredentialLink attribute for the user edward we successfully obtained a valid certificate that we can use to authenticate as edward. to retrieve edward’s hash, i will login to the domain controller using mark account and then upload rubeus and the certificate we have generated above, and finally execute rubeus on the domain controller to get the hash. the user edward has been compromised successfully.

   Alexander.Green - splunk backup

   from previous enumeration results, we know that edward is a member of the backup_reviewers and remote management users groups, so let’s login to the domain controller using winrm as edward and see what we can find there. the user flag is found there is an interesting compressed splunk backup file, let’s download this backup file and analyze it locally on our machine. the credentials for alexander are found inside this splunk backup we will decrypt the password using the splunk secret found in the backup just like we did with paul. and the user alexander is compromised successfully.

   System - SeImpersonatePrivilege

   the user alexander is a member of the splunk_admins group, this means we can login to splunk as admin, the username to sign in as is admin by following the instructions on this github repo. we will install an application that will give us a reverse shell checking alexander’s privileges, there is an SeImpersonatePrivilege privilege. this means we can impersonate any user’s token. i will execute printspoofer tool to give me a reverse shell as the dc01$ user and finally here is the root flag