Post cover image

October 14, 2026

Pickle Rick Walkthrough | TryHackMe

A Rick and Morty-themed CTF walkthrough covering web enumeration, command execution, hidden ingredients, and privilege escalation.

By isheblank

7 min read

Introduction

Hey everyone! 👋

In this write-up, I'll be sharing my experience completing Pickle Rick, a TryHackMe CTF challenge inspired by the animated series Rick and Morty.

I'll walk through my approach, the commands I used, the findings I discovered, and the answers to the room's questions.

Let's get started! 🚀

Lab Overview

  • Platform: TryHackMe
  • Room: Pickle Rick
  • Difficulty: Easy
  • Environment: Kali Linux and a TryHackMe lab machine
  • Tools used: Nmap, Gobuster, a web browser, Netcat, and Linux command-line utilities
  • Topics covered: Network reconnaissance, web enumeration, command execution, reverse shells, Linux permissions, and privilege escalation

Phase 1: Reconnaissance

Step 1: Scanning the Target with Nmap

After deploying the machine and connecting to the TryHackMe network, I started by scanning the target to identify open ports and the services running on it.

Command executed:

nmap -sC -sV 10.49.140.138

Command breakdown:

  • nmap launches the Network Mapper tool.
  • -sC runs Nmap's default scripts.
  • -sV attempts to identify service versions.
  • 10.49.140.138 is the target IP assigned to my session.

Scan Results

The scan identified two open TCP ports:

The HTTP service also revealed the page title Rick is sup4r cool!

With SSH and HTTP exposed, I decided to begin by investigating the website.

None

Phase 2: Web Enumeration

Step 2: Exploring the Homepage

I opened the target IP in my browser:

http://10.49.140.138/

The homepage displayed a message asking for help with Rick's pickle problem.

None

At first, the page looked like a simple themed landing page. However, rather than relying only on what was visible, I decided to inspect the HTML source for additional information.

Step 3: Inspecting the Page Source

I opened the page source using the browser's View Page Source option.

While examining the HTML, I found a comment containing a username reminder:

<!-- Note to self, remember username! -->
<!-- Username: R1ckRul3s -->

This exposed a username that could be relevant to the application's login page.

None

This was a useful reminder that HTML comments can reveal information that isn't displayed on the actual webpage.

Step 4: Investigating robots.txt

Next, I opened the website's robots.txt file:

http://10.49.140.138/robots.txt

The file contained the following text:

Wubbalubbadubdub
None

This looked like another clue that might be useful during authentication. Combined with the username discovered in the page source, I now had two pieces of information to investigate further.

Step 5: Discovering Hidden Web Directories

I used Gobuster to identify additional files and directories on the web server.

Command executed:

gobuster dir -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt -x php,html,txt.zip -e --no-error -t 100 -u http://10.49.140.138

Command breakdown:

  • gobuster dir performs directory enumeration.
  • -w specifies the wordlist.
  • -x php,html,txt.zip adds the specified extensions to the search.
  • -e enables expanded output.
  • --no-error suppresses error messages.
  • -t 100 sets 100 concurrent threads.
  • -u specifies the target URL.

Important Findings

The scan returned several interesting paths:

The login page was particularly interesting because I already had a possible username and a clue from robots.txt.

None

Phase 3: Logging In and Exploring the Command Panel

Step 6: Accessing the Login Page

I navigated to the discovered login page:

http://10.49.140.138/login.php

The page presented a login form with username and password fields.

None

Using the clues collected during reconnaissance, I tested the following credentials in the lab:

  • Username: R1ckRul3s
  • Password: Wubbalubbadubdub

After successfully logging in, I gained access to the portal.

Step 7: Exploring the Portal

The portal contained a command panel that allowed commands to be submitted through the web interface.

I used the available functionality to inspect the application's directory and discover which files were present.

The listing included:

Sup3rS3cretPickl3Ingred.txt
assets
clue.txt
denied.php
index.html
login.php
portal.php
robots.txt
None

Among these files, Sup3rS3cretPickl3Ingred.txt looked particularly relevant to the challenge. I also noted clue.txt, which could provide further direction.

Testing the Command Panel

Some commands were restricted by the application, and the portal displayed a message explaining that certain commands were disabled.

cat Sup3rS3cretPickl3Ingred.txt
None

I also checked for the location of Python 3 in the environment.

which python3
None

These observations helped me understand the limitations of the command panel and motivated me to investigate the underlying system from a proper shell.

Phase 4: Obtaining a Shell

