Basic Penetration Testing
Last updated
Last updated
URL -->
Target URL will change as I had to restart the machine. It will most likely change for you so make sure you use the one given to you by THM.
Start by running a basic nmap scan to see what services are available.
Looks like quite a few services are open. I'll save a more detailed scan for later if needed.
Looks like from before, Port 80 is open which is usually an indicator that a web server is running and may be accessed from your browser. Let's check that out.
Nothing of note on the web server page. Check the source code as well to see if there are any comments with important information.
Doesn't look like anything to note except a hint if we need help.
Since we have a web server available, let's run gobuster to see if we can discover some subdomains.
Any page with a 403 code is forbidden to access.
/index.html is the home page that is under development so that isn't helpful.
That leaves us with the /development subdomain which redirects to http://[Target URL]/development/
Looks like we have access to some .txt files that may be helpful.
So it looks like we know the following:
SMB has been configured.
Should look for a possible exploitation here.
They are using version 2.5.12 of something.
This note indicates they may be using an older version which may have a vulnerability we can exploit.
We'll run a more detailed nmap scan to see if we can identify what services and versions they are running.
Looks like there are some credentials on the /etc/shadows directory that are hashed but pretty easy to break.
Once I gain access, I should check this directory.
It looks like we have two potential users --> J & K.
I'm assuming these are short for first names.
Base on the information they are giving me, I'm going to start by taking a look at the SMB service running. I'll start by checking to see what shares may be accessible.
Looks like there is an anonymous share available. Let's try accessing that.
Hit enter when prompted for a password.
Looks like the we have access. I typed in the command ls to see what is available. There is a staff.txt file in the current directory. Download the file to your host machine to see.
Seems harmless enough but I now know what J & K stand for.
Possible usernames include Jan and Kay.
It doesn't look like we have access to any other part of the system from this share.
Exploring the file directory from the previous task gives us some good information.
Based on file from the previous task we know there is probably a username of either Jan or Kay.
We won't be able to brute force the smb server (I tried) but let's instead try the ssh service since we know that service is open. Let's use Hydra to try to brute force Jan's account. Based on one of the previous text files we found, we know it's probably a good chance that they have a pretty basic password that can be found easily.
This will take a while but eventually should kick back a valid password.
Note: you don't have to use the -V flag. I just like to see something that says it is still working.
Based on the previous task it is SSH.
Using the credentials jan:armando, login to the SSH service using:
You should now have access to the users account. Let's browse around a bit to see what we can do.
Looks like there is a possible password backup file in /home/kay that cannot be accessed.
Digging around the same directory we can find some other files:
Looks like there is some good info in the hidden .ssh directory.
From here I can get the private and public keys for SSH.
Private key:
The public key is:
I tried logging into the Kay's account with the private key. I saved the private key on my host machine under a new file called id_rsa.pem
This is the typical naming convention for a private key.
Unfortunately, it then asks me for a passphrase. I tried using the phrase at the end of the public key but no luck.
Let's use johntheripper to try to get the passphrase from the key.
Start by converting the private key to a readable file.
Then we can run this through John The Ripper with the rockyou passwords list to see if we can get something.
This kicks out a phrase of "beeswax"
Now I'll try ssh'ing back into kay's account and input that passphrase.
After you put in the passphrase "beeswax" you should now have access to kay's account.
Take a look at the pass.bak file in their home directory.
heresareallystrongpasswordthatfollowsthepasswordpolicy$$
LinPeas
I decided to also run linpeas to see what it would pull up.
Download linpeas
On the host machine, start up a python web server in the directory that has linpeas downloaded.
On the target machine download and run the file:
Scanning through the output two things pop up:
The machine has a vulnerability that allows privilege escalation
Vulnerable to CVE-2021-4034
I'm pretty sure this is just a vulnerability. I was trying to get an exploit for it to work but wasn't successful.
The scan also revealed the private keys we found before on kay's directory.
Based on previous enumerations, we also discovered a user Kay.
A lot
heresareallystrongpasswordthatfollowsthepasswordpolicy$$
Download to convert the rsa key to a readable file to crack. There are a lot of these for other hash types.
