Just to make life easier I usually add an entry in my hosts file for easier access of the target machine.
Okay now onto the hacking!
As always, I started off with an NMAP scan against the machine.
nmap -Pn -sC -sV -A -p- -oN initial academy.htb
┌──(root💀kali)-[/home/…/boxes/htb/machines/academy] └─# nmap -Pn -sC -sV -A -p- -oN initial academy.htb Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower. Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-10 16:54 EST Nmap scan report for academy.htb (10.10.10.215) Host is up (0.0037s latency). Not shown: 65532 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 c0:90:a3:d8:35:25:6f:fa:33:06:cf:80:13:a0:a5:53 (RSA) | 256 2a:d5:4b:d0:46:f0:ed:c9:3c:8d:f6:5d:ab:ae:77:96 (ECDSA) |_ 256 e1:64:14:c3:cc:51:b2:3b:a6:28:a7:b1:ae:5f:45:35 (ED25519) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) |_http-server-header: Apache/2.4.41 (Ubuntu) |_http-title: Hack The Box Academy 33060/tcp open mysqlx? | fingerprint-strings: | DNSStatusRequestTCP, LDAPSearchReq, NotesRPC, SSLSessionReq, TLSSessionReq, X11Probe, afp: | Invalid message" |_ HY000
Scanning & Enumeration
Based on the scan that was run, I realized that port 80 was running a web server. This was the web app that was being served!
When registering, I realized that I was given a
roleid which was set to
0 by default.
Initial enumeration also revealed that there was an
admin.php page available. Accessing the
admin.php page just threw me another login page.
I wasn't able to login to the page with the account which I created using the register page.
The first step I took was to intercept my account registration request and change my
roleid to 1. This enabled me to login to the admin page.
From this I was able to gather a bunch of information
- Possible user accounts =
- Possible staging server =
The next thing I did was to add an entry in the hosts file to the newly found domain as I didn't not have a domain name server that pointed that name to the target IP
Heading to the newly found staging domain reveals the app that's driving the solution. I was able to find a POC exploit for this particular app with couple google searches.
┌──(root💀kali)-[/home/…/htb/machines/academy/exploit_laravel_cve-2018-15133] └─# python3 pwn_laravel.py http://dev-staging-01.academy.htb dBLUaMuZz7Iq06XtL/Xnz/90Ejq+DEEynggqubHWFj0= --interactive
That got me a reverse shell into the target machine :)
I knew that the target was running Laravel. Therefore, I tried looking for crucial config files that a default Laravel install might have.
All the environment variables are declared in the .env file which includes the parameters required for initializing the configuration.
I went ahead and used the
find command to help locate these config files.
find / -name "*.env"
Looking into the contents of the file revealed a set of credentials. I poked around and used these credentials on the possible user account I found earlier.
I was able to successfully gain access to one of the two accounts and grab the user flag.
However, I needed to move into the other possible user that I uncovered earlier as this account didn't have any
At this point I had exhausted all my manual enumeration techniques and I turned to
Linpeas for assistance.
I quickly spun up a python http server, transferred
Linpeas over to the target machine and ran it.
Linpeas was able to dig through the logs for me and point out that the potential user I found earlier was actually valid. It also returned the password for that user~
The privilege escalation on this last user was pretty straight forward. The user was allowed to run composer with root privileges.
Thankfully, there was an existing GTFObin for it!