Hello and thanks for joining me in the fourth (and probably final for now) series about ethical hacking with penetration testing! Before jumping in, make sure you have read the first, second and third parts of this series. Then you will be ready for today’s installment, where we are going to put on our proverbial pirate costumes and loot our exploited machine for buried treasure and other goodies!
Get a lay of the land
In our last installment, we had just compromised a machine using the Shellshock vulnerability, and were sitting at a meterpreter prompt, indicating that this machine was ripe for exploration and/or looting.
The first thing I like to do with a compromised machine is get a feel for what’s running on it, what the network configuration is like, and how I might be able to leave myself a backdoor for easier access next time. Typing help and hitting Enter is a good place to get started:
From here, lets type sysinfo and hit Enter:
Ah, interesting. So it looks like we have Linux machine here running a 3.14.1 kernel. Lets also type ipconfig to see what networks the machine is connected to:
Sometimes I’ll find a machine that is dual-homed, meaning it is connected to multiple networks. In this case, however, the machine appears to sit only on the 10.0.0/24 network.
Lets also see what local ports are running services by issuing netstat -ntlp:
Essentially, this tells us that there is a Web service running, as well as SSH, which is typically used as a command-line interface to manage the machine. Lets keep this in mind for later.
Now use the shell command so we can interact with the system directly, just like we were sitting in front of it:
Find the digital booty
One of the things I find beneficial to do from here is conduct some simple searches for files of interest. This could include Word docs and Excel spreadsheets for starters. The format for these types of searches is pretty straightforward. For example, this command will search the entire drive for all files with a .doc extension:
find / -name “*.doc”
Upon doing the search for zip files, I found one juicy result:
Now to get these files downloaded to your local machine, you have a few options. From the netstat command we used above, we know that our compromised machine is running a Web server. Therefore, it makes it very easy for me to copy this .zip file to the machine’s public Web directory, and then grab it from local Web browser. To get the file copied I issue this command:
sudo cp *.zip /var/www/
Now, I can simply open my local machine’s Web browser and visit the full path to where the file has been saved:
Great, lets pop open this file and see what’s inside…
Ah, boo! The user has put a password on this file. Well, lets use another approach.
Fire up the built-in kali tool called fcrackzip to try and brute-force the password. The specific command is:
fcrackzip bankaccount.zip
Now, for the sake of this demonstration I’m going to use a shorter word list so that the time it takes to crack the password is reduced. Kali comes with a big set of word lists you can use in /usr/share/wordlists. One of my favorite’s is called fasttrack.txt, which contains ~130 common passwords. So lets try the fcrackzip command again in conjunction with fasttrack.txt:
fcrackzip -D -p /usr/share/wordlists/fasttrack.txt bankaccount.zip
The cracker will then parse through the fasttrack.txt file and try one password at a time against our bankaccount.zip file, eventually finding a match!
(Looks like someone didn’t read FRSecure’s post on picking strong passwords!)
Leave a (back)door open
Now lets say I’ve got to shut down my local machine, but I want easier access to this compromised machine at a later date and time. One method is to install a persistent service (a.k.a a persistent back door) that tries to continually make a connection back to my machine so I don’t have to put so much work into setting up Metasploit, selecting my payload, etc.
Persistent back doors could surely be an entire topic on their own, so I am going to finish up this example in a more straightforward way. Remember earlier when we noted that the server is running the management service called SSH? If we could just figure out what the root user’s SSH password was, we could connect back to this machine at any time.
Now, we could just use the passwd command and change the password to something we know, but in a real world scenario, this might alert the system administrators to something being askew. So lets figure out what the currently set password is.
To begin, lets use the cat command to list the contents of two system files: /etc/passwd and /etc/shadow. You can read more about these files here, but essentially they work together to store information about the computer’s user accounts and encrypted password information. Using the screenshot below as reference, copy and paste the contents of these files into two separate files – I called mine passwd.txt and shadow.txt.
Next we will use the unshadow command to combine the passwd.txt and shadow.txt into a file called shadow.txt.
The shadow.txt contains a file format that a popular password-cracking utility called John the Ripper (built into Kali) can use to attempt to crack our compromised machine’s root password. To sick John the Ripper on our unshadow.txt, we run the john command and, much like with fcrackzip, use it in conjunction with a word list.
I am going to assume that the system administrator picked a tough root password, so instead of using fasttrack.txt, I’m going to use the rockyou.txt word list, which contains over 14 million passwords! (Side note: check this site for a large collection of word lists you can use.)
john –wordlist =/usr/share/wordlists/rockyou.txt unshadow.txt
Now John will begin to do its thing. You won’t see much in the way of status/progress bars, but you can hit Enter during the process to see how far along John is in chewing through the rockyou.txt file. And per the screenshot below, we can see that once again we’ve struck gold (the password is password123)!
To test these credentials, we can issue this command:
When prompted, type in password123, and viola, we’re in:
We can now come back to this machine any time we want to! We can now consider this machine ours, or, as the hacker community likes to say, pwned.
Conclusion
Ah yes, we are unfortunately at the end of this series (insert sad face here), which demonstrated some hands-on white hat hacking. I had a blast putting it together, and I certainly hope you had fun getting a peek into some of the things you might see on a penetration test.
