June 22, 2026
Anatomy of a Full Compromise: From Information Disclosure to Remote Code Execution (RCE)
Story of how I managed to hack into a private institution’s website gaining complete access to everything! in just 3 hours
Viky
4 min read
Story of how I managed to hack into a private institution's website gaining complete access to everything! in just 3 hours
Executive Summary
During a recent security assessment of an educational institution's web application, I uncovered a chain of vulnerabilities that ultimately led to complete infrastructure compromise. What began as a simple configuration oversight escalated from local file inclusion to unrestricted file upload, and finally, full database access.
This write-up serves as a case study on why defense-in-depth is critical, and how minor, seemingly isolated flaws can be chained together by an attacker to completely bypass authentication.
Phase 1: The Back story, Reconnaissance & The Initial Footprint
After a long break from doing bug hunting for fun on random websites, I stumbled upon a weird PHP Laravel's Debug info leak on one of the popular Universities of south india and for next few hours I failed trying to get some interesting information out of it, I got bored and went on to find some other institution's website that are beautifully built with PHP with the help of our Good'Ol friend the Google Dorks.
On this aimless journey let's address our victim as readcted.edu.in. It is a small institution in India built from scratch with the classical LAMP stack. By some very beginnery devs, How did I know? I've explored the entire source code. 😉
Phase 2: Testing Authentication & Finding the Path Leak
Okay, now coming to the actual hack, Initially I manually enumerated the site and gathered all the accessible paths including few login pages, one for Students, one for staffs, one for hostel users, one for payments, one for parents, and couple more, what we will do when we saw login fields?… SQLi!! and I did, I injected a very basic small, simple payload (' or '1'='1'; — )but guess what? It worked! But instead of successful login it returned a SQL error with some important details like filepath of the source code
Sigh… But no worries if one entry is blocked there's a couple of others, let's try every single one and after multiple desperate attempts to login I only understood one thing that it's not possible to login bypassing this error. But I noticed one thing that is common in all the login pages that, All the entries lead to same point! I mean the same backend PHP file which handles the login requests.. from the SQL errors I found that file is /home/redacted/public_html/loginCode.php.
Phase 3: Exploiting Arbitrary File Download (LFI)
After having some little interaction I found a little secret, A beautiful file download endpoint ( https://redacted.edu.in/download.php?filename=pdf/<filename.pdf>) this secret was used by students to grab some study material PDFs, But I am not a student so guess what? I grabbed the source code itself! (Local File Inclusing). Yes I can able to download all PHP files including config.php which contains credentials for her Database! I told y'all the dev is a basic ain't I?
Phase 4: Gaining a Foothold via Unrestricted File Upload
But this LFI will not allow me to upload any data to the server, So I made a note of it and moved on to explore. After some intense enumeration, I found a photo upload feature sending request to (fileupload.php), so I quickly downloaded it using our LFI bug and discovered it does not validate the uploaded file type, So using postman I crafted a custom POST request carrying the PHP shell code. Boom! It worked and the shell code sits on the path ~/public_html/staffph/. I quickly checked if the uploaded shell code is executing by visiting the uploaded file path and it is executing as expected! using netcat I connected to the reverse shell successfully. Haha, now I gained RCE to the backend but, that's not enough for me… So, I wanted to push myself so deep into hitting the database.
Phase 5: Pivoting to Full Database Access
So using the database credentials I obtained from the source code I tried connecting to the mysql database, but the server blocks access to the DB through password login, which means… we can connect to the DB only through the unix socket which is basically you can only access the DB through programming.
Damn, this target is bit challenging, but I decided to not let it go without tasting the reward So once and for all I pull my final tool called Adminer if you guys don't know adminer is a single file php code that is used to manage SQL Database over web app so, I uploaded the adminer file and using the local credentials harvested earlier from config.php, I authenticated via the web interface of Adminer. BOOM! I sensed the taste of success! it gives access to
- 70+ Database Tables containing over 80,000 rows of sensitive records.
- Application source code backups.
- Payment gateway configurations and integration keys.
- User credentials.
Everything, every tiny detail about the site is mine now!
Finally I sent my another little tool called tinyfile manger to navigate through the filesystem more conviniently.
That's it now it is all mine! All this in just 3hrs 😎
Lessons Learned & Remediation Strategy
This attack chain highlights how a series of low or medium-severity vulnerabilities can be stacked together to create a critical, high-impact breach. To secure applications against this style of exploitation, organizations should implement the following remediations:
- Disable Verbose Errors: Production environments should always suppress database errors and stack traces. Log errors internally rather than displaying them to the end user.
- Implement Robust Input Validation: Enforce strict whitelisting for file download parameters to prevent directory traversal and arbitrary file reads.
- Secure File Uploads: Never trust user-supplied file extensions or MIME types. Uploaded files should be validated, renamed randomly, and stored entirely outside the web-accessible root directory, preferably with execution permissions disabled (
noexec). - Principle of Least Privilege: Ensure database users only have the minimal permissions required to function, and restrict administrative tools from being accessible via the public internet.
Thank you for reading!
see you in the next blog, If I write one probably:)