Basic Pentesting - TryHackMe Room

 
1.png
 

The link for this lab is located here: https://tryhackme.com/room/basicpentestingjt


In this room, we will learn about basic reconnaissance via Nmap, directory busting using Gobuster, enumeration via SMB and some password cracking techniques both online and offline.


1.jpg

Walkthrough for Beginners

The first step in any scenario is to run a port scan to determine which ports are open. This varies from person to person and is dependent upon personal preference. For me, I run two scans - one to determine open ports and one that gathers more information about the services running on those discovered ports.

The first scan I run uses the following syntax:

  • nmap -Pn -p- 10.10.115.63 -oN portscan

Where:

  • -Pn does NOT ping the host initially to see if it’s alive assuming it is a live host

  • -p- specifies all ports from 1 to 65535

  • 10.10.115.63 is the IP of the target

  • -oN portscan outputs the results to an nmap file called portscan

portscan.png

Looking at the results, we see that there are 6 ports open with some basic information like SSH, HTTP, NetBIOS. To get more information about these services and the machine itself, I run a second scan with the following syntax:

  • nmap -Pn -T4 -A -p22,80,139,445,8009,8080 10.10.115.63 -oN servicescan

Where:

  • -T4 specifies the speed (second fastest)

  • -A performs service detection, OS detection and runs some basic scripts

  • -p22,80,139,445,8009,8080 specifies the 6 ports identified before to only scan these ports

  • -oN servicescan once again outputs the results to a file called servicescan

servicescan.png

This reveals much more information including things like the version of Apache running (2.4.18). It also tells us that Samba is running for SMB, the hostname is BASIC2, it is most likely a Linux system running Ubuntu (seen in HTTP port 80 version section) and much more. I encourage you to read through and research the results yourself.

Since port 80 was identified as open, this indicates a web page is running. Navigating to the IP in a web browser reveals a very basic “under maintenance” page. This is not very useful but because it is under maintenance this indicates there may be hidden directories for when the page is fully finished. 

site.png

To identify these hidden directories, we can use a directory busting tool such as Dirbuster, Dirb or Gobuster (which I use personally). To use gobuster in in simplest form, you specify 3 things

  • what mode to run it in

  • the URL of the site

  • the wordlist to use

For this particular room I used the following gobuster syntax:

  • gobuster dir -u http://10.10.115.63 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 200

Where:

  • dir specifies directory mode (we want to hunt for hidden directories)

  • -u http://10.10.115.63 specifies the url to start trying subdirectories

  • -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt specifies the wordlist to use

  • -t 200 specifies 200 threads instead of the default (makes it go faster)

gobuster.png

After a short while, we received some results back. The first one is /development which seems interesting and the second is /server-status. The /development is a 301 which redirects - looking at the output it simply redirects to /development/ so we should be able to check it out. The /server-status returns a status code of 403 which is forbidden meaning we probably can’t navigate to it without some credentials.

So, the next step is to check out the /development page and see what’s there.

development.png

On the /development directory, we see 2 text files - dev.txt and j.txt. Opening dev.txt, we get a conversation between two people - identified as J and K. The first message indicates that Apache is set up meaning Nmap was right in identifying Apache running. The second message indicates that SMB has also been configured and the last message indicates a potential software version of 2.5.12.

The j.txt file indicates a simple message to the J user indicating that their password is incredibly weak.

j.png

Using this information, the first step I would personally take is taking a look at the SMB that was set up according to the message. To enumerate and gain information about SMB, we can use the enum4linux script built into Kali with the “-a” option which gets the userlist, sharelist, password policy information, group and member lists, enumerates via RID cycling, OS information, printer information and does an nmblookup.

Running this outputs a ton of information. I’d highly recommend reading through all of it in your own time but some of the key takeaways are the password policy section.

passwordpolicy.png

The users section is also incredibly useful as it reveals users available on the remote system for us to possibly enumerate further or bruteforce.

users.png

Remembering back the text files we uncovered we saw that J had an incredibly weak password that could be cracked easily. Tying this information to the two users we have just found - jan and kay - we can guess that “jan” is J who has the easy password to crack.

Knowing this information, we can also note that the machine had SSH port 22 open meaning the users can remotely access the machine either via a password or private key. We can potentially crack their SSH passwords and gain remote access to the machine as a user.

