HTB Writeup - Eighteen

Intro Eighteen is an easy rated windows machine. The only provided information is the following credentials: kevin / iNa2we6haRj2gaw! Recon As always, I start with with an aggressive nmap scan (using rustscan to speed it up a little).

I also ran a UDP scan, which found a filtered port 53.

This DNS server provided some info for the domain eighteen.htb

SRV records show that the following services are associated with dc01:

• Kerberos (TCP/UDP 88)
• LDAP (TCP 389)
• Global Catalog (TCP 3268)
• kpasswd (TCP 464)

The web server was running a financial planning website. I quickly found that the website returns an SQL error when you try to register with an existing username or password, which I used to discover that there is an existing account named admin. Accessing MSSQL After indentifying all the services I could find, I used the impacket script mssqliclient.py to connect to the SQL service with the provided login. This script provides some useful enumeration commands after connecting,

enum_impersonate revealed that I had the permission to impersonate the user appdev, which I assumed would relate back to the financial planning website hosted on the server. appdev could access the database financial_planner, which contained a users table with the following credentials: admin / admin@eighteen.htb / pbkdf2:sha256:600000$AMtzteQIG7yAbZIa$0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133 This application makes the mistake of using salt, but storing it within the hash in the DB.

I first tried to crack the hash as is with hashcat, but realized that while it was a PBKDF2-HMAC-SHA256 hash, supported by hashcat, it was not in the same format hashcat or john expected.. This hash was in the format pbkdf2:sha256:{iterations}${salt}${hash in hex} and hashcat expected pbkdf2:sha256:{iterations}:{base64 salt}:{base64 hash}. After using Cyberchef to correct it, I was able to run hashcat with rockyou.txt and get the password. User enumeration and password spraying After finding this password, I logged into the site, but didn't see any exploitation paths. I decided to try a password spraying attack with the cracked password, in case it was being reused.

I used the following command to get a list of users netexec mssql 10.10.11.95 -u kevin -p iNa2we6haRj2gaw! --local-auth --rid-brute. Then I performed a password spraying attack on the winrm service:

After finding this login, getting a user shell is as simple as running: evil-winrm -i eighteen.htb -u adam.scott -p iloveyou1. The user flag was in adam.scott's desktop folder. Priviledge Escalation with BadSuccessor As always, I started by uploading and running Winpeas to look for anything that could be a could priviledge escalation path. Unfortunately, I didn't find much. One thing I took note of is that it failed to get the windows version information to search for known vulnerabilities. This was due to the user being unable to run Get-CimInstance or systeminfo. Instead, I got the version info myself with [Environment]::OSVersion

With this info, I manually researched vulnerabilities, eventually finding BadSuccessor. Unfortunately for me, I am not very experienced with Windows pentests (I find Linux much more interesting) and exploiting this looked a bit complex.

The first thing I did was run Akamai's BadSuccessor recon script, which should tell me what identities have permissions to create dMSAs in their domain, the requirement for performing the exploit. This gave me the following output:

This shows me that as part of the IT group, I could create a dMSA as a child unit of Staff. I then used the this BadSuccessor.ps1 script to exploit it.

This seemed good. Next, I needed to use Rubeus.exe to get the hashes that would allow me to perform a pass-the-hash attack on Administrator. Rubeus doesn't provide binaries, and building a Capp using an EOL sdk on NixOS looked like hell, but Kali ships a binary, so I spun up a container to grab the exe. Unfortunately, Rubeus was giving me an error:

From what I found, you aren't able to do this from a WinRM session, as they're more restricted. I wasn't sure how to resolve this, so I decided to try instead using impacket's getST.py. Since the Kerberos authentication port was closed, I first needed to create a tunnel with ligolo-ng.

We're getting close, but first another error to deal with. Kerberos will deny requests if the timestamp is out of sync by more than 5 minutes. To fix this, I wrote a nice little oneliner to get the date and time from an http header and set it as my current system time sudo timedatectl set-time (curl -sI http://eighteen.htb | rg Date | choose 1.. | format date "%Y-%m-%d %H:%M:%S"). Then I got the same error again and realized I forgot about timezones, so I changed it to also convert the timezone: sudo timedatectl set-time (curl -sI http://eighteen.htb | rg Date | choose 1.. | date to-timezone EST | format date "%Y-%m-%d %H:%M:%S"). After this, I tried getST.py again:

I was able to use the last hash output along with evil-winrm -H to log in as Administrator and get the root flag. Conclusion It's probably just due to my lack of experience with windows systems, but this machine was more difficult than I expected from one rated easy. Getting the user flag was simple, but the priviledge escalation process took me a pretty long time to figure out. Although, if you already had some familiarity with the exploit, I imagine it'd be a lot simpler.