Agent Sudo

Introduction

If you're just starting out in cybersecurity and looking for a Capture The Flag (CTF) room that actually teaches you something instead of just frustrating you, Agent Sudo on TryHackMe is one of the best entry points around. It's built specifically for newcomers, and it touches on a huge range of foundational skills: scanning, web enumeration, brute forcing, steganography, hash cracking, SSH access, and privilege escalation.

The room's backstory is simple and fun: somewhere under the deep sea sits a secret server. Your job is to break in, uncover a hidden spy network of "agents," and eventually seize full control of the machine. Along the way, you'll pick up habits and tools that will follow you through the rest of your hacking journey.

This guide walks through the entire room step by step, explaining not just what commands to run, but why we run them. Even if you've never touched a terminal for security work before, you should be able to follow along.

Let's dive in.

Setting the Stage: What You'll Need

Before starting, make sure you have:

• A TryHackMe account and access to the Agent Sudo room

• A Kali Linux machine (or any Linux distro with common pentesting tools installed) — TryHackMe's own AttackBox works fine too

• A VPN connection to TryHackMe's network, or you're using the AttackBox directly in your browser

• The target machine's IP address, which you'll get once you deploy the room

Once your machine is deployed, you'll have an IP address to target. Keep that IP handy — you'll use it constantly throughout this walkthrough. From here on, I'll just refer to it as <TARGET_IP>.

Phase 1: Reconnaissance and Enumeration

Every engagement — whether it's a CTF or a real penetration test — starts the same way: figure out what you're dealing with. This phase is called enumeration, and it's arguably the most important skill in all of hacking. Skip it or rush it, and you'll miss the doors that are standing wide open.

Step 1: Scanning for Open Ports with Nmap

The very first tool almost every hacker reaches for is Nmap (Network Mapper). It's a free, open-source tool that scans a target and tells you which network ports are open, what services are running on them, and often even the exact software version powering each service.

Run the following:

bash

nmap -sS -sV -A <TARGET_IP>

Let's break that command down piece by piece, since understanding your tools matters more than memorizing them:

• -sS performs a SYN scan (sometimes called a "stealth scan"). It's fast and doesn't complete the full TCP handshake, which historically made it quieter than a full connect scan.

• -sV tells Nmap to attempt service/version detection — instead of just saying "port 21 is open," it tries to tell you it's running vsftpd 3.0.3, for example.

• -A enables aggressive scanning, which bundles in OS detection, script scanning, traceroute, and more detailed banner grabbing.

After the scan finishes, you should see a handful of open ports, most likely including:

• Port 21 — FTP (File Transfer Protocol)

• Port 22 — SSH (Secure Shell)

• Port 80 — HTTP (a web server)

Three open doors, three different ways in. Write these down — you'll need each one later.

Step 2: Poking at the Web Server

With port 80 open, the natural next move is to see what's being served. Instead of opening a browser, we'll use curl, a command-line tool for making HTTP requests. Working from the terminal keeps everything scriptable and lets us see the raw response, including headers, which browsers sometimes hide or interpret for you.

bash

curl <TARGET_IP>

Doing this without any extra options gives us a webpage with a curious message. It reads roughly like a note left behind by "Agent R," saying that only authorized agents should be viewing this page — and hinting that your identity needs to be presented as a specific HTTP header before you're allowed to see the real content.

This is a great early lesson: web servers don't just look at the URL you request. They also read metadata sent along with your request, and one very common piece of metadata is the User-Agent header — a string that normally identifies your browser (like "Mozilla/5.0…"). Here, the challenge wants us to forge that header to pretend to be a specific agent.

The note is signed "Agent R," which gives us our first real clue. If the codenames are based on the alphabet (Agent A, Agent B, Agent C, and so on), then "R" is just one letter in that sequence. Let's test that theory by setting our User-Agent to the letter itself:

bash

curl -A "R" -L <TARGET_IP>

Here's what those flags do:

• -A "R" sets the outgoing User-Agent header to the string R

