If you are new to TryHackMe, I recommend checking out their Tutorial room to see how the platform works and how you can access the target machine(s). I also highly recommend using your own “attack box”, be it a Kali, Parrot, or some other pentesting oriented Linux distro (in the form of a VM), as opposed to the browser based solution TryHackMe provides. I’ve found that the browser based VM is a lot slower, though others seem to have no issues with it. The only thing using your own attack VM entails is connecting it to THM’s network through VPN, but this is incredibly easy as TryHackMe will supply you with your own OpenVPN configuration file and is outlined below.
Types of Challenges
The TryHackMe platform has multiple types of challenges, each potentially having its own requirements for accessing and completing it. You can identify the type of challenge by looking at the icon on the right-hand side of the collapsible bar for that particular challenge:
Challenges using the “server rack” icon include the use of a deployable machine, and are the most common. Pressing the “Start Machine” button will launch a virtual machine that you have two ways of accessing: using THM’s “attack box”, found at the top of your browser window:
Or, you can instead opt to use your own virtual machine connected to the THM network, which is done (on Linux) by clicking your user icon, “Access”, and then “Download My Configuration File”.
Clicking “Save File”
And by running the following command in a terminal (I might suggest you move the download to another folder, such as “Documents”):
Once you see “Initialization Sequence Completed”, you’ll know you’ve successfully connected to THM’s network. Keep this terminal window open (you can minimize it, however). Return to it and press “Ctrl” + “C” twice once you are ready to disconnect.
After you’ve chosen between THM’s attack box or your own virtual machine, you’ll need the IP address of the target machine, which is what was deployed earlier with the green “Start Machine” button. That information can be seen in a banner at the top of your browser window, or in more detail at the top of the page:
In many cases you’ll be copying that IP address into your attack box/VM’s browser’s address bar, but in other cases you might be accessing it through SSH, RDP, etc. You’ll notice that you can add time to it if needed, or terminate it if you finish early – opening up more resources for other THM users.
Challenges using the “browser” icon will require interaction with a simulated website that can be accessed by pressing the “View Site” seen after expanding the challenge. These challenges will need to be completed from within your browser, and cannot be accessed through a VPN on your own machine due to the fact that they are not true websites.
Challenges with the “download” icon include files – in many cases packet captures (pcaps) or log files to be parsed through using a specific type of software. Where you would like to do this examining is up to you, but you will not be able to use one of TryHackMe’s machines. For examining something like a .pcap file, you will want to install Wireshark on one of your own computers or VMs.
Challenges without an icon focus on either reading material and answering questions, or will include a link to a publicly accessible website that doesn’t require connection to THM’s network, and therefore can be completed from any computer you choose.
Note: Bold and underlined words/phrases pertain specifically to the challenge questions
TryHackMe; Advent of Cyber 3; Day 6 Walkthrough
Day 6 is all about LFI (local file inclusion), where it occurs, and how it can be used to gain access to files that should not be accessible through a web app or to enable RCE.
Our first task will to be visit the target machine’s IP address through our browser and search for an entry point. Immediately upon loading the home page (index.php), we see “err=error.txt” appended to the URL. It’s likely that “err” is using a PHP “include” expression, which could grant us access to other files on the web server.
Our next task is to read /etc/flag file. Assuming “err” will allow us to read files outside of our current folder, we can replace “error.txt” with a directory and file of our choosing.
The default directory for most web apps is /var/www/html, which means we will want to go “up” three directories to get to the root directory “/”, and then go “down” into /etc/. To go “up” a directory, we’ll type in “../”. Our completed string should read “../../../etc/flag”
Now that we’ve confirmed the presence of LFI, we can use the same entry point to read the source code of “index.php”, our home page. To prevent the PHP code from actually executing, we will need to filter the index.php resource by using Base64 encoding. Using “php://filter/convert.base64-encode/resource=index.php”, we can grab the source code for the page.
We’ll throw the Base64 encoded text into a decoder such as Base64decode.org. Using that, we can see the flag, as well as the PHP resource that will be of interest to us for the next question.
Using the same technique as with “index.php”, we will instead change the resource to “./includes/creds.php”
We will then run the new Base64 string through a Base64 decoder, and have the credentials returned to us.
We can use these credentials the recover the server’s password. Start by going to the login page and logging in using the “McSkidy” username and the password shown above.
Once we’re in, we’ll click the “Password Recovery” link, which will give us the password of the flag.thm.aoc server.
The next task involves making use of the LFI vulnerability in order to gain RCE on the target machine. To execute this we’ll be using the access log, which resides at “./includes/logs/app_access.log”. There are a few ways of doing this, but we’ll be using the login page in order to create an entry on the access log that includes executable PHP code. Start by logging out and revisiting the login page.
We’ll then use actual PHP code as our username, which will allow us to find the hostname of the web server. Type the following code into the username field, an arbitrary value in “password”, and click “Sign in!”. The sign-in will fail, which is okay.
<?php phpinfo();?>
Now click “Home” link to bring us back to our LFI entry point, index.php. From here we will navigate to the ./includes/logs/app_access.log file using the same method used earlier – taking advantage of the “include” expression used in “err=”.
Navigating to this page will take us to the access log, where we can see that our code successfully executed, returning all the information about the usage PHP on this web server.
We can use the “find” function (Ctrl + F) to search for “hostname” and find our flag.
(Bonus) Because we used this PHP code in our “username” field, it will also be associated with our PHP session. We can validate this by using our browser’s development tools window by pressing “F12”, navigating to “Storage” > “Cookies” and looking at the value of the PHPSESSID cookie. We will use this value at the end of another LFI query, this time navigating to “../../../tmp/sess_<your_cookie_value>”. We should see the same PHP code executed on this page as we saw in the access logs.
