Introduction

This write-up documents my approach to solving the Basic Pentesting room on TryHackMe — a beginner-friendly challenge that walks through a realistic attack chain: from initial enumeration to gaining root access through credential discovery, brute forcing, and SSH key mismanagement.

What makes this room valuable from a security perspective is how closely it mirrors real-world scenarios that SOC analysts encounter in alerts every day: exposed SMB shares leaking usernames, brute-forceable SSH services with no rate limiting, and improperly stored SSH private keys that enable lateral movement. These aren't theoretical risks — they're the exact misconfigurations that lead to breaches in production environments.

Phase 1: Enumeration

Every engagement starts with understanding the attack surface. I ran a full port scan using Nmap with the -p- flag to ensure nothing was missed beyond the default top 1000 ports.

nmap -sC -sV -p- <TARGET_IP>

Open ports discovered:

• 22, SSH OpenSSH 8.2p1 Ubuntu 4ubuntu0.13
• 80, HTTP Apache httpd 2.4.41 (Ubuntu)
• 139, NetBIOS/SMB Samba smbd 4.6.2
• 445, SMB Samba smbd 4.6.2
• 8009, AJP Apache Jserv Protocol v1.3
• 8080, HTTP Apache Tomcat 9.0.7

Ports 139 and 445 running Samba immediately stood out. SMB is historically one of the most exploited services — from EternalBlue (MS17–010) to pass-the-hash attacks. Even without known CVEs, SMB enumeration often reveals usernames, shares, and domain information.

Port 80 running Apache and port 8080 running Tomcat gave me two web surfaces to explore. Port 8009 (AJP) is worth noting — the Ghostcat vulnerability (CVE-2020–1938) targets this protocol, though it wasn't the intended path here.

With six ports open, I needed to prioritize. Web services (80/8080) are quick to enumerate for directories, while SMB (139/445) often leaks information passively. I decided to start with web enumeration on port 80, then pivot to SMB.

Phase 2: Web Enumeration (Port 80)

I ran directory brute-forcing against the Apache server on port 80:

dirsearch -u http://<TARGET_IP>

This revealed a single interesting directory: /development.

Inside /development, I found two text files:

dev.txt. A note between developers discussing the need to improve security and referencing ongoing work.

j.txt. Another developer note that mentioned using SMB for file sharing and hinted at weak credentials.

The notes confirmed that SMB was actively being used. This made SMB enumeration the clear next step, the developers themselves told me where to look.

Security Issue #1: Internal developer notes were publicly accessible via the web server with no authentication. In a production environment, this is an information disclosure vulnerability. These notes revealed infrastructure details (SMB usage) and usernames that directly aided the attack. Developer notes, README files, and internal documentation should never be served on public-facing web servers.

Phase 3: SMB Enumeration and Credential Discovery

Based on the intelligence gathered from the web server, I targeted SMB for user enumeration using enum4linux:

enum4linux -A <TARGET_IP>

The -A flag runs all enumeration options (shares, users, groups, and domain information). From the results, I extracted two valid usernames:

• jan
• kay

Security Issue #2: The SMB service was configured to allow anonymous enumeration of user accounts. This is equivalent to handing an attacker a guest list — they no longer need to guess who exists on the system, only what their passwords are. SMB should be configured to reject anonymous access and restrict enumeration to authenticated users only.

With two valid usernames in hand, the question became which account is more likely to have a weak password? Going back to the developer notes from Phase 2, j.txt specifically called out that Jan had a weak password and needed to change it. This is a strong indicator. When a colleague openly acknowledges someone's password is weak, it almost certainly hasn't been fixed yet. So while I included both usernames in the brute force for thoroughness, Jan was the primary target.

I used Hydra to brute-force SSH credentials:

hydra -L users.txt -P /usr/share/wordlists/rockyou.txt ssh://<TARGET_IP> -V

Where users.txt contained both discovered usernames. The -V flag enabled verbose output, showing each combination as it was tested.

