Eschaton CTF 2026 — DFIR writeup

My writeups for DFIR challenges from Eschaton CTF 2026 Qualifiers.

The last days of the previous month I participated at Eschaton CTF, where I focused primarily on the Digital Forensics and Incident Response (DFIR) category. In this write-up, I documented my approach, analysis, and findings for the DFIR challenges I successfully solved two labs DFIR exfil and retro recall but here I will focus on exfil because it is more related to what I focus for this era.

DFIR Challenge: Exfil

Challenge Overview

This challenge provided a PCAP captured from a web server during an active attack. The scenario indicated that an attacker exploited a vulnerability in a web application, gained access to the underlying system, discovered sensitive data and attempted to exfiltrate that data outside the network.

The objective was to reconstruct the full attack chain from the network traffic and recover the flag.

Flag

#esch{x0r_3xf1l_fr0m_pwn3d_w3bsh3ll}

Investigation Strategy

Analysis of the PCAP revealed a clear, realistic kill chain:

1. SQL Injection to get
2. Administrator login to the web application
3. Upload of a web shell (likely via an avatar or file upload feature)
4. Triggering a reverse shell over TCP port 4444
5. Interactive shell activity (enumeration, environment discovery)
6. Privilege escalation / sensitive file access via a misconfigured SUID binary
7. XOR encryption of the flag
8. Attempted exfiltration via an HTTP POST request

Let’s dig into it and explain how I get this information, I start searching for the target website Ip address and I got it 192.168.1.100 and I got some doubt about 192.168.1.50 which started connection with the website.

Traffic Discovery

Discover Milicious Interaction

and I discovered it performing SQL injection to get more data

Using cyberchef to decode what was sent to the server

And using a crafted GET request to /products/search containing a UNION SELECT statement. GET /products/search?... UNION SELECT username,password,email,role FROM users-- the attacker gote some cerdintials.

The server’s response includes a rendered HTML table listing usernames, password hashes, emails, and roles.

This confirms a SQL injection vulnerability that allows direct extraction of sensitive database contents. The attacker is no longer guessing — they are enumerating real users and roles directly from the backend database

Credentials Exposure

Credentials

This packet capture shows an HTTP POST request sent to /admin/login. The request body clearly contains form-encoded credentials with the username set to admin and a weak password.

Login successfully with leaked data

Initial Access — Admin Login

This confirms the attacker’s initial foothold. The presence of valid credentials in plaintext traffic indicates poor authentication security and the vulnerable website itself immediately explains how administrative access was obtained without brute force or exploitation at this stage.

Accessing Admin Account

The server responds with an HTTP/1.1 302 Found status and sets a PHPSESSID cookie, followed by a redirect to /admin/dashboard the attacker now has an authenticated administrative session. This marks the transition from unauthenticated access to privileged application control.

An authenticated POST /admin/upload request using multipart/form-data. The uploaded file is named avatar_update.php and is accepted by the server.

This is the persistence step. Uploading a PHP file to a web-accessible directory gives the attacker a reusable execution point, commonly referred to as a web shell.

Web Shell Execution

Cmd Parameter

A GET request to /uploads/avatars/avatar_update.php with a cmd parameter executing a Bash reverse shell command targeting port 4444.

This confirms active remote code execution. The attacker is no longer interacting through the web application logic but is executing system-level commands directly on the server.

A direct TCP connection between 192.168.1.100 (victim) and 192.168.1.50 (attacker) over port 4444, characterized by frequent small PSH/ACK packets. This traffic pattern is a classic indicator of an interactive reverse shell. At this point, HTTP is no longer the primary control channel the attacker has an interactive command shell.

Suspicious Traffic

The combination of Port 4444 and frequent small PSH/ACK packets strongly indicated an interactive reverse shell.

Interactive Shell Confirmation

Confirming Interactive Shell Activity

The attacker executes standard shell commands such as whoami and pwd. The output confirms the process is running as www-data from /var/www/html/uploads/avatars.

This validates the execution context of the compromise and strongly supports the earlier conclusion that the web shell originated from the file upload feature.

Environment Variable Leakage

This directory strongly suggested that the web shell had been uploaded via a file upload feature.

The most critical command executed was:

env

which exposed sensitive environment variables among the environment variables, one stood out:

DEPLOY_TOKEN=Kj7mN2pQ9sR4vX8y

Environment variables often contain high-value secrets. In this case, DEPLOY_TOKEN later becomes the XOR encryption key, making this one of the most critical discoveries in the investigation. In real-world incidents, leaked environment variables often contain high-value secrets such as tokens, credentials, and API keys.

Discovery of a Dangerous SUID Binary

SUID Binary Discovery

The attacker enumerated SUID binaries using:

find / -perm -u=s -type f 2>/dev/null

One file immediately stood out:

/opt/backup_tool

SUID binaries run with elevated privileges. Any unsafe behavior in such binaries can lead directly to privilege escalation. This is extremely dangerous. If a root-owned SUID binary accepts arbitrary file paths, it can be abused to read protected files.

strings output reveals the binary internally executes /bin/cat %s, and direct file access attempts fail unless routed through this binary.

This confirms the binary accepts arbitrary file paths and executes them with root privileges a textbook SUID misconfiguration.

Reading the Secret Flag File

Reading the Protected Flag File

A failed direct read attempt (Permission denied) followed by successful file access using /opt/backup_tool this demonstrates how privilege boundaries were bypassed, allowing access to root-only files and ultimately the flag.

Direct access failed as expected:

cat /var/www/private/.secret_flag.txt
→ Permission denied

However, using the SUID binary:

/opt/backup_tool /var/www/private/.secret_flag.tx

successfully exposed the file contents, including the flag.

Exfiltration Stage: XOR + Hex Encoding

Instead of sending the flag in plaintext, the attacker:

1. XOR-encrypted the flag
2. Used DEPLOY_TOKEN as the repeating XOR key
3. Encoded the result as hex
4. Attempted to exfiltrate it via HTTP POST

Captured encrypted (hex string) payload:

2e195405354a402366402a524734671f395a5a323e451e625d2c2507142b504a27064a

Decrypting the Flag (XOR)

XOR decryption rule:

plaintext_byte = ciphertext_byte XOR key_byte

• Ciphertext: the hex string above
• Key: Kj7mN2pQ9sR4vX8y (cycled)

And finally we got our flag !

Key Takeaways

• PCAP analysis can fully reconstruct post-exploitation activity, even without host logs
• Environment variable leaks often expose critical secrets
• Poorly designed SUID binaries enable direct privilege escalation
• XOR “encryption” provides no real security

Final Thoughts

This challenge demonstrates how a full post-exploitation narrative can be reconstructed purely from PCAP analysis. By correlating application-layer traffic, command execution patterns, and encryption logic, it was possible to follow the attacker from initial access to data exfiltration with high confidence. The scenario closely mirrors real-world incidents, reinforcing the importance of network visibility, secure coding practices, and proper privilege separation.

Thank You For Your Time Wishing This Is Helpful :)