Post cover image

October 13, 2026

Brute It Walkthrough | TryHackMe

A practical Linux pentest covering web enumeration, Hydra, SSH private-key cracking, John the Ripper, and privilege escalation.

By isheblank

7 min read

Introduction

Hey everyone! 👋

In this write-up, I'll be sharing my experience completing Brute It, a TryHackMe room focused on password security, hash cracking, and privilege escalation.

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: Brute It
  • Environment: Kali Linux and a TryHackMe lab machine
  • Tools used: Nmap, Gobuster, Hydra, John the Ripper, SSH, and Hashcat
  • Topics covered: Reconnaissance, web enumeration, password brute-forcing, RSA private-key cracking, SSH authentication, and privilege escalation

Phase 1: Reconnaissance

Step 1: Scanning the Target with Nmap

After starting the target machine and connecting to the TryHackMe network, I began with an Nmap scan to identify open ports and the services running on the machine.

Command executed:

nmap -sC -sV 10.49.176.53

Command breakdown:

  • nmap launches the network scanning tool.
  • -sC runs Nmap's default scripts.
  • -sV attempts to identify service versions.
  • 10.49.176.53 is the target IP assigned to my lab session.

Scan Results

The scan revealed two open TCP ports:

The scan also identified the web server's default page as Apache2 Ubuntu Default Page: It works.

This gave me two services to investigate further: SSH for remote access and HTTP for potential web application entry points.

None

TryHackMe Questions — Reconnaissance

Question 1: How many ports are open?

Answer: 2

Question 2: What version of SSH is running?

Answer: OpenSSH 7.6p1

Question 3: What version of Apache is running?

Answer: 2.4.29

Question 4: Which Linux distribution is running?

Answer: Ubuntu

Phase 2: Web Enumeration

Step 2: Finding Hidden Directories with Gobuster

Next, I used Gobuster to discover directories on the web server that weren't immediately visible from the homepage.

Command executed:

gobuster dir -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt -e --no-error -t 100 \ -u http://10.49.176.53

Command breakdown:

  • gobuster dir performs directory enumeration.
  • -w specifies the wordlist used to generate directory-name guesses.
  • -e enables expanded output.
  • --no-error suppresses error messages.
  • -t 100 sets 100 concurrent threads.
  • -u specifies the target URL.

Important Findings

The scan discovered the following paths:

The /admin/ directory looked particularly interesting because it could contain an administrative interface.

None

Question 5: What is the hidden directory?

Answer: /admin

Step 3: Investigating the Admin Login Page

I opened the discovered directory in my browser:

http://10.49.176.53/admin/

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

None

Before attempting authentication, I decided to inspect the page source. Sometimes developers leave useful clues in HTML comments, even when those comments aren't visible on the rendered webpage.

Inspecting the HTML Source

The source code contained the following comment:

<!-- Hey john, if you do not remember, the username is admin -->

This revealed the username to use for the lab's admin login.

None

With the username identified, the next step was to investigate the password.

Phase 3: Password Brute-Forcing

Step 4: Using Hydra to Test the Admin Password

I used Hydra to test candidate passwords against the web login form, using the rockyou.txt wordlist.

Command executed:

hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.49.176.53 http-post-form "/admin/:user=admin&pass=^PASS^:invalid"

Command breakdown:

  • hydra performs authentication testing against supported services.
  • -l admin specifies the username.
  • -P provides a file containing candidate passwords.
  • http-post-form specifies that the target uses an HTTP POST login form.
  • /admin/ identifies the form's path.
  • user=admin&pass=^PASS^ describes the form fields, with ^PASS^ replaced by each candidate.
  • invalid is the failure indicator used to distinguish unsuccessful responses.

Result

Hydra identified valid credentials for the admin panel:

  • Username: admin
  • Password: xavier
None

This demonstrated how a weak password can put an exposed login page at risk when authentication attempts aren't sufficiently restricted.

TryHackMe Question

What is the user of the admin panel?

Answer: admin:xavier

Phase 4: Obtaining the Web Flag and RSA Private Key

Step 5: Accessing the Admin Panel

Using the credentials discovered during the previous step, I logged into the admin panel.

The page displayed a message indicating that John had an RSA private key available.

It also displayed the web flag.

None

Web flag:

THM{brut3_f0rc3_is_e4sy}

The link to the RSA private key was the next useful finding. An encrypted private key can still be a security risk if its passphrase is weak enough to recover.

Step 6: Retrieving the RSA Private Key

I opened the private-key link provided by the application.

The response contained an encrypted RSA private key.

None

I copied the key into a local file named rsa_id for further analysis.

nano rsa_id

Because SSH expects private keys to be protected by restrictive file permissions, I set the file's permissions before using it:

chmod 600 rsa_id

I also checked the file type:

file rsa_id

The output identified it as a PEM RSA private key.

None

Step 7: Converting the Key for John the Ripper

The private key was encrypted, so I needed to recover its passphrase before I could authenticate with it.

I used ssh2john to convert the key into a format John the Ripper could process.

Commands executed:

ssh2john rsa_id > rsa_id.hash

Then I used the rockyou.txt wordlist to test possible passphrases:

john rsa_id.hash -w=/usr/share/wordlists/rockyou.txt

John successfully recovered the passphrase.

None

TryHackMe Question: What is John's RSA private-key passphrase?

Answer: rockinroll

This step helped me understand that a private key's security depends not only on the key itself, but also on the strength of the passphrase used to protect it.

Phase 5: SSH Access

Step 8: Logging in as John

With the key's passphrase recovered, I used the private key to connect to the target over SSH.

Command executed:

ssh -i rsa_id john@10.49.176.53

The -i option specifies the identity file SSH should use for authentication.

After entering the recovered passphrase, I successfully logged in as john.

None

Once inside, I checked the home directory:

ls

The directory contained user.txt.

I read the file:

cat user.txt

The output provided the user flag.

None

TryHackMe Question: What is the user flag?

Answer: THM{a_password_is_not_a_barrier}

Phase 6: Privilege Escalation

Step 9: Checking Sudo Permissions

Getting access as john was an important milestone, but I still needed to investigate whether the account had any privileges that could allow me to become root.

I checked the account's allowed sudo commands.

Command executed:

sudo -l

The output revealed that john could run /bin/cat as root without being prompted for a password.

(root) NOPASSWD: /bin/cat
None

This was a significant misconfiguration. The cat utility normally just displays file contents, but allowing it to run as root means the user may be able to read files that would ordinarily be restricted.

Step 10: Reading /etc/shadow

I used the permitted command to read /etc/shadow, which stores password-hash information for local accounts.

Command executed:

sudo /bin/cat /etc/shadow

The output included the root account's password hash.

None

The important finding was that the permitted sudo command gave me access to sensitive authentication data.

Rather than needing to exploit a new service, I could now investigate the root password hash offline.

Step 11: Cracking the Root Password Hash with Hashcat

I copied the root hash into a local file named hash.

The hash began with $6$, indicating the SHA-512-based Unix password-hashing format commonly referred to as sha512crypt.

I used Hashcat's mode 1800 for this format and supplied the rockyou.txt wordlist.

Command executed:

hashcat -m 1800 -a 0 hash /usr/share/wordlists/rockyou.txt

Command breakdown:

  • hashcat runs the password-recovery operation.
  • -m 1800 selects the SHA-512 crypt hash mode.
  • -a 0 selects a dictionary attack.
  • hash is the local file containing the extracted password hash.
  • The final argument specifies the wordlist.

Hashcat successfully recovered the root password.

None

TryHackMe Question: What is the root's password?

Answer: football

This was another example of why a strong password matters even when the underlying system uses a password hash rather than storing the password directly.

Step 12: Switching to Root

With the recovered password, I switched from the john account to root.

Command executed:

su root

After entering the recovered password, I verified the active account:

whoami

The output confirmed:

root

I then navigated to root's home directory and read root.txt.

cd ~
cat root.txt

The file contained the final flag.

None

TryHackMe Question: What is the root flag?

Answer: THM{pr1v1l3g3_3sc4l4t10n}

What I Learned

1. Reconnaissance Comes First

Nmap showed which services were available, while Gobuster helped uncover the admin directory. This gave me a starting point for the rest of the investigation.

2. Weak Passwords Can Expose Login Interfaces

The admin page revealed the username through an HTML comment, and password testing identified a weak password. This reinforced the importance of strong credentials, rate limiting, and monitoring failed login attempts.

3. Private Keys Need Strong Passphrases

The RSA private key was encrypted, but its passphrase was recoverable with a wordlist. Strong, unique passphrases add an important layer of protection for SSH keys.

4. Sudo Permissions Must Be Carefully Restricted

Allowing an account to execute cat as root might sound harmless, but it can expose protected files such as /etc/shadow. Commands that appear simple should still be evaluated according to their privileges and potential impact.

5. Password Hashing Does Not Make Weak Passwords Safe

Hashcat was able to recover the root password from the extracted hash using a wordlist. Password strength remains essential even when a system stores hashed passwords.

Conclusion

Brute It was a useful practical exercise in understanding how several small weaknesses can combine to compromise a Linux system.

My biggest takeaway was that security depends on how different layers work together. A strong password policy, carefully managed SSH keys, and restrictive privilege assignments could have prevented several of the weaknesses demonstrated in this room.

My Rating

My rating: 9/10