Basic Pentesting — TryHackMe

Introduction

Hello everyone! 👋

Welcome back to another story and another journey with me.

Today, I’m going to share my experience solving the Basic Pentesting room on TryHackMe.

This room is a great exercise for practicing some important penetration-testing basics, especially enumeration, SMB, brute-force attacks, SSH, and private-key cracking.

I already solved the room, but I wanted to go back and explain how I solved it, step by step.

Maybe it will be useful for someone else, or maybe for me in the future.

So, let’s break it down.

Room Link

https://tryhackme.com/room/basicpentestingjt

Question 1 — Find the services exposed by the machine

The first question was straightforward:

Find the services exposed by the machine.

The first thing I did was run an Nmap scan:

nmap <ip-target>

Nmap scans the target and tells us which ports are open and which services may be running on them.

After running the scan, I could see several services exposed by the machine.

And that’s it for the first question.

Let’s move on.

Question 2 — Find the hidden directory

The next question asked:

What is the name of the hidden directory on the web server?

For this one, I used a hint from TryHackMe, which suggested using Dirsearch.

Dirsearch is a tool used to discover directories and files on web servers by trying different paths from a wordlist.

I ran:

dirsearch -u http://<ip-target>

After the scan finished, I found a directory:

/development/

So the answer was:

development

Another question completed.

Question 3 — Finding the SMB Share

The next step was to investigate the SMB service.

I used:

smbclient -L <ip-target>

The -L option tells smbclient to list the available SMB shares.

The scan revealed an Anonymous share.

That immediately caught my attention because an anonymous share may allow us to access files without providing a username and password.

So I connected to it:

smbclient //10.112.167.252/Anonymous -N

The -N option tells smbclient not to ask for a password.

Once I entered the share, I could interact with the files inside it.

Question 4 — Finding the Username

Now the question was:

What is the username?

The first thing I did was list the files inside the SMB share:

ls

I found an interesting file.

So I downloaded it to my Kali machine using:

get <file-name>

Then I opened it:

cat <file-name>

The file contained some useful information.

Among the information I found were two usernames:

jan
kay

At this point, I had two possible usernames.

The room then asked me to identify the correct username, so I tested jan.

And it was correct. ✅

Now I had a username to work with.

The next question was:

How can I find Jan’s password?

Question 5 — Finding the Password

Now I went back to the Nmap results.

The machine had several open ports, including SSH:

2/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-proxy

Since we already discovered the username jan, SSH became an interesting service to investigate.

One possible approach in a controlled lab environment is password auditing using tools such as Hydra or Medusa.

1. Hydra

I used Hydra with the username jan and the rockyou.txt wordlist:

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

Let’s break it down:

• -l jan → use jan as the username.
• -P → specify a password wordlist.
• /usr/share/wordlists/rockyou.txt → the wordlist being tested.
• ssh:// → target the SSH service.

Hydra then tested passwords from the wordlist against the SSH service.

Eventually, it found valid credentials.

But I didn’t want to stop with one tool.

So I tried another approach.

2. Medusa

The second tool I used was Medusa:

medusa -h <ip-target> -u jan -P /usr/share/wordlists/rockyou.txt -M ssh

Here:

• -h → target host.
• -u jan → username.
• -P → password wordlist.
• -M ssh → use the SSH module.

I also used a higher task/concurrency setting in the lab.

For example:

-t 10

means Medusa can process up to 10 login attempts concurrently, rather than processing only one at a time.

This can make the attack faster, but the actual speed depends on the target, network, service configuration, and tool behavior. It does not simply mean “10 times faster.”

The password was:

armando

So now we had:

Username: jan
Password: armando

And we could move forward.

Question 6 — What service do you use to access the server?

The question asked:

What service do you use to access the server?

We already identified SSH during the Nmap scan.

SSH stands for:

Secure Shell

The required answer was:

SSH

Simple enough.

Let’s continue.

Question 7 — Enumerating the Machine

Now the room wanted us to enumerate the machine and look for possible privilege-escalation paths.

After logging in as jan, I started checking the system.

One useful file to inspect is:

cat /etc/passwd

This file contains information about local user accounts.

After checking it, I found another interesting user.

And that leads directly to the next question.

Question 8 — Finding the Other User

The question asked:

What is the name of the other user you found?

From /etc/passwd, I identified another user:

kay

So now I knew there were at least two interesting accounts:

jan
kay

But I was currently logged in as jan.

So the next question became:

How can I access Kay's account?

Question 9 — Finding the Final Password

This was the most interesting part of the room for me.

At this point, I had access as jan, but I needed to find a way to access kay.

I started by looking around the user’s directories.

I eventually checked:

cd /home/kay

Then:

ls

There was an interesting file, but when I tried to access it, I didn’t have the required permissions.

So I needed to investigate further.

I remembered that SSH can use private keys instead of passwords.

That made me think:

Maybe Kay has an SSH private key.

And that’s exactly what I looked for.

Finding Kay’s SSH Private Key

Inside Kay’s home directory, I used:

ls -la

The -a option is important because it shows hidden files and directories.

And there it was:

.ssh

That was a very interesting discovery.

Get Enghellomahmoudanter’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

So I entered the directory and listed its contents:

cd .ssh
ls -la

I found:

id_rsa

This is commonly used as the filename for an SSH private key.

I inspected the file and confirmed that it contained a private-key format.

This was a major discovery.

Copying the Private Key

I copied the private key to my Kali machine and saved it as:

pk

Before using an SSH private key, its permissions need to be restrictive.

For example:

chmod 600 pk

This means the owner can read and write the file, while other users don’t have access to it.

