Roten [Cyber Apocalypse 2023]

Oct. 7, 2023

Before attempting to do anything, let’s read the description of the challenge first.

The description describes a scenario where a threat actor has uploaded a shell to the webserver. Using those clues, we can then attempt to try and solve the challenge.

The file given for the challenge is a singular .pcap file, which we can open in WireShark to inspect and do our investigations there.

After opening the file in WireShark, we can see that there are many different packets captured. However, we can use the clues that the description gave to give us a starting point in terms of searching for the right file. Remember that a threat actor has uploaded a shell to their web server. Working off this knowledge, we can then filter any activity involving uploads; namely POST and PUT HTTP requests.

After filtering for POST and PUT HTTP requests, we can see that there were only a couple of POST requests made to the web server. Upon inspecting these requests further, however, one requests stands out in particular. Recall that file uploads to the server are usually distinguished by their nature (in this example, x-www-form-urlencoded means that form data was uploaded). There is an outlier among the upload types here:

This indicates that a .php file was uploaded to the web server. Upon inspecting the packet, we can see that the file uploaded was a .php file called galacticmap.php.

We can follow this upload and try to see whether there will be any suspicious activities coming from the said IP.

The said upload was packet#1929. Checking any subsequent requests after the said packet, we can see that there are multiple GET requests for the file galacticmap.php file in different directories.

Notably, these requests also had a user agent of Wfuzz, which is an old school fuzzer for web directories.

Further inspection of subsequent requests show more attempts of accessing the file galacticmap.php.

Our theory is that the threat actor did indeed upload galacticmap.php, and that it was indeed a shell, but they do not necessarily know which directory the .php file was uploaded to. Which is why they are desperately trying to find where their uploaded file is hosted.

That being said, we can see that they eventually did find where their shell was located (in the /uploads/ directory). We know this because, right after accessing their shell, they have begun inserting commands into their requests immediately after.

So now that we have practically confirmed the existence of the shell, and we know which packet the upload was done, we can then try to rebuild the .php file the threat actor uploaded and try to see if we can get any hints there.

As mentioned before, the upload of the shell was in packet#1929. We can extract the file upload using WireShark by using its export function

When we open the .php file, we can see the following lines of code:

Looking at the code, all of the variables and values are obfuscated. However, upon looking closely at the code, we can see that at the end of the code, an eval() function is being used to evaluate a variable.

We can try to see what this variable is by printing the variable itself

We can see that one of the strings being printed is actually the flag!

Alternatively, you can use the results of the php execution and pipe it onto a grep command to easily search for the flag (if there is a flag):

💡 HTB{W0w_ROt_A_DaY}