Step 8: Preparing the Reverse Shell

To obtain a more flexible shell in the authorized lab environment, I used a Python reverse-shell payload.

A reverse shell allows a process on the target to initiate a connection back to the machine listening for it. The callback address must be reachable from the target, and both sides must use the same port.

I referred to a reverse-shell reference to understand the required connection settings.

None

In my lab session, I configured the callback to use my Kali machine's address and port 5555.

Step 9: Starting the Netcat Listener

Before triggering the payload, I started a listener on my attacking machine.

Command executed:

nc -lnvp 5555

This placed Netcat into listening mode on port 5555.

None

I then submitted the Python payload through the portal's command field. The payload initiated a connection back to the listener, providing a shell on the target.

None

Successful Connection

The listener received a connection from the target machine, and I was able to interact with the resulting shell.

None

This was a major step forward because I could now explore the target filesystem directly rather than relying solely on the limited web command panel.

Phase 5: Finding the Three Ingredients

Step 10: Retrieving the First Ingredient

Once I had the shell, I listed the files available in the current directory.

ls

The output included Sup3rS3cretPickl3Ingred.txt, the file I had noticed earlier in the portal.

I read the file:

cat Sup3rS3cretPickl3Ingred.txt

The output revealed the first ingredient.

None

Question: What is the first ingredient that Rick needs?

Answer: mr. meeseek hair

Step 11: Reading the Clue File

Next, I inspected clue.txt.

Command executed:

cat clue.txt

The file contained this message:

Look around the file system for the other ingredient.
None

The clue suggested that the next ingredient was somewhere else on the machine, so I moved on to explore the home directories.

Step 12: Searching the Home Directory

I navigated to /home and listed its contents.

Commands executed:

cd /home
pwd
ls

The output showed two directories:

rick
ubuntu

I then navigated into Rick's home directory:

cd rick
ls

The directory contained a file named second ingredients.

Since the filename contained a space, I needed to quote it when passing it to cat.

cat "second ingredients"

The file revealed the second ingredient.

None

Question: What is the second ingredient in Rick's potion?

Answer: 1 jerry tear

This step was also a useful reminder that spaces in filenames need to be handled correctly by shell commands.

Phase 6: Privilege Escalation

Step 13: Checking Sudo Permissions

After recovering the first two ingredients, I checked the permissions available to the current account.

Command executed:

sudo -l

The output showed that the www-data account could run commands as any user without a password:

(ALL) NOPASSWD: ALL
None

This was a serious misconfiguration. The web service account had far more privileges than it needed.

The sudo configuration provided a direct path to root access.

Step 14: Obtaining a Root Shell

I used the permitted sudo access to start an interactive Bash shell with elevated privileges.

Command executed:

sudo bash -i

After the command completed, I checked the account:

whoami

The output confirmed that the shell was running as root.

None

The key lesson was that unnecessary administrative privileges on a service account can turn a web application compromise into full system access.

Step 15: Retrieving the Final Ingredient

With root access, I navigated to the root user's home directory:

cd /root
ls

The directory contained 3rd.txt.

I read the file:

cat 3rd.txt

The output revealed the final ingredient.

None

Question: What is the last and final ingredient?

Answer: fleeb juice

What I Learned

1. Reconnaissance Provides Direction

Nmap gave me an initial view of the exposed services, and Gobuster helped me discover additional web resources.

2. Source Code Can Reveal Hidden Clues

Inspecting the HTML and robots.txt uncovered information that wasn't obvious from the main page.

3. Web Applications Need Strong Access Controls

The command panel showed why allowing web applications to execute operating-system commands can introduce serious security risks.

4. Reverse Shells Provide Interactive Access

The lab helped me understand the relationship between a listener, a callback address, and a connection initiated by the target.

5. Linux Filesystem Navigation Matters

Finding the ingredients required exploring files and directories, reading clues, and correctly handling filenames containing spaces.

6. Sudo Misconfigurations Can Be Critical

The unrestricted sudo permissions assigned to www-data allowed the account to become root. This demonstrated how an overly permissive service account can undermine the security of the whole system.

Conclusion

Pickle Rick was an enjoyable way to practise web enumeration, shell access, and Linux privilege escalation through a themed CTF challenge.

The investigation started with a basic network scan and a few clues hidden in web resources. It then moved through application enumeration, command execution, filesystem exploration, and privilege escalation.

My biggest takeaway was that a web application compromise can become much more serious when the account running the application has excessive privileges.

My Rating

My rating: 9/10