Note: In an attempt to be OSCP friendly, NONE of my write ups will utilize Metasploit. Zero. Zip. Tell your friends.

As always, we’ll start with our standard nmap scan: nmap -sC -sV

And it looks like there’s quite a few things open:

So we have port 8080, which is often used as a web browser port/http, so let’s bring up our browser and see what that’s all about.

If we scroll down on the webpage far enough, we see that there’s a .py script/source code we probably want to take a look at:

So, time to enumerate.

We’ll start with gobuster: gobuster dir -u -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

And stuff went belly up super quick….some Googling this error stated that this can come up when the server sends back invalid HTTP responses…so let’s try another tool. Wfuzz.


Wfuzz is used to brute force web applications, so let’s give it a shot. We’ll use the medium.txt file that is stored in the wfuzz directory in Kali linux:

Wfuzz doesn’t like us pointing to d

And then we’ll use this command: wfuzz -c -z file,/usr/share/wfuzz/wordlist/general/medium.txt -u

Let’s break this command down:
– c specifies output with colors
-z specifies the payload, in this case the word FUZZ.

So what will happen is it will take every word in the medium.txt file and put it in the location of FUZZ above and hopefully we’ll find a directory.
Let’s run it:

It get spammy fast. So scroll through the output and you’ll see a response code 200 for the word develop

So let’s navigate to that page:

Figure out how this works…write a script….


When we navigate to /home we see that there is only one directory: robert

And there’s a bunch of stuff in this directory:

When we try to look at the user.txt file we have a problem:

Let’s check out the check.txt file:

So…we notice in our current directory there is already a file called out.txt so let’s cat it:

Let’s also look at that passwordreminder.txt file:

We had to use hd to look at it because cat gave us garbage.

And then the .py file:

Ugh…this is what it looks like happens:

The characters are converted into ASCII codes, and then added to the key. Then they’re converted into characters.

So, after some analysis I think this is what’s going on:
1. SuperSecureCrypt.py is the file used to encrypt
2. check.txt is the clear text of the encrypted file out.txt
3. out.txt is the encrypted text of check.txt
4. passwordreminder.txt is the encrypted password for the user robert

So, the interesting thing about the way this is encrypted is that you can obtain the password used in the encrypted text if you know the clear text. So let’s try something: python3 SuperSecureCrypt.py -d -k “Encrypting this file with your key should result in out.txt, make sure your key is correct!” -i out.txt -o /tmp/passwd.txt

The reason we re-direct it to /tmp/ is because everyone had write access to /tmp/ by default, and the first time I tried running this script I got access denied.

It looks like the password might be alexandrovich and it might repeat? Or that might be a bug in my janky code. We’ll see. Let’s see if we can use that to get some more info. Now that we have the password, we should be able to decrypt the password for the user robert from the passwordreminder.txt file: python3 SuperSecureCrypt.py -d -k alexandrovich -i passwordreminder.txt -o /tmp/robertpwd.txt

Now, let’s try to SSH into the box with this new password. Open up a new terminal window and type ssh [email protected] with the password SecThruObsFTW

And the user flag is right there:


Doing a quick sudo -l on Robert’s account shows us something interesting:

So we can run the script in /home/robert/BetterSSH/BetterSSH.py without a password. So let’s go check it out.

And if we cat it there’s a lot going on:

The last part of the script stands out:

Basically, if we run this script and enter the correct password for the user (which we have, since we used it to SSH into the box) commands will be run inside the host as root. So, if our command starts with -u root the command will be executed as root.

Or not…I got errors just trying to get the script to run. Let’s look at the script again.

It looks like this script reads the contents of /etc/shadow and then writes its contents to a temp file. We should be able to watch the temp file in the /tmp/SSH directory while we run the BetterSSH.py script to get the contents of the /etc/shadow file. For some reason there’s a .1 second sleep in the script file and we can use this delay in our script too in hopes of improving our chances of reading this temp file. To do this, we’re gonna need to SSH into the box again.

And that failed…with the same error. Let’s try this again…

So after banging my head against the wall for like..an hour..I double checked the /tmp directory.

And there’s no SSH folder which is required by the script. So let’s create that directory and then try again.

Success. Now…let’s try to run a command as root to get the flag: -u root cat /root/root.txt

And you’ll see that it worked!

Leave a Reply

Your email address will not be published. Required fields are marked *