Vulnhub – Rickdiculously Easy [Part 2]

Welcome back to Part 2 of Vulnhub – Rickdiculously Easy.

The most important “What I’ve learned through this vulnhub” is at the bottom of this post.


Last time we ended with finding the password.html file, which showed:

<body>Wow Morty real clever. Storing passwords in a file called passwords.html? You’ve really done it this time Morty. Let me at least hide them.. I’d delete them entirely but I know you’d go bitching to your mom. That’s the last thing I need.</body>

<!–Password: winter–>

Okay, a password. But where are we going to use it at? For a remainder, let me give you the nmap result we had before.

nmap real 1

We’ve gone through port 21, 22, 80, 9090, 13337, and 60000. Which all of these ports didn’t have any type of authentication. Yes, the port 9090 had an authentication through web browser, but it was missing a password section. In other words, it was a broken authentication that we couldn’t exploit.

Time to ssh.  To ssh, let’s first look what users are in our target machine by taking a look at /etc/passwd.

tail – 10 /etc/passwd

Finding Summer

Our password was winter…. and there is an user called Summer. Interesting… let’s use the password winter with the user Summer.

ssh Summer@ -p 22222

There we see it, the FLAG.txt.

FLAG 6 = FLAG{Get off the high road Summer!}


Okay, now what?

  • We are inside a target machine, via SSH
  • We are Summer, a user with limited privilege
  • We need to get a user with higher privilege, and, ultimately root

Time to enumerate and gain more information about this system and its users.Let’s take a look at the home directory of other users.

ls /home

Shows Morty, RickSanchez, and Summer. Let’s take a look at Morty.

copy read write

Thought Process

  • We see a zip file and a safe_password.jpg file.
  • Zip file requires a password
  • It seems that password should/could be acquired from Safe_Password.jpg.
  • We might have a steganography, text hidden inside Safe_Password.jpg, or something. Anyways, it is crucial to analyze Safe_Password.jpg.

It would be great if we copy these files to our host machine and take a closer look at it, because in the target machine, as user Summer, we really don’t have enough tools nor permissions.

Always, ALWAYS look at the directory, and see which permission it gives to “others” users. In Morty’s home directory, the permissions are 755, which means the “others” users have permission to Read and Execute.

Permission to copy out files from directory

  • Source directory = Read + Execute permission  (Bingo!)
  • Source file = Read permission (Bingo!)
  • Destination directory = Write + Execute permission  (doesn’t really matter in this case, since we are copying files to out host machine)

reference = Copying files and permissions to do so in Linux (

To copy files over ssh, we need to use scp. man scp to look for more information. As always, man page is the best. Let’s copy all files within Morty’s directory to our host machine’s directory.

scp -P 22222 Summer@* ~/Rickdiculously


Good. Now for analyzing Safe_Password.

file Safe_Password.jpg  shows just typical output of jpg file.

binwalk Safe_Password.jpg  shows typical output. No embedded files.

Could there be some strings embedded? Let’s check out with strings


Bingo. Using the password “Meeseek”, let’s open the file.

By the way, you could’ve poked around with xxd Safe_Password.jpg and take a look at the hexdump and look for some plaintext.

unzip, read the journal.txt, and we have the flag.


Flag 7 = FLAG: {131333}

We also get a hint saying that Rick having a safe, and using a password (131333) for it. Let’s head on to Rick’s home directory and see if there is a safe.

cd /home/RickSanchez; ls -alh


Again, we have read + execute permission for the directory, and a read permission for the safe file. What does that mean? Yeah that’s right; let’s copy the file to the directory where we can execute.

cp safe /tmp

Usually /tmp directory has permission 777 with sticky bit.

Wait, what is a sticky bit?

  • Sticky bit is a special permission set on a directory which makes only the owner of the file, or, root, to delete or rename the file.

Anyways, we have read/write/execute permission inside tmp file.

If we run the program without any password, it complains to provide a parameter for the program. Let’s run the program with an argument, the password (131333), that we’ve got from the journal.

./safe 131333

[Summer@localhost tmp]$ ./safe 131333

decrypt:  FLAG{And Awwwaaaaayyyy we Go!} – 20 Points

Ricks password hints: (This is incase I forget.. I just hope I don’t forget how to write a script to generate potential passwords. Also, sudo is wheely good.)  Follow these clues, in order

1 uppercase character

1 digit

One of the words in my old bands name. 

Flag 7 = FLAG{And Awwwaaaaayyyy we Go!} – 20 Points


For Rick’s ssh password, we have to “write a script to generate potential passwords”, which includes 1 uppercase char, 1 digit, and one of the words in Rick’s favorite old bands name.

Google search (…1318.1453.0.1609.….0…1c.1.64.psy-ab..0.0.0….0.YCXarfb_3MI) shows it’s The Flesh Curtains.

So the password will be like






… and so on, and so on.


Thought Process

  • Create a wordlist of potential passwords
  • Use this wordlist and username RickSanchez to ssh
  • Use THC Hydra program to bruteforce our way in

First part, the scripting.


This should do it.

python > wordlist

We’ve got our wordlist now. Time for bruteforce, using THC hydra.

hydra -s 22222 -l RickSanchez -P wordlist ssh -t 64 -V

  • (-s) = port number
  • (-l) = user name
  • (-P) = wordlist
  • <target _IP_address>
  • <service_name> : In this case, we are using ssh
  • (-t) = Number of threads. Let’s use 64 to speed things up. In real life situations, this will definitely be suspicious. Also, many ssh configurations will limit ssh threads to 4. But in this case,
  • (-V) = show login+pass for each attempt

If things go wrong, reduce the thread number to 16 or 4.

Rick password

We are in as Rick.

Okay, what permissions does Rick have? Can he use sudo? Is he in the sudoer file? Only one way to find out.

sudo -l

sudo /etc/sudoers  → Provide Rick’s password


Rick is in wheel(10) group, and this group can run all commands with sudo. Nice.

sudo -i         will spwan a shell as a root user.


And there we have it, the final flag.

FLAG 8 (final flag) = FLAG: {Ionic Defibrillator} – 30 points


What I’ve learned

  • Use head, tail, vi, nano, grep ‘[a-zA-Z0-9]’  to see file’s content, if cat is broken.
  • nc writes its output to standard error, you need
    • nc -zvv localhost 31000-32000 2>&1 | grep ~~
      The 2>&1 will redirect standard error to standard output so you can then pipe it to grep.
  • sudo -i = Run shell as a root, if the current user has the permission to be root.
  • sudo -l  = List user’s available commands  (same as checking group permission in /etc/sudoers)
  • Use scp to transfer/copy files over ssh.
  • Copy out from directory → Read+Execute from directory, need Read from file.
  • Copy into direcotry → Write + Execute from directory,
  • Once inside a box, check who am I? What permission does this user have? What can this user do to elevate his/her permission?
  • Recon → Poke around services → Find vulnerabilities → Get into the box → Elevate privilege → Be root
    • (Oh only if everything was this simple.)
  • Sticky bit is a special permission set on a directory which makes only the owner of the file, or, root, to delete or rename the file.



As the name suggests, RickdiculouslyEasy might seem ridiculously easy for intermediate pen testers. For an absolute beginner like me, it was just about right difficulty.

I especially liked that I was going through various services to gain access to the target machine. It was a good practice with linux cli commands as well.