Academy ~ Hack The Box

Boxes Feb 11, 2021


Just to make life easier I usually add an entry in my hosts file for easier access of the target machine.

echo "	academy.htb" >> /etc/hosts
hosts file entry

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
└─# 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 ( ) at 2021-02-10 16:54 EST
Nmap scan report for academy.htb (
Host is up (0.0037s latency).
Not shown: 65532 closed ports
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 = cry0l1t3 & mrb3n
  • 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

echo "" >> /etc/hosts
hosts file entry

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.

└─# python3 dBLUaMuZz7Iq06XtL/Xnz/90Ejq+DEEynggqubHWFj0= --interactive

That got me a reverse shell into the target machine :)

Lateral Movement

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.

Successful Lateral Movement

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 sudo privileges.

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.

Thankfully, 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~

mrb3n:[email protected]!

Privilege Escalation

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!