Learn Pentesting Basics in One Week? – Try This Challenge

To help with my Cybersecurity job search, I thought it would be interesting to see how much pentesting I can learn in a one-week period. I'll describe what I've done, starting from the basics.

I'll be using Kali Linux as my main OS, and the Offensive Security Certified Professional (OSCP) syllabus as a rough guide on how to proceed. Offensive Security is the company which makes Kali Linux (and is the "OS" in OSCP, one of the most popular pentesting industry certifications).

Eventually I'll most likely get around to doing the whole OSCP, including the exam — though that will take longer than one week.

I'll go back over most of what's on this page later, and add more detail, and probably some images and screenshots and code. I'm typing things up fast currently so as not to be spending more time on writing things up than on the actual learning exercises within this one week of pentesting practice.

Initial Notes

I'll fill in more details of this soon... This is an example of what convinced me that it would be a good idea to have a completely isolated home lab to practice pentesting with (rather than just using virtual machines running within my usual daily OS):

From this page on security.stackexchange I found what seems like a really good example of how a malicious program running inside a virtual machine (VM) can escape from the VM to do things in the host OS. The whole idea of a VM is that this is supposed to be impossible, yet of course in practice, almost nothing is really impossible.

The page linked above mentions and quotes from this article, as below. The quote begins near the end of page 5:

VI. VIRTUAL MACHINE ESCAPE

The reprogrammability of the iSight [webcam] firmware can be exploited to effect a virtual machine escape whereby malware running in a guest operating system is able to escape the confines of the virtual machine and influence the host operating system.

One method is to reprogram the iSight from inside the virtual machine to act as a USB Human Interface Device (HID) such as a mouse or keyboard. Once the iSight reenumerates, it would send mouse movements and clicks or key presses which the host operating system would then interpret as actions from the user.

To demonstrate the feasibility of a virtual machine escape from a VirtualBox virtual machine, we implemented...

Basically, the iSight webcam is reconfigured by the malicious code in the VM to make the system think it's really a physical keyboard. Then the VM sends fake keystrokes to the keyboard and the host OS interprets these as if a real user had typed them on the host OS (not in the VM)!

The article goes on to describe them testing this out, and getting a terminal window on the host OS (which could then be used, for example, to download malicious code using the wget command, and then execute it on the host OS).

Day Zero: The First Evening

When I decided to try something like this (learning as much pentesting as I can in a week), it was afternoon. I looked at a few links and web pages, and decided the OSCP syllabus would be a good plan to roughly follow. I read a bit about the OSCP on the Offensive Security website.

Then I had a look on YouTube. I watched this video, which seems really good, and thorough. It goes for 1h50m, but only the first 1h15m is the actual video itself, and the rest is a question-and-answer session where he answers a series of questions that people have messaged in. You can also download all the slides he uses as a PDF file from his GitHub page.

In the video, Adithyan AK describes his method of study for the OSCP, over three months. He also gives lots of links to other resources, some of which I'll be using during this week.

His method was to initially learn all the theory, taking really good notes, and then move on to practical pentesting exercises. If I was doing this over a longer period (like 3 months, or even 1 month) I would follow this style.

However, given that my current "mission" is to learn as much as I can in one week, I'll adopt a different approach. Which is to spend a minimal amount of time reviewing theory, and over-viewing different tools within Kali, and then jump straight in to practical pentesting exercises.

Adithyan AK says that his method of tackling the exercises (e.g. those on VulnHub, which I will also be using) was to begin by going to his notes (from his theory part of the training), and going over all the possible things he'd noted down which might work to find a vulnerability into the system currently being attempted to penetrate. Then, if none of those worked, he would use the advice/hints provided on VulnHub.

I'll do something like this also, except that I haven't already spent 1-2 months studying all the techniques in the OSCP syllabus. Which means I expect I will end up going to the hints quicker than otherwise. I don't think this is a massive problem, since that's when most of the actual learning will happen. That is, from being faced with an actual "How can I hack into this system?" situation, and then learning whatever new technique is needed to actually do it. This then will go onto my own list of things to try on each new system I try to hack/penetrate/exploit.

If I keep doing this enough, I will learn a lot of different techniques.

I also watched this video which is shorter (16 minutes), and gives a really good overview of how to exploit a file upload feature on a web page in order to upload your own malicious code, which can then be run on the web server to gain shell (command prompt) access to it (and then run your own commands on the web server).

Day One: Basic/Preliminary Setting Things Up

After deciding to try this, and then getting some idea of what to try (as above), the next question was what to use to try this all on. That is, what actual system of mine I can use (hardware and software).