To do this, we can use a tool called Hydra to bruteforce the SSH port using a specified username and wordlist. We have a username called “jan” and we can use the wordlist rockyou.txt which has millions of potential passwords. The syntax for hydra looks something like this:

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

Where:

  • -l jan specifies a single user with username of jan which we found earlier

  • -P /usr/share/wordlists/rockyou.txt specifies the wordlist to use for the password

  • ssh://10.10.115.63 specifies the protocol (SSH service) and the IP of the target machine

hydra.png

After running for around 5 minutes, we got a result back that found the weak password for jan. Now that we have a password, we can try to simply SSH in to the target machine using the specified username and found password:

ssh.png

And it works. We now have remote access to the machine as the jan user. Doing some basic enumeration like listing files, moving directories and searching for hidden files, we first find a “pass.bak” file in the /home/kay directory but only the owner can read and write to it which is kay.

Next, listing all hidden files and directories, we spot a .ssh directory that normally contains SSH private keys to login remotely. It’s important to note that the file permissions on this directory allow ANY user on the system to read and execute any files in this directory.

sshdir.png

Inside this directory, there are three files that are incredibly important for SSH. The authorized_keys file specifies the SSH keys that can be used for logging into the user account for which the file is configured. The id_rsa file contains the private key for the user (should ONLY be read by the owner) and the id_rsa.pub file contains the public key which can be read by anyone.

private.png

Looking at the permissions of the id_rsa private key, we can see that ANYONE can read it which is incredibly useful. Since we can read this private key, we can simply open it, copy the contents and paste it into our own id_rsa file on our own machine which we can then use to login as kay via SSH.

To read the file, simply use the “cat id_rsa” command and copy it from the very top to the very bottom - this is important!

cat.png

Once copied, go back to your local machine and use a text editor of your use to create a new file called “id_rsa” and paste the contents into this file.

nano.png

Once created, we need to change the permissions of the id_rsa key for SSH otherwise it will produce an error about the permissions. These need to be read and write permissions for the owner ONLY and no permissions for anyone else. To achieve this, we use the “chmod 600” command 

chmod.png

Once all these steps are complete, we can use this file to login as kay. To do this, we use the “ssh -i id_rsa kay@10.10.115.63” command which uses the “-i” parameter to specify the private key file. However, using this command for this machine reveals a problem - we need to enter a passphrase.

passphrase.png

The purpose of the passphrase is usually to encrypt the private key. This makes the key file by itself useless to an attacker. However, we can try to crack this passphrase if it is a weak password. We can do this by using John the Ripper to first convert the private key to a format John can read and then cracking it.

To convert it to an appropriate format for John the Ripper, we use the “ssh2john” tool followed by the id_rsa key we created on our local machine.

ssh2john.png

The “> rsa_hash” simply takes the output of the ssh2john program and outputs it into a file to use later. Once we have this new file that John the Ripper can now read, we simply use john against this new rsa_hash file using the rockyou.txt wordlist to try and crack the password.

bees.png

After a short while, a password will be returned for the id_rsa file. We now have the passphrase for the file meaning we should be able to SSH to the target machine as kay now. Trying to SSH in once again using the previous command and entering the passphrase we just cracked, we log in to the target machine as kay.

If you remember previously, we found a pass.bak file in the /home/kay directory that was owned by kay and could only be read by them. Now that we are logged in as kay, we can read this file.

pwd.png

And we have a password - possibly for this user that is currently being used. Knowing this password, we can now check what sudo permissions kay has to see if we can elevate privileges to root.

sudol.png

When it asks for the password, simply input the long password we just found. Once ran, we can see that kay can run ALL commands as sudo. This means we can simply switch to the root user using sudo to get a root shell back. To change to the root user, simply type “sudo su” which switches to the root user by default if no user is specified.

root.png

And, as you can see, we get a root shell back. Navigating to the /root directory, we see a “flag.txt” file which is a nice message from the room creator.

Now, you have full access to the machine to do anything you want. 

I hope this walkthrough was informative and you learnt something. If you are in for a challenge, as the owner says, you can try and find a second way to gain access and to escalate privileges but I’ll leave that up to you. Thanks for reading and good luck on your journey.


Previous
Previous

Kenobi - TryHackMe Room Walkthrough

Next
Next

Vulnversity - TryHackMe Room