We closed Module 6 with an idea: once you have mastered the method, it is time to master the tools that make it possible. Throughout the authorized audit against TechNova S.L. we relied on a full arsenal: Nmap for scanning, Metasploit for exploitation, Burp and sqlmap against the store tienda.technova.lab, linpeas and proxychains in post-exploitation. We used them almost in passing, focused on the method. This module comes back to that toolkit to master it in depth, and the natural starting point is the working environment where it all lives: the pentester's distribution.

This lesson is about Kali Linux: what it is and what the alternatives are (Parrot), how to install it (virtual machine, live USB, WSL), how its tools are organized by category, and, most important for your learning, how to build a legal and isolated lab where you can practice everything you have learned without ever touching systems that are not yours. We finish with best practices (snapshots, updates, operational hygiene) and your first commands. Everything you do here must mirror the ethical framework of the course: authorized targets only, and in your lab that target is yourself.

1. What Kali Linux is and why it exists
2. Alternatives: Parrot and others
3. Installation options (VM, live, WSL, bare metal)
4. Building a legal and isolated lab
5. Tool organization by category
6. First commands and customization
7. Best practices and operational hygiene
8. Common Mistakes and Tips
9. Exercises
10. Conclusion

Kali Linux is a Debian-based distribution, maintained by OffSec (formerly Offensive Security), built from the ground up for penetration testing and security audits. Its value is not "a Linux with lots of programs installed": it is that it gathers, preinstalls, and keeps up to date a coherent set of offensive tools, with dependencies resolved and versions that work together.

• Single focus: the whole system is geared toward auditing; it is not a general-purpose desktop.
• Its own repositories: the kali-rolling repository brings security tools that are always current.
• Cross-platform: it runs on VMs, bare metal, ARM (Raspberry Pi), WSL, containers, and in the cloud.
• Rolling-release model: it updates continuously instead of through annual versions.

Kali does not turn you into a pentester and it does not "hack" anything for you: it is a toolbox. The skill lives in the person, and so does legitimate use: installing Kali does not authorize you to attack anything.

Kali is the de facto standard, but not the only one. The best-known alternative is Parrot Security OS, also Debian-based and with a very similar philosophy.

Other niche options: BlackArch (Arch-based, thousands of packages, for advanced users) or defensive distributions such as Security Onion (no longer offensive, but blue team oriented). For this course we will use Kali because it is the best documented, but everything you learn carries over to Parrot with almost no changes.

Defensive angle: knowing these distros also helps the blue team. The same scanners the attacker uses, the defender uses to audit themselves first.

There are several ways to run Kali. The choice depends on what you want it for.

To get started, the virtual machine is by far the best decision: it gives you isolation, snapshots (point-in-time captures of the state you can roll back to), and the ability to run the attacking machine and the victim on the same virtual network at once. OffSec even publishes ready-made VM/VMware images for you to import.

Integrity check: always download from kali.org and verify the SHA-256 hash before using the image.

Verifying the hash prevents you from using a tampered image: a compromised security tool is a dangerous contradiction.

This is the heart of the lesson. You never practice pentesting against systems that are not yours. Scanning or exploiting a machine without written authorization is a crime in most jurisdictions, even if you are "just testing." The right way to practice is to build your own isolated lab where you own every machine, attacker and victim alike.

Minimum architecture of a home lab:

Keys to a safe setup:

• Host-only network (or internal network): connects the VMs to each other but isolates them from your home network and the Internet. That way a deliberately vulnerable victim machine is never exposed. In VirtualBox: Host-Only or Internal Network adapter; in VMware: Host-only.
• Legal victim machines built for this: Metasploitable 2/3, DVWA, OWASP Juice Shop, VulnHub VMs. They are intentionally vulnerable, and their license allows you to attack them.
• Snapshots before touching anything: take a capture of each freshly installed VM so you can revert after breaking it.
• No accidental dual homing: check that the victim VM does not also have a NAT adapter that takes it out to the Internet.

In this lab you can reproduce the entire TechNova audit: stand up a vulnerable PHP/MySQL store, scan it with Nmap, exploit it with sqlmap/Metasploit, and practice post-exploitation, exactly as we did in Modules 2 through 5, but against machines that are yours.

Kali groups its tools into a menu organized by phase, which maps almost 1:1 to the pentest phases we studied in Module 1.

You do not need to know all 600+ tools: mastering one or two per category covers 90% of the work. The rest of Module 7 digs into the main ones (Metasploit, Burp, ZAP).