The advice on VulnHub is to not use your main computer, or any computer which has private data on it, or anything you care too much about possibly being compromised. Since you're going to be installing and running virtual operating systems which are uploaded by anyone (they are not officially verified or anything), and they are deliberatelly full of security vulnerabilities, and made by people with hacking/systems-penetration skills — it would not be a huge stretch of the imagination that some of them might contain actually malicious code, which might try to attack the host system of the person running the VM.

It's possible using VirtualBox to keep the settings very tight, not allowing any shared folders (or shared clipboard, or shared anything much) between the host OS and the VM. And to use an "Internal Network" for the networking option, which means that the VM can only access other VMs also running in VirtualBox with the same Internal Network name. This effectively does create a completely isolated network — at least in theory. In practice (as described earlier on this page) it is possible (although difficult) for malicious code in a VM to escape the container and attack the host operating system.

This means that it is a really good idea if you can create a totally isolated physical "lab" which has no access to any of your usual devices which have private data (like your passwords and other important private info) on them.

What I decided to do was buy a new hard drive for an 18-month-old laptop, and then take out the existing Windows 10 hard drive (SSD), and put in the new empty one, and install Kali Linux on that as the main OS. Then, later, when I want to use the laptop again with Windows 10 I can replace the original hard drive (SSD).

This is something I would recommend but only if you're comfortable with swapping around hardware parts. Or maybe, if you have an older machine that doesn't hugely matter if you do something really wrong. There are plenty of YouTube videos and web pages about how to swap hard drives of all differernt types on all different machines. You can also probably download the service manual for your machine (I did that) which will probably be very helpful.

Other than that, it would be possible to buy a new machine, or a second hand one (even a cheap one) and use that for your home pentesting lab, so that you don't have to worry about anything private being compromised. Also, if you have an older computer sitting around at home, not being used, that might work well for this. Linux is much lighter on system resources than Windows is, so a computer that's too old to run a current version of Windows very well (or at all) may run Linux really well. I've got a Lenovo R61 laptop from about 2007 or 2008, which has been upgraded to the maximum specs for pretty much everything in it, and it runs Kali Linux really well (though not as well as an 18-month old machine of course), it's still quite usable though.

If you don't have anything that you consider that private on any machine you have, you might consider that it's okay (as in worth the security risk) just to do everything on that machine, and use the Internal Network option for the VMs. It does seem unlikely that malicious code in a VM can escape from the VM and attack your host OS, but it is definitely possible.

Day Two: Setting Up My Pentesting Lab Machine

