top of page
  • BlueDolphin

Hack the Box - Soccer

Engagement Flow


This is my writeup for the Hack the Box Machine "Soccer".

Tools Used



Web enumeration

Directory busting

Web stack enumeration


We start off with a basic nmap scan that reveals an attack surface consisting of port 80 and port 9091.

A more in-depth scan reveals our webserver has a redirect to a FQDN soccer.htb. We then see that port 9091 is a mail server.

Web Enumeration

Using the whatweb tool we are able to determine the software stack that is supporting the web service.

  1. HTTPServer Nginx 1.18

  2. Framework - Bootstrap 4.1.1 with HTML5

  3. Library JQuery 3.2.1,3.6.0

Visiting our webpage on port 80

Running our directory buster we locate several directories.

Browsing to /tiny/ presents us with the servers web application which appears to be a file manager. A link below exists and provides us with the github repository.

From here we looked around for default login credentials which actually worked.

We receive the following landing page upon logging in. From here we play around with the upload function to the upper right. From here we pivoted and started to research our application "Tiny File Manager"

Researching public exploits led us to this fantastic CVE. The way to exploit this application according to the below CVE is the following steps.

  1. Login with a valid user account

  2. Upload a malicious PHP webshell (WOLF) to the /tiny/uploads directory

  3. Upload a malicious reverse shell PHP file to the /tiny/uploads directory.

  4. From the Wolf webshell, change the permissions on the payload PHP file.

  5. Execute the payload PHP file.

We can see in the below folders that we have uploaded our payload and webshell.

In the bellow photo we have accessed our PHP webshell.

Executing our reverse shell PHP provides us with a connection as user www-data.

Horizontal movement

Basic shell upgrading

python3 -c 'import pty; pty.spawn("/bin/bash")'


Daily CronJobs

Nothing here that was helpful.

MySQL files

There was nothing much here.

Sites Enabled

Looking in here showed me a whole new hostname and webpage.

Looking in the /etc/nginx/sites-enabled folder we can see soc-player.htb.

We receive the following landing page upon browsing. We can see it is similar to our other page, but with more options.

From here we view the match link on the webpage.

From here we attempt to login but it does not work. So we instead register for an account.

Upon logging in we receive the following landing page.

Burpsuite enumeration

We pass some user input and intercept the request to learn how the application is parsing our data.

While attempting SSTI payloads and techniques, I realized we have a WebSockets message in burbsuite seen below. I initially was confused about this and learned through the HTB community that this suggests that our connection is not over an HTTP connection but a WebSocket connection where data is sent A synchronously. Therefore we have to leverage middleware to receive and structure the data for the endpoint.

The forums pointed me to this website here as a reference.

In this article I learned that our attempts to communicate over an HTTP protocol directly to a WebSocket protocol could work with some converting and formatting. In this instance, our middleware was too act as a proxy, catching our HTTP requests and formatting them in JSON for the WebSocket.

User - MYSQL & Middleware

From here we start our middleware which will format our data into appropriate JSON format for the websocket. From here we call sqlmap and specify the listening URL displayed on the right under "Send payloads". In the following image we can see that our query was received from the middleware.

We first need to make a modification in the middleware script.

We need to change the data from EmployeeID to id.

Now we run sqlmap and specify our pointer in the middleware server.

sqlmap -u "http://localhost:8081/?id=" --current-db

sqlmap -u “http://localhost:8081/?id=" -D soccer_db --tables

sqlmap -u "http://localhost:8081/?id=" -D soccer_db -T accounts --dump  



Reviewing the manual page for doas reveals that they are several directory that may contain plugins related to our binary. We also learn about a doas.conf file which we find as well.

I found doas.conf in the /usr/local/etc location. It reveals we can run plugins as root!

We see that there are many plugins associate with the dstat application.

We browse to /usr/bin/dstat and find many plugins available.

Here, we are able to add a malicious python payload and call it from the dstat binary as root.

We have write permissions to /usr/local/share/dstat

We place a reverse shell into the plugin directory and execute

doas -u root /usr/bin/dstat --plugin name.

18 views0 comments

Recent Posts

See All


bottom of page