Multimaster
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.95.200
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-25 22:20 +08
Nmap scan report for 10.129.95.200
Host is up (0.011s latency).
Not shown: 65513 filtered tcp ports (no-response)
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3389/tcp open ms-wbt-server
5985/tcp open wsman
9389/tcp open adws
49666/tcp open unknown
49667/tcp open unknown
49674/tcp open unknown
49675/tcp open unknown
49678/tcp open unknown
49687/tcp open unknown
49694/tcp open unknownRDP is available for this machine, which is not the usual for HackTheBox machines. I did a detailed nmap scan just in case:
We can add megacorp.local and the multimaster.megacorp.local domains to our /etc/hosts file for this machine.
SMB Enumeration
SMB does not allow us to access anything without credentials for this machine.
Employee Hub -> SQL Injection
Port 80 shows us a dashboard of some sorts:
There were some functions, and the one that stood out was the 'Colleague Finder', which took one name parameter.
If nothing is entered, then all the employees are returned.
We can take note of these usernames for later. More importantly, we should see how this thing processes queries. When viewed in Burpsuite, the request simply sent a POST request to /api/getColleagues and it returns a response.
This looks vulnerable to SQL Injection somehow. Every form of injection I tried resulted in a 403 being returned. I noticed one thing however, the Content-Type header said that this app accepts UTF-8 characters.
UTF-8 characters are a bit special as they are denoted like \u12 or something. If I try to use \u12 as the input, I get an error instead of being blocked.
This likely indicates that our query has caused a backend error. Using this, we can try some of the sqlmap tampers that are available:
Tampers are basically scripts that change the characters being sent in to the website. There's a charunicodeescape option that we can try. The final command looks something like this:
The initial attempt tells me there's nothing, and that all requests ended in 403. I tried again with a --delay 3 flag in case there was a WAF blocking my access, and it works. The final command I used was:
The guess of the DBMS being MS-SQL was purely a guess based on usual HTB machine patterns, but obviously this is not always the case! Windows AD can use SQLite3 or MySQL for their backends, especially for web servers!
Great! Now that we have this, we can attempt to enumerate the database. Here are the results from repeated use of sqlmap:
Loads of hashes. Only 3 of them were crackable using hashcat -m 17900.
The rest of them weren't crackable. We can gather the rest of the users:
Then, we can attempt to use password spraying to find a valid user.
Spray Fail -> SID Brute -> Shell
For some reason, none of these users were valid.
I found this rather odd. I did a kerbrute to find more users, and found that there were different users found by kerbrute relative to those in the database.
None of the users that I found via kerbrute worked with any of the passwords as well. So we were just left with an SQL Injection on an MSSQL database. Googling for AD enumeration via MSSQL injection led me to this page:
Basically, it is possible for us to find valid usernames using the MSSQL Injection that we have found. Earlier, sqlmap indicated that there were 5 columns present, and that it used UNION injection. Following the above PoC, we can use this payload:
I used this site to encode it into a suitable UTF-8 format:
Testing it worked!
We can then try to enumerate the Administrator user using this payload:
This would result in some hex being returned:
We can use this to send another query that would return usernames and convert the SID for us.
Now, we just need a way to automate this method. I took the two functions used to convert the hex to a valid SID from the user earlier.
Then, we can fit this SID into a payload with a test number of 1000.
This is the final script I used to automate this method:
This would slowly brute force all the users out. I included the 'nope!' part to let me know that the script was still running fine. This script takes quite long...but eventually we would get some valid users. Here's what the output of my script looks like:
There are a lot of groups starting at 500, so I changed it up and started at 1000 instead, which is where user IDs should start. Because this was taking so long, everytime I found a valid user I would test the credentials immediately. Eventually, it found these users:
The tushikikatomo user had valid credentials!
I was then able to evil-winrm in as this user:
Privilege Escalation
Basic Enumeration + Bloodhound
The current user had no privileges or anything of interest. Since we had a shell, we can do some basic enumeration like finding the other users present:
In the C:\ directory, there were some interesting folders:
The DFSRoots gives me a weird error regarding network location:
We probably don't have the permissions for this yet. We also cannot access the inetpub directory:
Within the C:\Program Files directory, we can see that Microsoft Visual Studio is installed.
The Windows SQL Server is also not default. Before we delve further into a specific software, I wanted to run bloodhound-python to get more information about the domain.
Start Bloodhound and upload the information as usual. Then, we can check each user from the C:\Users directory to identify if there are ACLs to abuse.
First, we find that cyork is part of the Developers group:
There are no outbound object controls for this, indicating that this group might have access to somestuff on the machine.
We can also find that the sbauer user has some privileges over jorden.
The rest of the users don't have anything interesting about them. I also used PrivescCheck.ps1 to enumerate for me since WinPEAS was not working for some reason. Here was the interesting output:
For some reason, Visual Studio was running a lot of processes and even had some ports open for it.
VS Code -> Cyork Shell
There were loads of processes run as Code, so let's take a look at that. The VS Code directory had some files within it.
Within the Microsoft VS Code file, there was a Code.exe binary present, and I found this StackOverflow post that gave me the command to find its version (I was struggling to run .\Code.exe --version previously).
Then, we can enumerate the possible exploits.
This machine was released in 2020, so we can ignore the 2023 exploits. There was only one Privilege Escalation one which looked promising as it involved injecting code into existing processes.
The exploit involves exploiting the debug ports that are left open by the process, and we should be able to get RCE for the user context that Code.exe runs in.
VS Code is built on Electron, so we should be looking for exploits that are able to communicate with the port that is open. On Hacktricks, there's a page detailing CEF Deug abuse using cefdebug.exe.
We can grab a copy of the compiled binary and transfer it to the machine. We can first run it to find the target port we want.
This exploit was weird, as it took me ages to get a shell, but I eventually did.
Inetpub DLL -> Credentials
This user has access to the inetpub directory:
Within the bin file, there were some DLLs:
The application also seems to be using this DLL for something:
The Web.Config file doesn't seem to use it, making it weirder. I downloaded this file back to my machien for some reverse engineering. Since it was a DLL file, we can open it up in DnSpy.exe.
Within it, we can find some hardcoded credentials:
Since we have access to the C:\Users directory, we can check which user is this password valid with, and sbauer is the one!
We can then evil-winrm in as this user:
GenericWrite -> Jorden Shell
From the Bloodhond we did earlier, we can see that this user has GenericWrite privileges over jorden:
To exploit this, we can use PowerView.ps1. However, it seems AMSI is blocking us:
This is pretty easy to bypass since we have an evil-winrm shell. We can just use Bypass-4MSI to do so:
To abuse this, I learned from PayloadAllTheThings that we can basically set the attribute required for AS-REP Roasting to work:
Then, we can use impacket-GetNPUsers to get the hash required.
This hash can be easily cracked by john.
Server Operators -> Root
jorden has loads of privileges available and is part of a lot of groups:
Technically, SeBackupPrivilege allows us to read the root.txt directly, but getting an admin shell is of course better. So since we are part of the Server Operators group, we can start our enumeration from there.
From Hacktricks, I gathered that the Server Operators group was able to do these:
Allow log on locally
Back up files and directories
Change the system time
Change the time zone
Force shutdown from a remote system
Restore files and directories
Shut down the system
control local services
All of these are not super interesting, except for the last one. We can control local services, meaning that we can do stuff like change service paths to run payloads as the SYSTEM user. As such, I used PowerUp.ps1 to do my checks on what services I could manipulate.
This didn't work because it seems that we cannot access the Service Manager:
I couldn't run WinPEAS on the machine, so I used my own Windows host to find a service that we could edit, and this took a while.
We can find all the services using reg query:
Within this huge list, there were loads of services that weren't valid to use because they were already running or I could not edit the binPath variable.
Used 0xdf's writeup because I got lazy finding the service lol.
The first service I noticed were browser and bowser. I just thought the latter was funny, but the former was one that we could abuse. First, we just need to change the binpath and then run start to start it again. This gives us a root shell.
Rooted!
Last updated