I put in my new SSD "hard drive", it was easy enough to install. I'd opened the back of the machine before, to add some RAM, so I'd already opened the case on this particular machine before, which always helps. With this machine, the hardest part of opening the case is that (after unscrewing the 9 screws on the back cover), you have to carefully unclip all around the edges. You can hear them "snap" out when done correctly. I used my thumbnail though (esp if you don't have very strong thumbnails) it would also be possible to use one of those plastic levers which are specially made for this task. Something metal (like a bread and butter knife) would work to open it, but would be likely to scratch something, and may even cut something inside that you don't want cut, especially if you slipped even the tiniest bit. I wouldn't recommend using a knife for this. A guitar pick might work. If you want to try this, and are even the tiniest bit unsure of how to do it, I would very highly recommend looking for a YouTube video and/or a web page with descriptions and pictures, about how to open and change the drive in your model of machine.

Then I made a bootable USB "stick" flash drive with the Kali Linux installer on it, using the program Rufus in Windows, as described on the Kali website. Note that in Rufus, you do need to make the bootable USB drive with the option as recommended on the Kali page, which is the opposite of the one that Rufus recommends that you choose (which doesn't work for installing Kali — it will boot, but not get past the first few questions, and then it gets stuck on not being able to find a hard drive to install Kali onto, even though there is one there).

Then, I tried to boot it in my laptop. This was the tricky part...

The laptop (a Lenovo L380 Yoga) really seemed to not want any OS to be installed on it other than Windows. The problem was the "Secure Boot" option in the BIOS settings, which requires that any files the computer boots from are digitally signed by a vendor which the computer already recognises as valid (i.e. Microsoft). The problem with this was that every time I tried to change the Secure Boot setting to disabled, it would just re-enable itself immediately when I tried to "Save Settings and Reboot" the machine.

It took about 3-4 hours to figure out how to disable the Secure Boot setting. First, there was an extra option in a different menu to always revert a shortlist of BIOS settings to their defaults (including the Secure Boot setting to on) no matter what they were actually set to. Once I found that setting, I thought it would all be good. But, no. Still no dice.

Then, I discovered that the BIOS menu I got when I tried to boot the computer, and failed (because it couldn't find any operating system it was satisfied with, i.e. was digitally signed and officially recognised), looked identical to the real BIOS setup menu, but it was some kind of one-time temporary thing which did not remember many of the setting changes. The way to solve this problem was to power cycle (i.e. turn off and then on) the machine, and then go into the BIOS setup before it got up to trying to boot anything. This BIOS menu looks identical to the other one, but this was the one which worked properly. And in this one, when I disabled enough of the Secure Boot settings and also the extra settings to not re-enable the Secure Boot, then it finally booted from the USB drive into the Kali Linux installation.

After that, everything went smoothly.

So then I installed Kali as the main OS onto the new hard drive, and updated everything in Kali, and changed the root password to something other than the default.

Then I installed VirtualBox onto the Kali OS, and then another copy of Kali (from an .ova VM image file this time) to run within VirtualBox as a VM. This copy of Kali I also updated everything on, with the Network Adapter set to NAT. Then, I changed the Network Adapter to "Internal Network", which is the setting it will be on when I'm using it as a virtual hacking/pentesting lab.

Now I am all ready to install other VMs onto my new OS to practice hacking into them...

Day Three: First Experiments with Hacking Unknown VMs

This is going to be roughy the plan (I'm not sure in what order yet — probably a random mix of whatever I feel like at the time):

• Revise basic Unix/Linux commands, especially those mentioned in the OSCP syllabus which I haven't used for a while and/or aren't very familiar with.
• Have a look at more levels of the OverTheWire Bandit Wargame.
• Load up at least one VM from VulnHub and have a go at hacking into it.
• Make some more notes in general, and plan out what I think is the best material to focus on for the next 3-4 days.

First, I thought it would be a good idea to make a list of Linux commands to revise and/or learn:

An internet search for most useful kali linux commands gives mostly pages with basic/generic Unix/Linux commands, which you would need to know to be able to do much in Linux. Commands like ls, cd, mkdir, cp, mv, rm, chmod, chown, cat, whoami, pwd, users, uname, uptime, date, cal, history, echo, clear, more, less, free, df (dh -h is a good option for df,which will tell you in "human" readable units how much disk space you have left).

Nearly all the commands will give you help information if you type the name of the command followed by --help (there is a space after the name of the command, and then there are two dashes and no space before the word help). Also most of them have "manual" pages which are even longer, and more detailed, and can be accessed by typing man [name_of_command].

The editors that get mentioned the most are vi, nano, and leafpad. I really like the editor gedit, though I think this is not installed by default on Kali (it's easy to install though). The editor gedit does automatic code colouring based on the file extension, so it's good for writing code in if you just want to do something quicklly and don't want to use a fully featured developer's IDE. You can customise and add other code colouring features for any languages that aren't supported by default (e.g. assembly language).

Also there are commands to work with your Linux system (e.g. to update it and install and uninstall packages) like apt, apt-get, dpkg. The command apt is a newer command similar to apt-get. The apt command has less options and functionality than apt-get, but is meant to be better to use for basic tasks like installing things and upgrading your system. This web page gives a good table (if you scroll a bit past halfway down the page) showing the equivalent comands in each, e.g. for it you're used to using apt-get (like I am) and want to learn the equivalent commands using apt.

The next tier of commands would be ones like sort, grep, awk,

There are networking commands, such as ifconfig, tcpconfig, tcpdump,

Note that many of the packages below which are mentioned as not being installed by default on Kali, you can easily install just by typing the command (at the Kali shell command prompt), and then Kali will ask you if you want to install it, and install it for you just like that.

Commands with a & character after them are GUI-based commands, and if you type the & it will free up you terminal window for further use (rather than hogging it until the GUI command's window is closed).

Then there are the security/pentesting-specific and Kali-specific commands (many of which may be more often referred to as "tools" than commands). Ones like nmap, masscan, fierce, netcat, macchanger, burpsuite & (GUI-based, it has free and paid options, it does a lot of different things), wireshark, metasploit, aircrack-ng, john (i.e. "John the Ripper"), sqlmap, autopsy, setoolkit, lynis, wpscan, hydra, hash-identifier, skipfish, kismet, nikto, maltego & (not open source and needs to be signed into with an account, either free or paid. It's a GUI (graphical/window based command. Typing maltego in the command prompt will pop up a window asking you which version you want, even the free version still requires you to sign up for an account with them.), nessus (not installed by default on Kali and maybe not free), beef (not installed by default in Kali anymore though it can easily be installed), Apktool (not installed by default on Kali), snort (not installed by default on Kali and possibly somewhat hard to install), king-phisher (not installed by default on Kali but easy to install), yersinia (not installed by default on Kali but easy to install), openvas (not installed by default on Kali but easy to install), cmsmap (not installed by default in Kali), fluxion (not installed by default in Kali), rcrack (not installed by default on Kali but easy to install), dhcpig (not installed by default on Kali but easy to install), fl-record (FunkLoad, not installed by default on Kali), slowhttptest (not installed by default on Kali but easy to install), inundator (older package, not currently part of Kali), findmyhash (older package, not installed by default on Kali anymore), t50 (not installed by default on Kali but easy to install), firewalk (not installed by default on Kali but easy to install).

Many of the above security-specific commands are described in a more detail here, and here, and here. Each of them has a lot of functionality, and can be used in a basic way, and in many different more advanced ways. So it's possible to learn a little about each one, and then later go back and learn more.

Preparing to Hack a VM from VulnHub

I'm using the advice on this page (which has two more further pages following it, the link to each next page is at the end of the pages). I've already done everything on the first page except for installing the DHCP server on the Internal Network. I was wondering if I'd have to manually configure the IP addresses on the Internal Network (since I read that they don't have a DHCP server, which is the system that automatically assigns IP addresses when machines connect to the network). This (using a DHCP server on my Internal Network in VirtualBox) would be better as it would only need to be done once, and not for every new VM I install from VulnHub.

The command to activate the DHCP server (typed, or copied and pasted, into the command prompt on Linux) is:

vboxmanage dhcpserver add --network=intnet --server-ip=10.10.10.1 --netmask=255.255.255.0 --lower-ip=10.10.10.2 --upper-ip=10.10.10.12 --enable

Where "intnet" is whatever name your Internal Network is given in the VirtualBox Manager. (The default name is "intnet").

Note that the above command has a different syntax to the one on the web page linked to above. Perhaps their one is for a different operating system (e.g. Windows) as a host for the VMs. I am using a Kali Linux host for VirtualBox (and also another installation of Kali as a VM inside VirtualBox).

After running the above command, when I boot my Kali VM on the Internal Network, and type ifconfig into the shell prompt (a.k.a command prompt), it shows two entries for it, a localhost (127.0.0.1) entry, and another IP on the 10.0.0.0 network, with an IP of 10.0.0.2, which was presumably not there before (I forgot to look) and has been added by the DHCP server that was just enabled on this network.

Downloading VMs from VulnHub

The first VM I downloaded from VulnHub is called Noob 1, and the filename is Noob.ova. I thought a VM called "Noob" sounded like a good one to start with.

Then, while waiting for it to download (it was slow and took almost an hour), I found another beginner one on VulnHub from a Google search, which is this one, I'll download that next, and use the two of them for my initial systems penetration attempts. The second VM is from a Google drive and is downloading much faster, about 10MB/sec as compared to about 0.4MB/sec for the Noob one. This one will take about 5 minutes to download the 2.6GB of .ova file.

This second VM (as above) is called "Basic Pentesting 1" and it looks like it's popular, since there are several web pages and even at least one YouTube video giving a walkthrough of how to exploit it.

I imported the two VMs as above into VirtualBox (click on "File" in the top menu, then "Import Applicance"). The only things I then changed in the settings for each was the name (I gave them more meaningful names than the default ones), and the Network setting to Internal Network.

I still havent booted any of the new vulnerable VMs yet.

Next, I temporarily changed the Network settings for my Kali VM back to NAT so it could access the internet, then booted Kali again in the VM, updated everything again, shut it down, changed the network settings back to Internal Network, and then made a snapshot image of it (so I can revert it later on if I want to do that for any reason).

The next thing to do will be to boot up my Kali VM (which I'll be doing the pentesting/"attacking" from), and one of the new vulnerable VMs, and try to see what I can do with it...

More coming soon...

Coming Soon

During the rest of the week, I spend most of my time learning and doing the exercises, rather than writing them up (which slows things down a lot). I took a lot of handwritten notes, which I'll add to this page as I get around to it.

I began work as a Risk Analyst at the start of February 2022, which took up much of my time during February and early March. I should be able to get back to updating this page and the rest of this website soon...

Cover image by Shutterstock.

Share This Page

If you liked this page, please share it with others! You can use the links to share on Facebook, Twitter, LinkedIn, Pinterest, and Email. Ther is also an RSS feed to get updates for the website.