FristiLeaks: 1.3 VulnHub Writeup


After the grueling beast that was The Necromancer I decided I needed to take a break with something hopefully a little bit easier and not as lengthy. This VM has been described as being closer to the beginner side so let’s spin it up and find out.
I’m not sure why but I like to start by pretending I don’t see the IP address listed right in the bootup screen of the VM so here is the netdiscover showing the remote host’s IP:

Let’s do a simple initial nmap scan to see if any services are available:

A webserver is open on port 80 so let’s go ahead and try to pull up the page in a browser.

Viewing the page source I see references to an /images/ folder as well as a note in the HTML as follows:

<!-- Welcome to #Fristleaks, a quick hackme VM by @Ar0xA

Goal: get UID 0 (root) and read the special flag file.
Timeframe: should be doable in 4 hours.

Browsing to /images/ I see another image not referenced on the main page (3037440.jpg) and take a look:

I try, http://*/admin, http://*/images/3037440/ and a couple others but without any luck. Before I go full dirbuster I’ll try a nikto scan first to see if it picks up anything more obvious:

Now I feel silly for not trying to check for robots.txt directly. Let’s take a look at that and then probe into the folders that were found by nikto.

User-agent: *
Disallow: /cola
Disallow: /sisi
Disallow: /beer

Nothing new here versus what came up in the report so on to the folders themselves.

Each returns a site with the same HTML referencing the Obi-Wan picture above:

<img src="/images/3037440.jpg"/>

Checking through the /ICONS/ directory I was hoping I’d find a file that wasn’t a GIF/PNG, or another folder, or something that was mislabeled and larger in size, but no luck there. I guess I may fire up Dirbuster after all to see if it can detect PHP directories or anything else of interest.

Soon after starting the scan 2 new folders /cgi-bin/ and /error/ get detected. I get no directory listing with /cgi-bin/ and I get a 403 Forbidden message when attempting to load /error/ or sub-directory /error/include.

After about 30 minutes (remind me next time I boot Kali to assign 2 cores instead of 1) dirbuster finishes and I don’t see anything new. Let’s try scraping a word-list based on all the content of pages we’ve seen so far:

  • the, motto, keep, calm, drink, fristi, fristileaks, meneer, barrebas, rikvduijn, wez3forsec, PyroBatNL, 0xDUDE, annejanbrouwer, Sander2121, Reinierk, DearCharles, miamat, MisterXE, BasB, Dwight, Egeltje, pdersjant, tcp130x10, spierenburg, ielmatani, renepieters, Mystery guest, EQ_uinix, WhatSecurity, mramsmeets, Ar0xA, beer, cola, sisi

I’ll try running this custom dictionary and if it doesn’t work maybe I can dig up a Dutch dictionary word-list somewhere.

Success! We found a new hidden folder “/fristi/”:

Hoping I will get some specific error feedback I try combinations of “admin/admin”, “admin/[blank]”, “[blank]/admin”, “fristi/fristi”, etc. but they all return me to a page that says Wrong Username or Password.

Interestingly, it’s an HTTP site and the password field is shown in cleartext. I get kicked to a page called “checklogin.php” (maybe I can brute-force the destination address bypassing AUTH?). I check the page source to see if there are any more details inside.

Below that there’s another comment encoded in base64:

I plugged it into an online decoder and was kind of surprised when it started downloading a PNG (then not surprised after reading the note inserted at the top).

I tried “keKkeKKeKKeKkEkkEk” as username + password, I tried it as the password for “admin”, “fristi”, “fristileaks” but with no luck…still the same generic feedback. I tried it in the URL a couple different ways too, but no luck.

At this point I opened up BurpSuite and tried the connection again to see if anything interesting would pop up in the POST/response. I double checked the code again to make sure I didn’t type it out wrong. I could use Hydra to try to bruteforce the ID, but there’s gotta be an easier way, right?

I try out navigating directly to “loginsuccess.php”, “admin.php” and a handful of others I can try to think of but none return valid. I try using dirbuster to search for ONLY *.php pages within but that doesn’t get me anything extra.

Then I read through the HTML source again and notice the top note is signed by eezeepz. Suspiciously non-brute-forceable for a login ID, right? Let’s try that and the password above.

Damn, I was on the right track before. It looks like you can navigate directly to without any authentication required.

Maybe I can upload the same PHP webshell via this upload page that I used in my Mr. Robot writeup?

Alright, well let’s upload a valid picture and see what it does.

Of course I’m going to try and bring up that folder…

Maybe rename our PHP shell to a php-reverse-shell.php.jpg and see what happens when we upload it?

Uploaded fine… Lets open up a listener and try to navigate to the uploaded file @

Great! The server loaded it as though it were just *.PHP and we got our session right away.

Poking around directories I find a list of interesting looking users under /home/

I try to “su eezeepz” but get a response back that it’s not allowed: Standard in must be a TTY

Again, as like in the Mr. Robot VM, I know a way around this:

  • echo “import pty; pty.spawn(‘/bin/bash’)” > /tmp/
  • python /tmp/


Now let’s try the su again.

Aww, no password reuse with the account. Let’s poke around the directories some more. I can’t view /home/admin or /home/fristigod but I am able to get into /home/eezeepz/ even though I’m logged in as apache still.

A lot of commands here like chmod/chown and others that don’t belong and we can take advantage of. Can I change /root to be owned by apache? No. What’s in the notes.txt?

Awesome, so we can put some commands in /tmp/ and either escalate our privileges or modify rights to.

I had some weird terminal issues trying to save with nano, so I ended up restarting the shell and trying again echoing my command to a new file.

Waited a minute or two as instructed…

Admin folder access confirmed!

The password is encrypted. Let’s look at the + files.

The is just the cron we utilized before (interestingly it blocked grep pipes, and gave a hint if you used the command from the wrong directory). But the contents of give us exactly what we need to reverse the encrypted password.

Step 1) takes string and encodes it to base64

Step 2) [::-1] – reverses order of the chars in string

Step 3) rot13 encodes the string

So we reverse the flow. Import the same libraries as in the above script. Then decode using rot13.

Then re-order.

Then base64 decode, and we have a password! Let’s try it out with fristigod!

Nope, but it worked for admin. No root access, though. I have access to tons of stuff but nothing in /home/fristigod or /root still. I killed a lot of time trying to find something interesting at this point but didn’t come up with too much. So I circled back to trying to figure out the password for fristigod instead.

Back in /home/admin there was another encrypted password, right? For whoisyourgodnow.txt?

Alright, let’s open up python and reverse this one as well.

Now let’s try switching over to fristigod with the new password.

Got it! But then I look in the /home/fristigod folder and there’s nothing there. No access to /root still either. Maybe home has some hidden files?

But probing deeper I don’t find anything meaningful. Eventually while looking around in the VAR directory I see another folder for fristigod, though.

This has to be something good. I do a cat on .bash_history and get tons of references to doCom.

I can hijack the command to su to root.

A quick cd to /root/, ls, and cat and we have our flag!

The End!