top of page
  • BlueDolphin

Hack the Box - Stocker

Engagement Map


We start off with a casual NMAP scan including the flags for service scanning and version discovery. Initially the attack surface appears to be small in scope, limited to port 80.

In the scan it is revealed our hostname is stocket.hb and our server is nginx/1.18.

Web Enumeration

Viewing the website provides us with the following landing page.

Subdomain enumeration

Dirsearch turns up several directories but nothing worth mentioning.

Trying ffuf we attempt to discover hidden domains using the -u and -H flags while grepping for 302 responses only.

ffuf -w /usr/share/wfuzz/wordlist/general/common.txt -u -H "Host: FUZZ.stocker.htb" -c | grep 302

We receive the below landing page when visiting our newly discovered domain. We first of course had to add this to our /etc/hosts file.

With burpsuite, we can analyze the request by intercepting the communication on a proxied browser to better analyze the application logic.


Whatweb is a good tool for enumerating web application to discover the underlying infrastructure.

Let's parse the information to make it readable.

http://dev.stocker.htb/login [200 OK] 
HTTPServer[Ubuntu Linux][nginx/1.18.0 (Ubuntu)],
Meta-Author[Mark Otto, Jacob Thornton,and Bootstrap contributors],
MetaGenerator[Hugo 0.84.0],
Title[Stockers Sign-in],

NoSQL Injection

From here I was quite unsure of what approach to take. The Official HTB forums provided a hint about NoSQL attacks.

We prepare NoSQL injections in an attempt to bypass the login page. A handy reference for working through your OSCP is the hacktricks book in the link below.

The hacktricks book has a NoSQL Injection specific area, with a sub category for Basic authentication bypass.

I found this next part to be a bit challenging, and I found a hint on the Official HTB forum that suggested we double check the headers in our request. From here I made the following configurations:

Content-Type: application/json
Close Connection: DELETED
Upgrade insecure-Request

The payload was placed at the bottom of the request.

Upon successfully logging in, we see in big font "Buy Stock Now!" and a view cart button.

Iframe Injection

The page eventually loaded items that were available for purchase. It was very simple, with only 4 items available. Be

Clicking on our option to view our cart, provided a very simple cart with the option to submit purchase.

We notice our submitted purchase is intercepted by our BurpSuite proxy.

We are prompted with a thank you dialogue and are given a "Order ID" and an option to view the purchase order.

Following the link to view our purchase order, reveals exactly that.

From here, we can intercept the request and modify the parsed data. The Official HTB forum suggested iframes can be used for a stage of this engagement.

We can see our modified string was successfully parsed to the generated document.

After researching about iframes, I learned we can use an iframe to call a local file, and not just HTTP calls. By adding an iframe to the title, with a point to /etc/passwd/ we forward the request and see the results in the generated report.

The iframe was a success, however our file is largely cut off. We can fix this by defining height and width in the frame.

We eventually learned that the index.js file was a sensitive file where web administrators may leave residual data or notes. This was totally new and not something I would of thought about on my own.

The index.js file reveals a password, and when this is conjoined with the user found in /etc/passwd/ we are able to login.


We have a successful login as user angoose.

Reviewing the users sudo permissions, reveals special permissions to /usr/bin/node /usr/local/scripts/*,js as sudo,

From here I created a javascript reverse shell and execute is as sudo.

We then call our reverse shell on the target system with the command below. We simply take advantage of the wild card, adding a pointer to our malicious script.

26 views0 comments


bottom of page