Sedna is a vulnerable virtual machine from VulnHub designed to teach typical web-app and service-based exploitation techniques.
After downloading Sedna, I ran it and my Kali Linux attacker VM on the same host-only network, then moved through discovery, enumeration, vulnerability research, and exploitation to capture the user flag.
Here’s a walkthrough of how I achieved this.
I ran two virtual machines in VirtualBox. One was Kali Linux, the attacker. The other was Sedna, the target. I put both on a host-only network. Host-only networking means both VMs can talk to each other, but cannot reach the wider internet or your home LAN. This keeps your tests safe and quiet.
On Kali, I ran:
nbtscan ip_address_and_subnet_mask _of_kali #nbtscan 192.168.195.0/24
nbtscan is a tool that asks systems for their NetBIOS names. It is quick and quiet compared to a full ping scan. It let me spot Sedna’s IP address on the network in seconds.
Next, I used nmap to see which ports were open on Sedna:
Nmap is a port scanner. The -sV flag also asks each service for its version. Knowing which services and versions are running guides your next steps.
nmap -sV sedna_ip_address
Once you know which ports are open (like SSH, HTTP), you can pick your attack paths.
Here, seeing HTTP on port 80 told me there was a web server worth poking at.
I opened a browser and went to:
On Browser: ip_address _of_sedna
Here, I tried inspecting the page but could not find any hidden links, with no input field, so SQL injection was out of the question. The next step was to check for hidden and accessible directories.
I used dirsearch here.
Dirsearch is a lightweight Python-based brute-forcer that enumerates directories and filenames on web servers using customizable wordlists. It’s perfect for finding hidden pages or files.
I ran:
dirsearch -u http://sedna_ip_address/ -e * -r
## -u: target URL
## -e *: all file extensions (php, html, txt, etc.)
## -r: recursive search
Here, it revealed a license.txt.
I opened this on the browser:
Inside license.txt, I saw “Builder Engine” mentioned.
PS: BuilderEngine is an open-source PHP/MySQL content management system and website builder that lets you quickly create and maintain professional sites using a user-friendly admin panel, drag-and-drop layout tools, and modular features (eCommerce, bookings, blogs, etc.), all under the MIT license
A quick Google for “Builder Engine file upload exploit” landed me on an Exploit-DB post describing an unauthenticated file-upload bug in that engine
Tip:
This is pure OSINT(open-source intelligence). Public exploits can save hours, but you must read them closely before using.
Always read exploits carefully and adjust URLs, file paths, or form names to match your target. Never run them blindly.
I copied the HTML exploit, saved it as an HTML file in Kali. Upon running it, I noticed the form was pointed at localhost. I edited its action URL so it would target Sedna instead of my own machine.
Running this HTML page allowed me to upload files to Sedna Browser.
With the possibility to now upload a file, I could proceed to have a reverse shell by exploiting the file upload vulnerability identified.
I grabbed a simple PHP reverse shell script from PentestMonkey. I edited the script so it would connect back to my Kali IP.
Then I saved it as shell.php.
Uploaded it to the HTML page I was running. I navigated to the files and identified the shell.php file.
Before activating and starting the script uploaded (clicking it)
I had to be listening on my terminal: nc -lvp 4444
This listens on port 4444 for the incoming shell connection. With me now listening, I proceeded to activate my shell script.
After a connection was established, I now had access to a shell as the web user!
Reverse vs. Bind Shell
Bind shell: target listens; attacker connects.
Reverse shell: the target connects back to the attacker.
Reverse shells often bypass firewalls/NAT since most environments allow outbound traffic. Hence, preferred here.
Tip:
A reverse shell means the target machine will call back to me, which often works better through firewalls than having me connect directly.
In my shell, I found the flag, confirming a successful exploit!
We’ve walked through every step of cracking the Sedna VM using tools you’ll find in Kali Linux. First, we set up our lab so Kali and Sedna could talk only to each other. Then we found Sedna’s IP with a quick NetBIOS scan. After that, we checked which doors (ports) were open using Nmap and saw the web server was our best bet.
We poked around the website with Dirsearch, which pointed us to a file-upload weak spot. A little online digging led us to a public exploit for the Builder Engine, which we tweaked to match Sedna’s setup.
Next, we grabbed a simple PHP reverse shell, told it to call back to our Kali box, and waited with Netcat.
Once Sedna ran our shell, we hopped into its file system, found the flag, and read it.
The key takeaway is to move step by step, always asking yourself why you’re using each tool and what you expect it to show.
Test in small chunks, check your work, and adjust any public code before you run it.