After booting Kali for the first time, the first thing to do is update and get your bearings.

Explanation:

• apt update && apt full-upgrade syncs the repositories and updates; on a rolling release you should do this regularly.
• ip a gives you Kali's IP inside the isolated network: you will need it to configure attacks (LHOST in Metasploit, for example).
• searchsploit queries the local Exploit-DB database offline, ideal in a lab with no Internet.

Useful customization from the start:

• Non-root user: since 2020 Kali uses a normal user by default (kali). Work that way and use sudo when needed; always operating as root is a bad habit.
• zsh and aliases: Kali ships with zsh configured; add aliases in ~/.zshrc for your frequent commands.
• Extra tools: install anything missing with sudo apt install <tool>.

• Snapshots before every session. It is what separates "I roll back in 10 seconds" from "I reinstall for two hours."
• Do not use Kali as your daily OS. It is hardened for security tools, not for browsing, online banking, or personal email. Use it as a dedicated working environment, ideally in a VM.
• Keep it updated, but do not update in the middle of a critical engagement without a prior snapshot: a rolling release can break a tool.
• Always isolate the lab. Double-check that the network is host-only before powering on a deliberately vulnerable VM.
• Document your lab (IPs, credentials, purpose of each VM) just as you would in a real engagement: it is the best way to internalize the method from Module 6.

• Practicing against real targets "just to test." It is illegal even if you cause no harm. Build your own lab: it is the only ethical and legal path.
• A victim with Internet access. A vulnerable VM with a NAT adapter can be exposed or compromised by third parties. Use a host-only network and verify it.
• Always working as root. It breaks things and builds dangerous habits. Use the kali user and sudo.
• Not taking snapshots. You break a VM and lose hours reinstalling. Capture the clean state before touching anything.
• Downloading Kali from unofficial sources. Verify the SHA-256 from kali.org; a tampered security tool is a Trojan horse.
• Tip: treat your lab like a mini TechNova engagement. Naming the machines, documenting, and reporting your practice turns play into professional training.

Exercise 1. Design on paper an isolated lab to reproduce the TechNova audit. State which VMs you would include (attacker and at least two victims), what kind of virtual network you would use and why, and what you would do before you start attacking.

Exercise 2. You have just installed Kali on a VM. Write the sequence of commands to: (a) update the system, (b) find out Kali's IP on the host-only network, and (c) search locally for an exploit for the vsftpd 2.3.4 service. Explain what each one is for.

Exercise 3. A colleague says they are going to "practice Nmap" by scanning the WiFi network at their usual coffee shop. Explain why this is a bad idea and propose a legal alternative that gives them the same practice.

Solution 1. I would include three VMs: Kali (attacker) and two legal, deliberately vulnerable victims. For example DVWA/Juice Shop to play the role of TechNova's PHP/MySQL web store, and Metasploitable or a vulnerable Windows VM for the system/internal-network role. All connected to a host-only (or internal) network with no access to the Internet or my home network, so the vulnerable machines are never exposed and never affect third parties. Before attacking: check that no victim has a NAT adapter, note each machine's IP, and take a snapshot of the clean state of all of them so I can revert.

Solution 2.

apt update/full-upgrade keeps Kali and its tools current; ip a gives me the IP I will use as LHOST/source in my attacks inside the lab; searchsploit checks offline whether there is a known exploit for that service (there is: the famous vsftpd 2.3.4 backdoor).

Solution 3. Scanning the coffee shop's network is unauthorized access/analysis: even if it causes no harm, in most jurisdictions it is illegal and a violation of that network's policy. The alternative: build a host-only lab on their own machine with a Kali VM and one or more vulnerable VMs (Metasploitable, VulnHub). They get exactly the same Nmap practice (discovering hosts, ports, and services) but against machines that are theirs, with no legal or ethical risk.

Kali Linux is the working environment where the whole arsenal we used throughout the TechNova audit lives. In this lesson we saw what it is and why it exists, its main alternative (Parrot), the ways to install it (with the virtual machine as the best option for learning), and, above all, how to build a legal and isolated lab with a host-only network and deliberately vulnerable victim machines, the only ethical way to practice. We reviewed how tools are organized by category (a mirror of the course phases), the first commands, customization, and best practices: snapshots, not using Kali as a daily OS, and keeping it updated.

With the environment set up and isolated, you now have somewhere to practice without touching systems that are not yours. In the next lesson we open the first major tool in that toolkit, and the one we used most in exploiting TechNova: the Metasploit Framework, which we will study in depth from its architecture to its responsible workflow.