TryHackMe — Basic Pentesting

Overview

Platform: TryHackMe
Room: Basic Pentesting
Difficulty: Easy
Category: Web Exploitation / Privilege Escalation
OS: Linux

TryHackMe’s Basic Pentesting room is designed to walk beginners through a complete attack chain from initial reconnaissance to root. It’s not a trick box — the vulnerabilities are intentional and well-documented. The value isn’t in the difficulty, it’s in practicing the discipline of methodical enumeration before touching an exploit.

This write-up covers the full path to root: network scanning, web directory enumeration, credential discovery, SSH access, and privilege escalation via a misconfigured sudo permission. Every step is documented with the reasoning behind it, not just the commands.

Note: TryHackMe rooms are intentionally vulnerable machines hosted in a sandboxed environment. Never run these techniques against systems you don’t own or have explicit permission to test.

Methodology

The approach here follows a simple loop:

1. Enumerate — find every open door before trying to walk through any of them
2. Research — understand what’s running and what’s known about it
3. Exploit — use the simplest reliable path, not the flashiest one
4. Document — write down what worked and what didn’t

Skipping step 1 is the most common beginner mistake. Rushing to exploit before fully enumerating means missing easier paths that were right there.

Reconnaissance

Network Scan

Start with an Nmap scan to identify open ports and services. The -sV flag requests version detection; -sC runs default scripts; -oN saves output to a file for reference.

nmap -sV -sC -oN basic_pentest.nmap <TARGET_IP>

Results:

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu
80/tcp open  http    Apache httpd 2.4.18
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X
445/tcp open  netbios-ssn Samba smbd 4.3.11

Four ports open: SSH, HTTP, and two Samba ports. HTTP is the obvious first target — web services are almost always the entry point on beginner boxes. Note the Samba ports for later; SMB shares sometimes contain credentials or sensitive files.

Web Enumeration

Navigating to http://<TARGET_IP> in the browser shows a basic Apache default page with some placeholder content. Nothing immediately useful — the interesting content is almost never at the root on a CTF box.

Run Gobuster to brute-force directories using a standard wordlist:

gobuster dir -u http://<TARGET_IP> -w /usr/share/wordlists/dirb/common.txt -o gobuster.txt

Results:

/development  (Status: 301)
/secret       (Status: 301)

Two directories. Check both.

/development contains a text file with a note between two developers discussing SSH access and a weak password being used temporarily. The note references a username: jan.

/secret contains another note referencing a second user: kay, and hints that they have sudo access.

Two usernames and a hint about a weak password. That’s enough to move forward.

Initial Access

SSH Brute Force

With a username (jan) and the knowledge that the password is weak, a dictionary attack against SSH is the logical next step. Hydra handles this efficiently:

hydra -l jan -P /usr/share/wordlists/rockyou.txt ssh://<TARGET_IP>

Hydra iterates through the rockyou wordlist against the SSH service. On a beginner box with a deliberately weak password this typically completes within a few minutes.

Result: Password found. SSH access gained as jan.

ssh jan@<TARGET_IP>

We’re on the box. Run a quick check to establish context:

whoami      # jan
id          # uid=1001(jan) gid=1001(jan) groups=1001(jan)
ls /home    # jan  kay

Two home directories match the two usernames from the web enumeration. The goal is to get to kay, who has sudo access.

Lateral Movement

SSH Key Discovery

Before trying anything complex, check what’s readable from jan’s account:

ls -la /home/jan
ls -la /home/kay

The /home/kay directory contains a .ssh folder with an id_rsa private key file — and it’s world-readable. This is the misconfiguration being demonstrated here: private keys should never be readable by other users.

Copy the key to your attacking machine:

# On the target, print the key
cat /home/kay/.ssh/id_rsa

Copy the output, paste it into a local file (kay_id_rsa), and set the correct permissions:

chmod 600 kay_id_rsa

Cracking the Key Passphrase

The key is passphrase-protected. Use ssh2john to convert it to a format John the Ripper can attack, then crack it:

ssh2john kay_id_rsa > kay_hash.txt
john kay_hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Result: Passphrase cracked.

Now SSH in as kay using the key:

ssh -i kay_id_rsa kay@<TARGET_IP>

We’re now operating as kay.

Privilege Escalation

Sudo Enumeration

The first thing to check on any Linux box after gaining a new user is what sudo permissions are available:

sudo -l

Result:

User kay may run the following commands on this host:
    (ALL) NOPASSWD: /usr/bin/vim

kay can run vim as root with no password required. This is a classic GTFOBins misconfiguration — many text editors can be abused to spawn a shell when run with elevated privileges.

Shell Escape via Vim

sudo vim -c ':!/bin/bash'

The -c flag passes a command to vim at startup. :! runs a shell command from within vim. Since vim was launched as root, the spawned shell inherits root privileges.

whoami   # root

Root achieved.

Flags

cat /home/kay/flag.txt   # user flag
cat /root/flag.txt       # root flag

Key Takeaways

Enumerate before you exploit. Both usernames and the weak password hint came from web directory enumeration. Skipping Gobuster would have left the only obvious entry point undiscovered.

Check file permissions on private keys. A world-readable id_rsa file is an immediate critical finding in a real assessment. Private key material should be 600 (owner read/write only) and should never be stored in a location accessible by other users.

GTFOBins is your friend. Any time a sudo permission allows running a text editor, compiler, or interpreter, check gtfobins.github.io — the escape technique is almost always documented there.

Weak passwords + exposed services = breach. SSH brute force only worked because the password was in rockyou.txt. Public-facing SSH should use key-based authentication only, with password authentication disabled entirely.

Tools Used

References

• TryHackMe — Basic Pentesting Room
• GTFOBins — vim
• ssh2john documentation
• Hydra documentation