Result: Hydra successfully cracked Jan's password: armando.

Security Issue #3: SSH was brute-forceable because there was no rate limiting, account lockout policy, or fail2ban configuration in place. In a production environment, Hydra would have been blocked after a handful of failed attempts. The use of a weak, dictionary-based password (armando is in rockyou.txt) made the attack trivial.

Phase 4: Initial Foothold: SSH as Jan

With valid credentials, I logged in via SSH:

ssh jan@<TARGET_IP>

Login successful. I now had a shell as a low-privilege user. The first thing I did was enumerate the system for lateral movement opportunities.

With this command below

cat /etc/passwd | grep home

It confirmed the existence of another user kay. I explored Kay's home directory and discovered something critical.

ls -la /home/kay/.ssh/

Inside Kay's .ssh directory, I found an id_rsa file — Kay's private SSH key and it was readable by Jan.

Security Issue #4: A user's private SSH key was stored with improper file permissions, allowing other users on the system to read it. SSH private keys should always have 600 permissions (owner read/write only). This single misconfiguration enabled complete lateral movement without needing Kay's password. In real-world incidents, compromised SSH keys are one of the most common vectors for lateral movement within a network.

Phase 5: Lateral Movement (To kay)

I copied Kay's private key to my attacking machine and saved it as rsa_id. The key was passphrase-protected, so I needed to crack it before it could be used.

First, I converted the key to a crackable hash format using ssh2john a utility from John the Ripper that extracts the passphrase hash from an SSH private key file.

ssh2john rsa_id > hash.txt

Then I cracked the hash using John the Ripper with the rockyou wordlist.

john kay_hash.txt — wordlist=/usr/share/wordlists/rockyou.txt

Result: The passphrase was cracked: beeswax.

SSH enforces strict permission checks on key files. If a private key is readable by other users, SSH will refuse to use it. I set the correct permissions before logging in.

chmod 600 id_rsa

After changing the permission, now i can login as kay.

ssh -i id_rsa kay@<TARGET_IP>

Security Issue #5: The SSH key passphrase was weak and dictionary-based. Passphrases on SSH keys serve as a second layer of defense. If the key is compromised (as it was here), a strong passphrase would prevent its use. A passphrase like beeswax can be cracked in seconds.

Phase 6: Privilege Escalation (To Root)

With access as Kay, I checked for privilege escalation vectors. The flag was accessible from Kay's account, completing the challenge. However, in a real engagement, the next step would be checking sudo -l, SUID binaries, cron jobs, and kernel version for escalation paths.

cat /home/kay/pass.bak

Blue Team Perspective

This is where I want to bridge the gap between offensive and defensive security. This is what i think a blue team would flag.

1. Information Disclosure

Vulnerability scanners (Nikto, OWASP ZAP) would catch publicly accessible directories like /development. Prevention: restrict access via web server config and never store internal notes on public-facing servers.

2. SMB Anonymous Enumeration

A SIEM rule matching anonymous SMB sessions with user enumeration queries would catch this. Prevention: set restrict anonymous = 2 in Samba config, and firewall SMB off from external networks entirely.

3. SSH Brute Force

Auth logs (/var/log/auth.log) would show hundreds of failed logins from a single IP. SIEM rule: "5+ failed SSH logins from same source IP within 60 seconds." Prevention: deploy fail2ban, disable password auth, and restrict login accounts via AllowUsers.

4. Lateral Movement via SSH Keys

File integrity monitoring (FIM) on .ssh directories would detect unauthorized reads. EDR should alert on ssh2john or john execution. Prevention: enforce chmod 700 on .ssh and chmod 600 on private keys, and audit permissions regularly.

This write-up is part of my ongoing series documenting TryHackMe challenges as I build my portfolio in cybersecurity — approached from a Blue Team and SOC analyst perspective.

Thanks for reading! If you found this helpful, feel free to give it a clap and follow for more cybersecurity and tech content.