Getting your first pentesting build up and running
A brief definition of Cybersecurity:
Cybersecurity, from a raw, simple viewpoint is just one’s ability to keep computer systems safe. An event during which a computer system is compromised is referred to as a security incident. Conceptually, incidents can be examined from three different perspectives:
• Offense (red team) – when the examiner’s aim is to cause incidents by finding and exploiting system vulnerabilities.
• Defense (blue team) – when the examiner focuses on preventing incidents by designing and deploying fixes and patches, as well as implementing remediation and mitigation strategies for system vulnerabilities and security risks.
• Forensics – when the examiner aims to understand an incident and its timeline in the aftermath of a successful attack by collecting and analyzing the artifacts left behind.
5 rules of thumb to keep in mind when pentesting:
1) When pentesting, one becomes both hunter and prey.
Pentesting isn’t a risk-free activity, even when doing it in sand-boxed and controlled environments. Just to name a few of these risks, it is quite frequent to end up visiting questionable websites, executing dangerous scripts, accidentally using infected binaries downloaded from who-knows-where in the internet, or just bricking your system and/or your target.
2) Mindset over skill set.
Cybersecurity is about learning how systems work and how they break rather than using guides and running a few commands to breach a target.
3) Chase the rabbit down the hole.
It is important to turn off the autopilot and read through the entire article or guide to fully understand it before issuing any terminal commands. Try different approaches, research, and ask your peers about problems you are working on. It is also important to fully analyze scripts, and if possible, disassemble binaries before execution. Develop a healthy habit to read through all the gibberish console output, search the internet and design your own testing methodologies.
4) Free your system.
Pentesting requires a high degree of accessibility and control over the system you are using. Commercial systems are not usually designed for this purpose, and many necessary features might be blocked or capped.
5) Split your profile, isolate your resources.
Splitting profiles and isolating computer resources help keeping things safe. It is not a good idea to pentest with the same computer and account that are used to access online bank accounts. Just saying.
Pentesting build:
In this section, we are discussing a pentesting build example that satisfies the aforementioned rules of thumb and explaining the reasons to have it this way. However, feel free and welcome to choose any other builds, contest the proposed one and elevate different recommendations.
Basic build:
Dedicated i7, 16Gb RAM, 512Gb SSD; 120Gb external SSD, 4Gb flash drive.
Host OS: Debian (for stability) or Void/Arch (for upstream packages) running Mate, KVM and Qemu (type 1 hypervisor).
Guest OS: kali 2022 (4 cores, 8+ Gb RAM).
For the most part, a normal computer should be powerful enough to perform most of the activities discussed here. A machine with 4 to 8 cores, 8 to 16 Gb of RAM and a decent size SSD should suffice. The only hard requirement for this build is the motherboard must support hardware virtualization (Intel VT-x or AMD-v in BIOS).
A USB flash drive with a capacity bigger than 4Gb and an external hard drive are also necessary. The first one will be used to burn images (usually under 4Gb), and the later to save notes, binaries, scripts, etc. which are no pre-bundled in Kali (the OS we’ll use to pentest), as well as larger forensics images.
Using cutting edge tech and commercial hardware, such as Apple computers, might not be a good choice because a huge portion (if not all) of the system drivers are privative (not open source). This means there are not well documented ways of taking control and interacting with the hardware, and hence, some techniques/activities are capped in these devices (for example, setting the wifi card to promiscuous mode).
The reason for choosing Linux both as the host and guest operating systems is that Linux is free software (free as in free speech, as well as in free beer). This means we will have complete control over the operating systems and any software packages we install and use to the extent of being able to modify the code and recompile it for our specific needs.
In our case, we are leveraging Linux virtualization capabilities to host our pentesting environments. This way we can run both our offensive and target virtual machines (VM) on the same hardware, while sandboxing any dangerous software in virtual containers (each VM is isolated from other system resources).
KVM+Qemu is considered a type 1 hypervisor, meaning the VMs have direct hardware access through the host’s kernel (giving us an edge in efficiency over type 2 hypervisors like VirtualBox, which emulate the VM hardware).
There are multiple Linux distributions and flavors out there in which the aforementioned pentesting environments can be built, and it’s a good idea to try a few before sticking to one, or several. A good reason, though, to use Debian with MATE desktop environment is it strikes a good balance between resource consumption, system stability, security and flexibility.
Kali Linux is basically Debian backports pre-bundled with tons of pentesting apps and resources, such as scripts, wordlists, etc. This distro is developed and maintained by Offensive Security, the Berkeley-based company which issues the OSCP certification.
Creating a Linux installation flash drive
Debian’s latest image can be downloaded from one of the following mirrors:
https://www.debian.org/CD/
To ease and speed up the process, use the following link to download a Debian image (ISO file):
http://mirrors.ocf.berkeley.
These are the OSX terminal commands to download and verify the image. Using wget:
$wget -c
-c → continue downloading partial file |
Using curl:
$curl -C – -L -O
-C -→ continue at offset – → continue downloading partial file -L → follows links -O → write output file same as input file (name) |
For example:
$ cd ~/Downloads
$ curl C – -L -O https://cdimage.debian.org/
$ curl C – -L -O https://cdimage.debian.org/
Or in OSX:
$ brew install coreutils → installs sha256sum
$ sha256sum debian-11.4.0-amd64-DVD-1.iso
This last command (sha256sum) checksums the downloaded ISO image and returns the computed result. This result should be listed in the downloaded SHA256SUMS file. If the calculated checksum matches the related sha256sum in the file list, we say the downloaded file is verified, meaning that we have the same image as the publisher (note that this does not guarantee the publisher published a secure image!).
Then, insert your 4Gb flash drive and get the device file associated to it:
In linux:
[$] fdisk -l
Linux output example:
Disk /dev/sda: 29.8 GiB, 32017047552 bytes, 62533296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dosDisk identifier: 0x9364fd51
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 58593279 58591232 28G 83 Linux
/dev/sda2 58593280 62531583 3938304 1.9G 82 Linux swap / Solaris
In OSX:
$ diskutil list
OSX output example:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
[…]
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
[…]
In this case (assuming OSX), the device file associated with the flash drive is /dev/disk2. Then, burn the image to the flash drive and boot to it:
[$] dd if=/path/to/image of=/path/to/device/file
For example:
[$] dd if=~/Downloads/firmware-11.4.
Once these steps have been completed , we have a bootable flash drive and are ready to start the installation.
dd is a utility to convert and copy files bit by bit. |
Host OS installation (Debian):
Installing Debian is a straight forward task using the graphical installer we just burnt to the flash drive. Boot to the flash drive and follow the installation prompts carefully. A couple notes:
Modern Linux systems do not need 2xRAM swap partitions.
Consider activating disk encryption with LVM (the installer provided with a guided option).
Consider separating the /home folder in a different partition (it makes it much easier to repair the OS if it breaks, and recover data if it can’t be repaired).
When installing the software package sets, only “system tools” (or the like), and one desktop environment (gnome, mate, lxfe …) are needed (SSH and spool servers are not needed).
Once upon a time, getting Linux running and installed in a computer was an engineering feat in itself. In those times, the deployment was made manually from a minimal OS build with terminal booted from a CD or even a floppy disk. I will be providing with an additional guide to install Arch using a netinstall image with terminal in a different article. A really educational experience, like in the good old times.
Debian nuances:
1) Standard users do not belong to the sudoers group in Debian. In fact, sudo is not even installed by default. In order to access files and execute commands with superuser privileges, it is necessary to log as root:
$su
In this guides, commands executed with superuser privileges will be preceded by one of these prefixes:
[$] or root@debian$ or sudo
2) Debian does not include sbin directories in the system path by default (system path $PATH is a system variable that tells Debian where to find utilities invoked using terminal). That can be changed by issuing the following command:
[$]export PATH=”/usr/local/bin:/usr/bin:
Adding basic repositories:
Debian and Debian-based distros use apt as its package manager. Software packages are retrieved from repositories, whose remote addresses are stored in /etc/apt/sources.list. In order to add new repositories, you have to edit that file:
Use a text editor with superuser privileges to change the sources:
[$]nano /etc/apt/sources.list
Comment all the lines and add the following one:
deb http://security.debian.org/
#deb-src http://security.debian.org/
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
#deb-src http://deb.debian.org/debian/ bullseye-updates main contrib
deb http://ftp.debian.org/debian bullseye main contrib non-free
#deb-src http://ftp.debian.org/debian bullseye main contrib non-free
– “Main” software packages fully comply with the Debian Free Software guidelines. – “Contrib” software packages comply with the Debian Free Software guidelines, but not their dependencies. – “Non free” software packages do not comply with the Debian Free Software guidelines. – “deb-src” allows us to download a package source code and compile it. |
Update your software list and upgrade your system:
[$] apt-get update && apt-get upgrade -y && apt-get autoremove && apt-get autoclean
Update → updates the version list of installed software packages and compares with the repositories upgrade -y →forces (-y) upgrade of all packages whose version is inferior to those in the repositories autoremove → uninstalls all unused packages autoclean → uninstalls all old version packages |
Additional protection:
Antivirus:
If an antivirus is required, ClamAV can be installed in the system (with a GUI). It is not the best option out there, but it offers an extra layer of protection:
[$] apt-get install clamav clamav-daemon
[$] apt-get install clamtk
ClamAV automatically checks for virus definition updates every hour, though this can be changed in /etc/clamav/freshclam.conf. To perform a system or folder scan we can either use the GUI or run the following command in terminal:
$clamscan -ri /path/to/directory >> /path/to/log file
Clamscan is the command to invoke the antivirus scan. Option -r means recursively (all subfolders) while -i means “print infected files only”). >> /path/to/log file → dump the output of the previous command in /path/to/log file |
Rootkit hunter:
A rootkit is a fake replica of a legit program or application which has been installed in the system to alter its normal behavior. An example would be a rootkit of “ls” command so that we cannot list a particular file. In some cases, it is useful to have a rootkit scanner installed in the system.
$sudo apt-get install rkhunter
$sudo rkhunter –popupd
$sudo rkhunter -c –enable all –disable none
$rkhunter –popupd -c –popupd → updates rootkit database -c → performs a system check with the enabled tests – enable all – disable none → perform all available rootkit tests |
Rkhunter’s log file can be found in /var/log/rkhunter.log
Hypervisor and first VM:
Finally, we are going to install the hypervisor and enable the service in systemd:
[$]apt-get install qemu-kvm libvirt-clients libvirt-daemon-system bridge-utils virtinst libvirt-daemon
[$]sudo systemctl enable –now libvirtd
Find the image manager in the app menu, and you are now ready to create your first KVM VM.
Creating a VM is quite easy, you’ll just need to download the latest Kali image and point to it in the installer.