TryHackMe: Basic Pentesting Walkthrough | Beginner’s Guide

Hello everyone! Welcome to my very first walkthrough on Medium. I’m really excited to start sharing my journey into offensive security with the community, and what better way to kick things off than by breaking down a classic training lab!!

Today, we’re looking at the popular TryHackMe room:Basic Pentesting. Whether you are an absolute beginner, studying for a certification, or just looking to refresh your fundamentals, this machine is an excellent playground. It perfectly demonstrates how minor network misconfigurations, weak passwords, and improper file permissions can chain together to let an attacker completely take over a system.

The Breakout: Attack Lifecycle Phases

When you’re tackling a machine like this, it helps to approach it methodically. We can break this attack down into three distinct, logical phases:

• Phase 1: Reconnaissance & Enumeration
• Phase 2: Exploitation & Initial Access
• Phase 3: Lateral Movement & Privilege Escalation

And the specific tools we’ll be using for each step:

• Phase 1 (Recon): We’ll use Nmap to scan the ports, Gobuster to dig into hidden web directories, and enum4linux paired with smbclient to poke at the SMB file shares.
• Phase 2 (Exploitation): We’ll rely on Hydra to run an online brute-force attack against SSH.
• Phase 3 (PrivEsc): We’ll use John the Ripper (specifically the ssh2john.py script) to crack an encrypted SSH private key offline.

Phase 1: Reconnaissance & Enumeration

The absolute rule of any penetration test is simple: enumerate, enumerate & enumerate... We can’t attack what we don’t know exists, so our first goal is to find open ports, see what services are active, and look for low-hanging fruit.

1. Active Port Scanning

I started things off by running an aggressive stealth SYN scan with Nmap to map out the target's network profile. I also made sure to redirect the terminal output straight into a text file so I could review it easily later.

nmap -sS -A -T5 <Targetiphere> > output.txt

Looking closely at the results, Nmap surfaced 6 open ports:

Port 22 (SSH): Running OpenSSH 8.2p1. This will be our target for brute-forcing once we have a username.

Port 80 (HTTP): A standard web server running Apache 2.4.41. Always a great place to hunt for web vulnerabilities or directory leaks.

Ports 139 / 445 (SMB): Windows-style file sharing handled by Samba smbd 4.6.2.

Port 8009 (AJP13): Apache Jserv Protocol.

Get Ashish Sunder’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Port 8080 (HTTP): An instance of Apache Tomcat 9.0.7.

2. Web Application & Directory Discovery

When you visit the web server on port 80 using a browser, it gives you a generic “Undergoing maintenance” splash screen. There’s nothing to click on, but as a rule of thumb, you should always check the underlying source code.

Now we know a “dev note section” exists, but we don’t know the exact folder path. To find it, I fired up Gobuster to brute-force the directories against the server using a common wordlist.

gobuster dir -u http://10.48.129.156/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Gobuster immediately found the hidden spot: http://10.48.129.156/development/. Navigating there in the browser opens up a directory index containing two plain text files: dev.txt and j.txt.

Let’s read them to see what the developers left behind:

• dev.txt: This note mentions upcoming software updates and explicitly states that "SMB has been configured". Crucially, it's signed with a single letter: -K.

• j.txt: This note is a direct warning to a user named J. It tells them that their credential hash was incredibly easy to crack straight out of the shadow file, and demands that they change their password immediately.

This gives us an incredible roadmap. We now know two potential usernames: a developer named Kay (-K), and a target user named Jan (J) who is actively using a terrible, easily guessable password.

3. Samba/SMB Infrastructure Enumeration

Since the development notes explicitly mentioned that SMB was up and running, it was time to pivot over and look at those network file shares on ports 139 and 445. For this, I used enum4linux.

Quick tip: enum4linux is an awesome tool for enumeration that essentially acts as an automated script to query Samba shares, scrape user details, and look for open guest access paths.

enum4linux -S 10.48.129.156

The scan confirmed our suspicions, revealing a publicly accessible share folder named Anonymous that allowed completely unauthenticated guest logins.

smbclient //10.48.129.156/Anonymous

