TraceBack HackTheBox Walkthrough

Musyoka Ian
9 min readAug 15, 2020

Hello guys back again with another walkthrough this time I’ll be showing how i solved traceback from HackTheBox. The box according to my opinion was a really great box for beginners and i loved the little OSINT that you must carry out to get the initial foothold on the box. What i also loved about the box was that to get a user shell on the box it required one to have some lua scripting knowledge and be able to understand how to use lua to execute system commands on a target. To get root on the box was a little bit tricky but we’ll create a bash script to automate the process am sure you’ll love the walkthrogh since the box was so nice. Without much say let’s jump in

As always we’ll start off with a nmap scan of the box. This will give us a good idea of services running on the box and also their version numbers. Sometimes the running services are outdated have vulnerable version which is good for us and bad for the server and if we are lucky enough we can get an exploit already build and use it to get a shell on the server or we can build our own exploit script

Looking at the result of the nmap scan we see that SSH and HTTP is running

Since HTTP has a bigger attack surface compared to SSH that’s where we’ll begin enumerating. Opening HTTP we get a standard webpage but we also get some really useful information like There’s a backdoor on the webserver and if we hit it we might use it to get a shell on the web server

I decided to see if robots.txt existed on the web server but i did not get lucky

Next i decided to run gobuster which is a Directory/file & DNS busting tool written in Go. Gobuster is a tool used to brute-force URIs including directories and files as well as DNS subdomains.

Looking at the output of gobuster we see a SSH Pubic Key (id_rsa.pub)

I decided to download it to my box using wget

Looking at the contents of the private file and in particular the username we see that it has nothing useful just someone public key

Since gobuster didn’t reveal much i decided to see the source code of the web application. It wouldn’t be the first time seeing a developer leave comments behind that has led to a server being compromised.

Looking at the source code we see one comment

I decided to search for that specific comment on the internet and as you see below few interesting results came back

The second webpage link sounded more interesting since the author of that specific GitHub page is the same author of found on the HTTP webpage

On clicking the link it directs us to a GitHub page which seemed to have a couple of web shells

Since there were a lot of web shells i decided to git clone the entire repository so that i can do analysis on the files on my local box

Next i navigated to the directory and decided to list the entire contents of the repository

Looking at the result we see that there were a lot of git config files which i knew that i probably wouldn’t need it again and because if this i decided to delete them

Doing a directory listing again we see a couple of web shells which i saved to a file called wordlist.txt

Doing a search and replace i was only left with names of potential web shells that the server might have

Now let’s do a directory bruteforcing again using gobuster and this time we get a hit on one of the web shells

Looking at the results of the gobuster we see one filename cam back with a status code of 200 meaning something good must have happened

I tried to navigate to the URL using Mozilla and see if it existed

And voila we get a PHP web shell

But we don’t know the username or password and because of this i decide to go back to the GitHub repository and analyze the PHP file

Looking at the PHP source code we get credentials both username and a password

admin:admin 

Of course we could bruteforce the credentials but first i decided to check the PHP source code since most of the times

I decided to login in to the web shell and voila looking below i got in

Looking at the web shell we see that we are able to execute system commands

I decided to execute a simple system command “ifconfig” and voila looking below we get the output back

Next best thing we can do is get a shell on the box. The reverse shell payload cheat sheet that i normally use is the Pentest monkeys reverse shell cheat sheet

The i did set up a netcat listener on my local box on port 9001

The executed the reverse shell. Going back to my netcat listener we got a shell on the box sweet

Sweet!!!! Now it’s lateral movement and privilege escalation. Next i decided to run lipeas which automatically checks for privilege escalation vectors. So i downloaded linpeas to the box

Then executed the script. Looking at the linpeas output i saw one odd thing. I could execute a binary called luvit as the user sysadmin without providing a password

So decided to go online and see if it’s a production binary or a custom application that someone build

Looking at the online result we see that it is a binary probably used to run lua scripts

So i decided to execute the binary and see what happens

Looking at the output below it dropped me in to a lua shell

If you’ve come across lua before you know that you can execute a system using the syntax below

os.execute("system command you want to run")

Let execute a simple Linux command whoami

Looking at the output above you see we can execute commands the sysadmin user. Now that we know we can execute commands as the sysadmin user lets drop into a shell as the sysadmin using the command

os.execute("bash")

And voila looking at the output below we have a shell as the sysadmin user

Looking at the sysadmin home’s directory we have the user flag and we have read access to it you can now submit it

Next we have to escalate our privileges to root. I again decided to run linpeas.sh

Again looking at the linpeas output we see that we can write files in /etc/update-motd.d/

But how would it get executed

So i decided to load pspy (which is just a process monitor from linux systems) to the box and see the processes that gets executed in the box

First we see some file being copied from /var/backups

I waited for other interesting processes to pop up but got nothing so i decided to leave pspy for a while and decided to just inspect the writable files in /etc/update-motd.d

Looking at 00-header we see something really interesting

Also this exact message pops up when we try to login via ssh

How do i know this ?

motd just means message of the day and they are messages that get shown when someone logs in to a box using CLI

I decided to generate SSH Key Pairs that would allow me to log into the box by using SSH

Let’s generate our own SSH Keys and try to log in via SSH

I uploaded the public key to my user .ssh directory

After copying the SSH Public keys i decided opened pspy and tried to log in via SSH and see what i see

Also looking at the pspy output we get the the folder gets executed

And knowing we could edit the 00-header i tried to see if i could use it to our advantage and add a SSH Public Key to the root’s .ssh directory if the process run-parts was running as root we could get root that way

i created a simple bash script below

mkdir /root/.ssh/
touch /root/.ssh/authorized_keys
echo "ssh-rsa <my-ssh-public-keys>" >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

Next i uploaded the script to traceback

Next i edited 00-header and added a bash command that would execute my script once i login to the box via SSH

Next i logged in again via SSH and hoped for the best

If my reasoning was right probably the SSH Public key had been added to the root’s .ssh directory and all we had to do was use the SSH Private key pair to login to the box as the root user

So i tried to login to the box as the root user

And voila as you see we are root on the box sweet now we can submit the root flag and get the points

That’s it for now guys till next time Take care. If you liked the walkthrough you can clap for me down below and folow me so that you dont’t miss any upcoming articles

--

--