• -L tells curl to follow redirects — if the server responds with a "moved" instruction, curl will automatically chase it down rather than stopping short

The response this time is more revealing. It mentions a headcount — something like 25 employees, not counting Agent R — which all but confirms the alphabet theory. If there are 26 letters and one is already accounted for (R), the rest are presumably assigned to the other agents.

Step 3: Brute-Forcing the Right Letter

Rather than guessing endlessly one letter at a time by hand, the efficient approach is to try each letter of the alphabet as the User-Agent and watch for a response that looks different from the rest. You can do this manually:

bash

curl -A "A" -L <TARGET_IP> curl -A "B" -L <TARGET_IP> curl -A "C" -L <TARGET_IP>

…and so on, or write a tiny one-line loop to automate it:

bash

for letter in {A..Z}; do echo "Testing letter: $letter" curl -s -A "$letter" -L <TARGET_IP> echo "----" done

Somewhere in that sequence, one letter breaks the pattern and returns a genuinely different page — one that finally names a real agent. This is the answer to the room's next question, and it also hands us the username we'll need in Phase 2.

That wraps up enumeration. We now know three open services and have a legitimate username to work with. Time to turn that username into full access.

Phase 2: Cracking Passwords and Digging Through Hidden Files

Knowing a username gets you halfway to a login. The other half — the password — almost never gets handed to you. This is where brute forcing comes in: systematically trying a huge list of possible passwords until one works.

Step 4: Brute-Forcing FTP with Hydra

Hydra is a fast, flexible tool built specifically for this kind of password-guessing attack, and it supports dozens of protocols out of the box, including FTP, SSH, HTTP forms, and more.

TryHackMe conveniently provides a copy of rockyou.txt, one of the most famous password wordlists in existence. It's a real-world leaked password list from a 2009 data breach, and to this day it remains shockingly effective against weak passwords because it reflects what people actually choose when left to their own devices.

Run:

bash

hydra -l <agent_name> -P /path/to/rockyou.txt <TARGET_IP> ftp

Breaking this down:

• -l <agent_name> specifies a single, known username (lowercase -l for "login")

• -P /path/to/rockyou.txt points Hydra at the wordlist of candidate passwords (uppercase -P for "Password list")

• <TARGET_IP> ftp tells Hydra which service and target to attack

Give it a little time. Hydra will hammer through the wordlist and, if the password is in there, it'll surface it along with a success message. Beginners are sometimes surprised how quickly this works — a reminder of just how important strong, unique passwords are in the real world.

Step 5: Logging Into FTP and Grabbing Files

With a username and password in hand, log into the FTP server:

bash

ftp <TARGET_IP>

Enter the credentials when prompted. Once inside, list the directory contents:

bash

ls

You should find three files worth grabbing — typically one text file and two images. Download them all to your local machine:

bash

get filename1 get filename2 get filename3

(Or use mget * to grab everything in one shot, if your FTP client supports it.)

Step 6: Reading the Text File

Open the downloaded text file in any text editor or just cat it in your terminal. It contains a short note addressed to another agent, further reinforcing the alphabet-codename theory and nudging you toward the idea that something valuable is hidden inside one of the two images.

This is your cue to think like an investigator: if a message says "check the picture," the picture is probably hiding more than meets the eye. Enter steganography — the practice of concealing data inside another, innocent-looking file, like an image.

Step 7: Finding Hidden Data with Binwalk

Binwalk is a tool designed to analyze files and detect embedded content — other file types, compressed archives, or anything that's been appended or hidden inside the file you're looking at. It's often the first tool people reach for when they suspect steganography.

Run it against each image:

bash

binwalk image1.jpg binwalk image2.png

One of the images will likely come back clean, showing nothing unusual. The other, however, should reveal something extra buried inside it — commonly a compressed archive like a ZIP file appended to the end of the image data. This trick works because many image formats don't strictly require the file to end right after the image data; extra bytes tacked onto the end are simply ignored by most image viewers, making it a sneaky (and surprisingly common) hiding spot.