Inside the share was a text file titled staff.txt. I downloaded it to my local machine and opened it up. The file contained an announcement from Kay that explicitly confirmed our primary target's username: jan.

Phase 2: Exploitation & Initial Access

At this point, the puzzle pieces are falling into place. We have an open SSH port, a confirmed username (jan), and a formal warning from the dev logs telling us that Jan uses a weak password. This is the perfect recipe for a dictionary attack.

1. Network Authentication Brute-Force

I targeted the SSH protocol on port 22 using Hydra, matching Jan's username against the rock-solid rockyou.txt wordlist.

hydra -l jan -P /usr/share/wordlists/rockyou.txt ssh://10.48.129.156 -V

It didn’t take long at all. Within a few moments, Hydra successfully cracked the account and dumped a valid login combination:

• Username: jan
• Password: *****

2. Establishing the Foothold

With legitimate credentials in hand, I authenticated directly to the target machine via SSH to establish a stable terminal foothold.

ssh jan@10.48.129.156

Once inside, running basic checks like whoami and checking the /home folder verified that we were logged in as jan, and confirmed that jan and kay are the two main user accounts on the server.

Phase 3: Lateral Movement & Privilege Escalation

Gaining initial access is great, but as a standard user like Jan, we have very limited power. Running sudo -l showed that Jan doesn't have any administrative rights, so we need to look around internally to see how we can move horizontally across the system.

1. Private Key Discovery

I began exploring the file system, eventually moving over to check out Kay’s home directory. There was an interesting file there named pass.bak, but trying to read it directly threw a "Permission denied" error because it belongs entirely to Kay.

However, looking closer at the file permissions across Kay’s folder using ls -la, I noticed a massive security flaw: Kay's hidden .ssh folder backup was accidentally left world-readable to anyone on the system.

Navigating into /home/kay/.ssh/ revealed Kay's private SSH identity key file (id_rsa). Because of the weak folder permissions, I could read the entire file.

I copied the entire block of text from the terminal, brought it back over to my local attacking machine, and saved it into a file named rsaid.

2. Offline Passphrase Cracking

When you look at the top of Kay’s private key, you can see it’s marked as ENCRYPTED. This means we can't use it to log in until we figure out the passphrase protecting the key. To break this open offline, I turned to the John the Ripper suite.

First, I copied the entire raw RSA private key block from the target terminal, came back to my local attacking machine, and used nano to save it into a new file named rsaid.

Before feeding it to the cracker, we have to convert this private key file into a format that John can actually parse. I ran the ssh2john tool against our rsaid file to extract the cryptographic hash and save it into hash.txt.

ssh2john rsaid > hash.txt

With the hash successfully extracted and saved into hash.txt, I launched John the Ripper against it, utilizing the standard rockyou.txt wordlist to execute an offline dictionary attack.

john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

John cracked the password in seconds, successfully recovering the passphrase: beeswax.

3. Lateral Account Pivot & Final Victory

Now we have everything we need. I updated the local file permissions on our attacker machine so SSH would accept the key (chmod 600 rsaid) and then used it to log directly into Kay's account.

chmod 600 rsaid

ssh -i rsaid kay@10.48.129.156

The login succeeded! Now running as the higher-privileged user kay, I walked right back over to the home directory and read that restricted pass.bak database file without any permission issues.

cat pass.bak

With Kay’s master system password recovered, the target machine was completely compromised!

CTF Mission accomplished!

• Types of Attacks: Brute-Force Attack, Privilege Escalation, SSH and Samba Services
• Severity Level: High

Summary

The attack started with an Nmap scan to identify active services running on the server. Next, web directory and SMB share enumeration were used to uncover critical developer notes, which revealed the target usernames and exposed a weak password vulnerability. With this information in hand, a brute-force attack using Hydra was launched to find the SSH password for the initial user. Once inside, another user’s encrypted id_rsa key was discovered due to weak folder permissions. This key was then cracked offline using John the Ripper, allowing direct SSH lateral movement to a higher-privileged account to retrieve the final master credentials.

If you found this walkthrough helpful and want to see more step-by-step CTF breakdowns, please consider giving it a like and following my profile for future articles!