Then I tried to connect:

ssh -i pk kay@<ip-target>

But I encountered another problem.

The private key itself was protected by a passphrase.

So I couldn’t simply use it.

Now I had another challenge:

How can I recover the passphrase protecting the private key?

Converting the SSH Key for John the Ripper

This is where John the Ripper came in.

John cannot directly work with every SSH private-key format.

Kali includes a utility called:

ssh2john

Its job is to extract the relevant authentication information from the SSH private key and convert it into a format that John can process.

On Kali, I found it under the John installation directory.

The general syntax is:

ssh2john <private-key-file> > <output-file>

For example:

sudo /usr/share/john/ssh2john pk > hash.txt

Now I had:

pk

→ the original SSH private key

and:

hash.txt

→ the converted representation that John can process.

So lets start crack that hash and here we hve to ways:

1. john the ripper
2. hashcat

So lets break down every method to see how we will find out the password for the PK of kay.

note: in both ways i will use rockyou.txt as a wordlist.

Cracking the SSH Key Passphrase with John

Now I could use John with the rockyou.txt wordlist:

john --wordlist=/usr/share/wordlists/rockyou.txt /home/mahmoud/hash.txt

John started testing passwords from the wordlist against the extracted SSH-key data.

Eventually, it recovered the passphrase.

That gave me what I needed to use Kay’s private key.

But I wanted to try the same task using another tool too.

Cracking the SSH Key with Hashcat

I also wanted to understand how Hashcat handles the same type of SSH-key hash.

The hash produced by ssh2john contains additional information, including a prefix such as:

$sshng$...

For the Hashcat method I used in this lab, I extracted the part after the delimiter.

I used:

cut -d: -f2 hash.txt > sshng.txt

Let's break this down.

cut

cut is a Linux command used to extract specific parts, or fields, from text.

-d:

The -d option specifies the delimiter.

Here, the delimiter is:

:

-f2

This tells cut to take the second field.

So conceptually:

field1:field2

becomes:

field2

Finally:

> sshng.txt

redirects the result into a new file called:

sshng.txt

So now I had a cleaned file ready for my Hashcat command.

Hashcat

For this SSH private-key format, I used Hashcat mode:

22931

Then:

hashcat -m 22931 -a 0 sshng.txt /usr/share/wordlists/rockyou.txt

Breaking it down:

• -m 22931 → select the SSH private-key hash mode.
• -a 0 → dictionary attack.
• sshng.txt → the hash input.
• rockyou.txt → the password wordlist.

After Hashcat finished, I could display the recovered password using:

hashcat -m 22931 sshng.txt --show

And there it was.

The passphrase for Kay’s private key had been recovered.

so lets continoue solving last question in the room.

Finally Accessing Kay

Now I had everything I needed:

• Kay’s username
• Kay’s private SSH key
• The passphrase for the key

So I tried SSH again:

ssh -i pk kay@<ip-target>

This time, I successfully authenticated as Kay.

🎉

I finally had access to Kay’s account.

Finding the Final Password

After logging in as Kay, I listed the files:

ls

I found the file:

pass.bak

So I read it:

cat pass.bak

And finally, I found the password the room was asking for.

That completed the final question.

then….

So I read it:

cat pass.bak

And finally, I found the password the room was asking for.

That completed the final question.

What I Learned

This room taught me several useful concepts that I can carry into future labs.

1. Directory Enumeration

I learned how tools like Dirsearch can help discover hidden directories on a web server:

dirsearch -u http://<ip-target>

2. SMB Enumeration

I practiced discovering and accessing SMB shares with:

smbclient -L <ip-target>

and:

smbclient //<ip-target>/Anonymous -N

3. SSH Private Keys

I learned that SSH authentication doesn’t always require a password.

A private key can be used for authentication:

ssh -i pk kay@<ip-target>

4. ssh2john

I learned how ssh2john converts an SSH private key into data that John the Ripper can process:

ssh2john pk > hash.txt

5. Linux cut

I also learned how cut can extract fields from structured text:

cut -d: -f2 hash.txt > sshng.txt

6. John vs Hashcat

I practiced recovering an SSH-key passphrase using both:

• John the Ripper
• Hashcat

This helped me understand that different tools may require the input data to be prepared differently.

Attack Path

Looking back at the whole room, the journey was:

Nmap
  ↓
Service Enumeration
  ↓
Web Directory Enumeration
  ↓
SMB Enumeration
  ↓
Anonymous Share
  ↓
Discover Usernames
  ↓
SSH Password Attack
  ↓
Access as Jan
  ↓
Enumerate Users
  ↓
Discover Kay
  ↓
Find .ssh/id_rsa
  ↓
Extract SSH Key Information
  ↓
John / Hashcat
  ↓
Recover Key Passphrase
  ↓
SSH as Kay
  ↓
Read pass.bak
  ↓
Final Password

What I liked about this room is that every step gave me information for the next step.

It wasn’t about running one magic command.

It was about:

enumerating → discovering → understanding → testing → moving forward.

Conclusion

It was a really nice room for practicing the basics of penetration testing.

I learned several new things, especially directory enumeration, SMB shares, SSH private keys, ssh2john, John the Ripper, Hashcat, and Linux text-processing commands.

I also learned something important about cybersecurity labs:

Sometimes the answer is not directly in front of you.

You need to collect small pieces of information and connect them together.

That’s what makes these rooms interesting for me.

I hope you enjoyed this journey as much as I did.

Maybe this write-up will be useful for someone else, or maybe for me in the future when I need to remember how I solved it.

See you in another story and another journey. 🔐🐧

Thanks for reading.

Goodbye! 👋