VulnHub Symfonos: 4 Walkthrough

For this walkthrough we will be looking at Symfonos: 4 from vulnhub. This was fun because I got to do some port forwarding and a pickle attack that I hadn’t done before. So let’s get started.

Here we run our typical nmap scan and see an open web port.


Navigating to the page we see a pretty background and that’s about it. Let’s run a gobuster and see what we get.


So gobuster found a gods directory which has some log files.



So the log files just contain a description of the gods. Interesting but not helpful right now. Let’s do another gobuster search but look for php extensions.


sym4-6Now we find two new pages. Going to sea just redirects us to atlantis.php which is a login page. After trying some default logins without any results, I move on to some SQL injection. After a few tries admin’;– works.


Selecting a god from the list takes us to a familiar description.


It looks like the php script is including the log files we found earlier, but it’s appending .log to the end. Let’s see if we can find any other logs.


Here we can see the auth log that gets populated through SSH. Looking back at our nmap scan, SSH is open. Let’s test it out.

If you haven’t made a snapshot of the system, I would recommend it at this point. It is very easy to mess up the logs. Quick reverts are immensely helpful.


We can see the log populate the username, so let’s try to poison it with PHP code.


Now let’s see if we can get a shell.


Ok so now we have a webshell. Let’s see if we can upgrade that to something better. I start up a netcat listener and run a netcat command in my webshell


And now we have a shell!

Let’s upgrade it with python.


What you can’t see after the stt raw -echo is that I hit enter and then fg and enter again. The netcat commands you see is just leftover from the previous terminal commands that show up when you’re switching from background to foreground.

Anyway, now that we have a better shell to play with, we can work on escalation. After some basic attempts to escalate, I tried running netstat only to find that it’s not available. That’s kind of interesting since this is a Debian system and it’s usually included by default. So I decided to run ss instead.


It looks like there’s an internal webpage that we can’t see. Let’s fix that with some port forwarding. There are different ways to do this, but it turns out that socat is installed on this box. That makes this easy.

What we’ll do is create a connection that will forward the internal port to an external one that we can view with our browser.


Now if we brows to port 7000 we should see something interesting.


Not only did we get a page, but a big hint. It redirected us to a whoami directory and said a cookie is set to Poseidon. If you look at the passwd file you can see Poseidon is the only real user on the system.

Since it mentioned a cookie, let’s look at it.


Using BurpSuite, we can reload the page and intercept the request. Here we see the username contains a base64 string. Let’s decode that. I’ll just send it over to the burp decoder.


Ok, we see the username Poseidon and some sort of python object. I had no idea what this was. Google to the rescue!

It turns out this is a json pickle. Reading this helped me figure out what to do next.

From the VerSprite page, I notice something familiar. A call for a python object.


Since this is a cookie, I assumed that the base64 string would be passed back to the rest of the code and then decoded. So let’s see what happens if we copy this code, encode it into base64 and send it back. The only difference is that instead of running whoami, I’ll try to get a shell.

Now let’s setup a listener and see what happens.





Nope didn’t work. After looking at the exploit a little more closely, I realized that it was using subsystem.Popen to make the system calls. That’s not the only option in Python. Let’s try it with something else like os.system.



After making the change we get a shell. Now who are we …?


We are root!


Well that’s it for Symfonos 4. I hope you enjoyed the walkthrough. If you’d like to see a video walkthrough you can find it here.



VulnHub DC: 1 Walkthrough

This VulnHub walkthrough is a box called DC: 1. It’s rated as a beginner box and it’s really not too difficult.

We start off by running our typical nmap scan: nmap -sC -sV -v -oN map1


There are a few ports listed here but the most interesting one is port 80. Let’s look at the website.



Ok it’s a Drupal site which confirms what Nmap found. Nmap also noted that the version was 7. Let’s see if we can find a more exact version. I’ll use droopescan: droopscan scan drupal -u



It takes a few minutes to run, but it gives us a list of possible versions between 7.22 and 7.26. Let’s see if any exploits exist.



Searchsploit returns a ton of results most of which center around the Drupalgeddon exploits. I successfully exploited the site with three of the exploits:, 44449.rb, and a Metasploit module.

For this walkthrough, I’m just going to show the Metasploit route. I’ll have a video walkthrough up soon where I’ll show all three ways. The privilege escalation is the same either way.

So let’s start up Metasploit and search for drupal.


Next, we’ll set the rhosts to the site IP address



Now, we’ll launch the exploit to get a shell.


Now that we have a shell, we can work on privilege escalation. There are a couple ways to discover the path. By running a Linux privilege checker, or by finding a hint (in the form of a flag) on the Drupal site.

I’ll use the checker for this walkthrough. So start up a python web server and use wget to download the file. I also upgraded the shell using python.

python -c ‘import pty; pty.spawn(“/bin/bash”)’dc8

python -m SimpleHTTPServer 80



Then run the checker script.


The hard part about doing it this way is that it’s really easy to miss it. You also might not know that find has an exec flag that lets you run commands on what you find.


The other way to find this would be to get the mysql password form the Drupal config, find the user password hashes, and crack them. That would lead you back to the Drupal site where you could find the hint.

All that to say is that the find command has the suid bit set which will let us execute code as the owner – in this case root.

Let’s test it out.

find /etc/shadow -exec cat {} +


If you only had a webshell at this point, you could crack the password for the flag4 user account and log in with ssh. That’s not necessary to get root or even view the root flag. Find can do all that for us (I’m still using /etc/shadow here because something has to fill the spot. It really doesn’t matter what. An empty text file would work too.)

find /etc/shadow -exec bash \;


Hmmmm … what happened here? We should have been root. Let’s try it again with sh.


Now we’re root! But why didn’t it work with bash? Let’s find out.


So it looks like running bash will actually put you in a restricted bash shell. That’s not the case with sh.

Anyway, we can now go to the root folder and view the flag.


So that was DC: 1 from VulnHub. I hope you enjoyed the walkthrough. I’ll have a video up soon that walks through the other methods to get a shell.

Update: The video can be found here

Happy Hacking!