Step 8: Extracting the Hidden Archive

Once Binwalk confirms there's something buried inside, extract it with the -e flag:

bash

binwalk -e image2.png

This creates a new folder containing whatever Binwalk managed to carve out — in this case, a password-protected ZIP file. Progress! But a locked ZIP file is just another wall to climb.

Step 9: Cracking the ZIP Password with John the Ripper

To crack a password-protected ZIP file, we need to first convert it into a format that a password-cracking tool can actually work with. That's what zip2john is for — it extracts the password hash from the ZIP file and formats it for John the Ripper, one of the oldest and most trusted password-cracking tools around.

bash

zip2john locked.zip > zip_hash.txt

Now feed that hash file to John, along with our trusty wordlist:

bash

john --wordlist=/path/to/rockyou.txt zip_hash.txt

Once John finishes chewing through the list, you can view the cracked password with:

bash

john --show zip_hash.txt

Step 10: Opening the ZIP File

With the password in hand, extract the archive. The unzip command sometimes struggles with certain ZIP compression methods, so 7z (p7zip) tends to be a more reliable choice for CTFs:

bash

7z e locked.zip

Enter the password when prompted, and the contents will spill out.

Step 11: Decoding a Base64 Message

Inside the extracted files is a note — a message from one agent to another, mentioning that a picture needs to be sent to something that looks like a random jumble of letters, not an actual name. That's a strong signal that it's encoded rather than a literal identifier.

The pattern of the string (a clean mix of upper/lowercase letters, sometimes ending in = padding) is a classic giveaway for Base64 encoding — a common way to represent binary or text data using only printable characters. Base64 isn't encryption; it's just a different representation, and it's trivially reversible.

Decode it like this:

bash

echo "ENCODED_STRING_HERE" | base64 -d

The decoded result is a normal, readable word — and it turns out to be exactly the kind of thing you'd use as a steganography passphrase.

Step 12: Using Steghide on the Second Image

Remember that second image — the one Binwalk didn't flag as hiding anything? Binwalk is great at spotting appended files, but steganography tools like Steghide can embed data within the image's actual pixel data using much subtler techniques that Binwalk won't catch.

First, check whether the image has anything embedded using the passphrase we just decoded:

bash

steghide info image1.jpg

Enter the passphrase when prompted. If it reports a hidden file, you're in business. Extract it:

bash

steghide extract -sf image1.jpg

Enter the passphrase again, and out comes another hidden text file.

Step 13: Reading the Final Clue

Open this newly extracted file. It reveals the identity and password of yet another agent — one who has direct SSH access to the server. This is exactly what we need to move from "outside looking in" to "actually logged into the box."

Phase two complete. We've gone from a single username to a full chain of credentials, cracking two different password protections and uncovering two layers of hidden data along the way. Not bad for a beginner room!

Phase 3: Getting a Foothold and Capturing the User Flag

Step 14: Logging In via SSH

Now we put those freshly discovered SSH credentials to use:

bash

ssh <agent_name>@<TARGET_IP>

Enter the password when prompted, and — assuming everything checks out — you're in. This is a genuinely exciting moment in any CTF: the shift from poking at a system from the outside to actually having a shell running on it.

Step 15: Exploring the Home Directory

Once logged in, get your bearings:

bash

ls -la

You should spot two things of interest: the user flag file, and an image named something like alien_autopsy.jpg. Pull the image back to your own machine to inspect it more closely — scp is perfect for this:

bash

scp <agent_name>@<TARGET_IP>:alien_autopsy.jpg .

A quick reverse image search (or just a knowledgeable eye) will let you identify what's actually pictured — a fun little pop-culture nod baked into the challenge that doubles as a quiz question.

Step 16: Grabbing the User Flag

Simply read the flag file:

bash

cat user_flag.txt

Copy that flag into TryHackMe to confirm you've captured it. You now have a genuine foothold on the machine — but a normal user account is rarely the end goal. Time to go after root.

