Write-up: InfinityShell

Cipher’s legion of bots has exploited a known vulnerability in our web application, leaving behind a dangerous web shell implant. Investigate the breach and trace the attacker’s footsteps!

The objective is to investigate and analyze traces of an attack caused by an implanted webshell.

THM Room: https://tryhackme.com/room/hfb1infinityshell

Reconnaissance

When attackers successfully penetrate the system, they try to persist and escalate their privileges. If they succeed at privilege escalation, the best option is to reinstall the system from scratch. Let us check if we can spot something suspicious immediately. We can use ps faux to list the process tree and ss -plnt to see listening TCP sockets.

There is nothing suspicious in the process tree, and the list of active servers shows that we have mariadbd, sshd, cupsd, systemd-resolve, Xtigervnc, and python3. While Python may look suspicious, it is benign:

python3 -m websockify 80 localhost:5901 -D

It provides a bridge between the web browser and the VNC server, allowing us to access the box from the browser.

The web server is not running, which is good: the attacker will be unable to upload new shells while we clean the system.

Let us see what we have to work with. We expect the files to live in /var/www/html:

The index.html file is the default Ubuntu’s stub, and CMSsite-master is apparently what we will have to work with.

The first red flag is the database dump: php_cms.sql. Never store backups or database dumps under the web root: attackers will use tools like gobuster or dirb to find them.

users table” class=”wp-image-825″/>

Although this is not related to this investigation, Henry and Victor have very weak passwords: henry and victor respectively (these passwords are not helpful to capture the flag). Password hygiene is a must.

Finding the Web Shell

Now we need to locate and eradicate the web shell.

Let us see what we have:

img/images.php looks suspicious, but it may not be the only file. Let us check these files for suspicious strings. In Kali Linux, there is a file, /usr/share/wordlists/seclists/Pattern-Matching/Source-Code-(PHP)/php-auditing.txt. It lists functions used to execute commands:

exec
passthru
system
shell_exec
popen
proc_open
pcntl_exec

I would also add base64, rot13, gzinflate, and eval as they are often used with obfuscated payloads.

Because this system does not have that file, I used a simpler approach:

find . -type f -name \*.php\* | xargs grep -E 'base64|exec|system|shell|pcntl|passthru'

We have found the web shell; it was img/images.php, as expected.

Logs Analysis

Now we need to find out how the attacker penetrated the system and maybe find other dropped or modified files.

To do this, we need to analyze Apache access and error logs. We will find references to img/images.php in /var/log/apache2/error.log.1 and /var/log/apache2/other_vhosts_access.log.1.

We see the attacker’s IP; we will use it to investigate what else they modified, and how they intruded into the system:

for i in $(grep -F img/images /var/log/apache2/other_vhosts_access.log.1 | grep -Eo '\?query=[^ ]+' | awk -F= '{print $2}'); do echo $i | base64 -d; done

Let us decode the commands the intruder used:

And we have the flag!

Finding and Analyzing Vulnerabilities

This section is not required to complete the box; however, it is always interesting to find out how the intruder penetrated the system. After all, if the vulnerability remains undetected and not fixed, they can hack into the system again.

We have the attacker’s IP address; let us look through the logs to see what they did.

The attacker registered, logged in, and then probably uploaded something from the administrative panel (user avatar?). They uploaded the img/images.php web shell, ran several commands, and read a post.

Let us look at admin/profile.php:

admin/profile.php” class=”wp-image-837″/>

As a software engineer, I can say that the code is horrible. You can find SQL injections, unfiltered user input, and arbitraty file uploads. This code will generate a lot of warnings with E_ALL.

If we scroll down, we can see stored XSS vulnerabilities. The verdict is: kill it with fire. Some things are easier to rewrite correctly than to fix. I would not recommend bringing this site back online.