Phase 4: Privilege Escalation

This is the phase that scares beginners the most, but it's also one of the most satisfying once it clicks. Privilege escalation is the process of turning limited access into full administrative (root) control.

Step 17: Checking Your Sudo Permissions

The very first thing to check on any Linux box once you have a shell is what your current user is allowed to do with elevated privileges:

bash

sudo -l

This lists any commands your account can run via sudo, with or without a password. In this room, the output reveals something unusual: the current user can run /bin/bash as any other user on the system, except root — using a syntax like:

(ALL, !root) /bin/bash

At a glance, that restriction looks like it should be safe. Surely if you're blocked from becoming root, you can't escalate? This is exactly the kind of assumption that real vulnerabilities are built on.

Step 18: Researching the Vulnerability

A quick search for "sudo exploit bypass root restriction" turns up a real, publicly disclosed vulnerability: CVE-2019-14287. This flaw affected versions of sudo prior to 1.8.28, and it involved exactly this scenario — a sudo configuration meant to block a user from running commands as root could actually be tricked into granting root access anyway, due to how sudo handled user IDs internally.

Before trying anything, confirm the installed sudo version matches the vulnerable range:

bash

sudo -V

If the version reported is 1.8.27 or earlier, you're clear to proceed.

Step 19: Understanding the Bug (Briefly)

Without getting lost in kernel-level detail: Linux identifies users internally by numeric IDs, not just usernames. Root is always user ID 0. The vulnerable versions of sudo failed to properly handle a negative or otherwise unusual user ID value passed to the -u flag. Because of how that value got interpreted internally, sudo could end up executing the command as UID 0 — root — even though the configuration explicitly tried to forbid targeting root directly.

It's a great real-world example of why security configurations need to be tested against edge cases, not just the "obvious" attack path.

Step 20: Exploiting It

The practical exploit is refreshingly simple — no custom scripts or compiled payloads required, just a crafted sudo command:

bash

sudo -u#-1 /bin/bash

Here, -u#-1 tells sudo to run the command as the user with UID -1. Due to the bug, this integer wraps around and effectively becomes UID 0 — root. If everything lines up, you'll suddenly have a shell with full root privileges.

Confirm it worked:

bash

whoami id

Both should now report root.

Step 21: Capturing the Root Flag

With root access secured, navigate to the root user's home directory and read the final flag:

bash

cd /root cat root.txt

Submit that flag, and along the way you'll likely spot one last message revealing the true identity of "Agent R," tying the whole story together as a nice narrative bow on the technical challenge.

Wrapping Up

Congratulations — you've just completed the Agent Sudo room from start to finish! Let's recap everything you practiced along the way, because the tools matter far less than the thinking process behind them:

1. Reconnaissance — using Nmap to map out open ports and running services before touching anything else

2. Web enumeration — manipulating HTTP headers with curl to access hidden content

3. Brute forcing — using Hydra and a real-world password list to crack FTP credentials

4. File analysis — using Binwalk to detect data hidden inside image files

5. Password cracking — converting a ZIP's protection into a crackable hash with zip2john and John the Ripper

6. Encoding recognition — spotting and decoding Base64

7. Steganography — using Steghide to pull hidden files out of images the "easy" tools missed

8. Remote access — using SSH to get an actual foothold on the target

9. Privilege escalation — researching and exploiting a real CVE to go from limited user to root

What makes Agent Sudo such a great beginner room isn't just that it's approachable — it's that nearly every technique here shows up again and again in real penetration tests and even in actual breach investigations. Weak passwords, forgotten hidden files, misconfigured sudo permissions — these aren't just CTF tropes, they're genuinely common findings in the wild.

If you enjoyed this room, a natural next step is to look for other beginner-friendly TryHackMe rooms that build on these same fundamentals, and to start getting comfortable reading CVE writeups on your own — being able to translate "here's a vulnerability description" into "here's how I'd actually exploit it" is a skill that only gets better with practice.

Happy hacking, and see you in the next writeup!