Learn Ethical Hacking series):Exercise 1 -- Colonial Pipeline attack chain:
The Colonial Pipeline attack (May 2021) began when the DarkSide ransomware group obtained credentials for a legacy VPN account that lacked multi-factor authentication. Using this single compromised password, attackers accessed Colonial's IT network, deployed ransomware that encrypted billing and business systems, and demanded $4.4 million in Bitcoin. Colonial shut down the pipeline as a precaution (unable to bill customers), causing fuel shortages across the US East Coast for six days. The attack could have been stopped at Kill Chain Stage 1 (Recon) by disabling unused VPN accounts, at Stage 3 (Delivery) by requiring MFA on all remote access, or at Stage 5 (Installation) with endpoint detection that flags ransomware encryption behavior.
The key insight: MFA on a single VPN account would have prevented a $4.4 million ransom and six days of fuel shortages for 50 million people.
Exercise 2 -- Passive recon example:
Results vary by target, but a typical passive recon of a mid-size company reveals:
Target: Acme Corp (fictional example)
1. Job posting on LinkedIn: "Senior Django Developer" -> uses Python/Django
2. DNS MX records: mx1.google.com -> uses Google Workspace for email
3. Login page HTML source: <meta name="generator" content="WordPress 6.4">
4. Employee on LinkedIn: "Jan de Vries - IT Manager at Acme Corp"
5. Shodan search: 203.0.113.42 running nginx/1.24.0, OpenSSH 8.9
The key insight: you didn't touch any Acme Corp system, but you already know their web framework, email provider, CMS version, an IT employee's name, and a server's software versions. An attacker uses this to craft targeted phishing (mentioning Django to Jan), exploit known WordPress vulnerabilities, or target the specific nginx version.
Exercise 3 -- CFAA analysis:
1. Port scanning (Nmap) -- CFAA 1030(a)(2): "intentionally accesses a computer
without authorization." Authorization: written scope document from client
explicitly listing IP ranges approved for scanning.
2. SQL injection testing -- CFAA 1030(a)(5): "knowingly causes the transmission
of a program, information, code, or command, and... intentionally causes
damage." Authorization: bug bounty program scope explicitly including
the web application's database-backed endpoints.
3. Password hash cracking -- CFAA 1030(a)(6): "knowingly and with intent to
defraud traffics in any password." Authorization: engagement contract
specifying credential testing as in-scope, with captured hashes from
authorized systems only.
The key insight: the CFAA is broad enough that almost any unauthorized interaction with a computer could technically be prosecuted. Written scope documents and bug bounty safe harbors are not optional -- they're your legal shield.
Before we touch a single vulnerability, before we write a single exploit, before we even think about scanning anything -- we need a lab. A controlled environment where we can break things freely, learn from the breakage, and never, ever accidentally cause harm to real systems.
This is non-negotiable. Professional pentesters don't practice on production systems. Neither do we.
I've seen people (aspiring security researchers, no less) fire up Nmap against random IP ranges "just to see what happens." That's not curiosity, that's recklessness -- and depending on your jurisdiction, it's potentially a federal crime. As we discussed in episode 1, authorization is everything. Your own lab gives you that authorization by default, because you own every machine in it.
Everything we do in this series happens inside virtual machines (VMs). The concept is simple: your real computer (the host) runs software that creates fake computers (the guests). Each guest has its own operating system, its own network interfaces, its own filesystem. And critically: what happens inside a VM stays inside that VM.
If you mess up an exploit and crash the target? Restore from a snapshot in 30 seconds. If malware escapes in a lab exercise? It hits the VM boundary and stops. If you accidentally misconfigure something catastrophically? Delete the VM and start over. No harm done.
The beauty of virtualization for security work is that it gives you infinite do-overs. In the real world, if you accidentally drop a production database during a pentest (it happens, more often than anyone admits), there are phone calls, incident reports, possibly lawyers. In your lab? You click "Restore Snapshot" and pretend it never happened ;-)
We'll use VirtualBox (free, cross-platform, works everywhere) or UTM (if you're on Apple Silicon -- VirtualBox on M-series Macs is... niet zo geweldig let's say).
Our lab has three components:
+-------------------+ +-------------------+ +-------------------+
| ATTACKER VM | | TARGET VM(s) | | HOST MACHINE |
| (Kali Linux) |<--->| (Metasploitable, | | (your real OS) |
| | | DVWA, custom) | | |
| Python, Zig, | | | | VirtualBox/UTM |
| Nmap, Burp, | | Intentionally | | manages all VMs |
| Metasploit, etc | | vulnerable! | | |
+-------------------+ +-------------------+ +-------------------+
| |
+-------[ISOLATED]--------+
Internal network ONLY
(no route to internet/host)
The attacker VM runs Kali Linux -- a Debian-based distribution specifically designed for penetration testing. It comes pre-loaded with hundreds of security tools. The target VMs are intentionally vulnerable systems designed for practice.
The critical part: the network isolation. We put attacker and target on an internal-only virtual network. No connection to your host machine's real network. No connection to the internet. Nothing leaves the sandbox.
Why is isolation so important? Because the tools we'll be using -- port scanners, exploit frameworks, password crackers -- don't care about your intentions. Nmap will happily scan your ISP's infrastructure if you point it that way. Metasploit will cheerfully try to exploit your neighbor's router. The tools are amoral. You set the boundaries by controlling the network.
There's also a practical reason: reproducibility. When you're learning, you want to be able to run the same attack three times and get the same result. On a live network, traffic changes, services restart, firewalls update rules. In your lab, the target is frozen in time (thanks to snapshots) and the network is predictable. That consistency is worth its weight in gold when you're trying to understand why an exploit works, not just that it works.
Download and install VirtualBox from virtualbox.org (or UTM from mac.getutm.app for Apple Silicon).
First, create the isolated network. In VirtualBox:
vboxnet0)192.168.56.1192.168.56.100192.168.56.200Every VM in our lab will use Host-Only Adapter on this network. No NAT, no bridged -- host-only means the VMs can talk to each other but NOT to the outside world.
(When you specifically need internet access to download something into a VM, temporarily add a second NAT adapter, do your download, then remove it. Don't leave it connected. I mean it -- remove it right after. A lab with internet access is not a lab, it's a liability.)
Download the pre-built Kali Linux VirtualBox image from kali.org/get-kali -- the "Virtual Machines" tab. It's about 3-4 GB.
Import it into VirtualBox:
.ova filevboxnet0)kali / kaliFirst thing after login -- change the password:
passwd
Yes, I know this seems obvious. But the number of people running Kali with default credentials on a network-connected machine is... alarming. Change it.
Now let's verify our tools are present. Open a terminal and run:
# Check key tools
which nmap && echo "nmap: OK"
which msfconsole && echo "metasploit: OK"
which burpsuite && echo "burp: OK"
which sqlmap && echo "sqlmap: OK"
which hydra && echo "hydra: OK"
which john && echo "john: OK"
which hashcat && echo "hashcat: OK"
python3 --version
All of those should be pre-installed. Kali comes with over 600 security tools organized into categories: information gathering, vulnerability analysis, web application testing, password attacks, wireless attacks, exploitation tools, sniffing/spoofing, post-exploitation, forensics, and more. We won't use all 600 (nobody does), but having them available means we never need to hunt for tooling mid-exercise.
A quick note on Kali vs. other distros: you can install all these tools on a standard Ubuntu or Arch box. Kali is just convenience -- everything pre-configured, pre-patched, and organized in the application menu by attack category. Some people prefer Parrot OS (lighter weight, same tools). Either works. I use Kali because that's what most training materials and certifications expect, and when you follow online tutorials they'll assume Kali paths and configurations.
Now add our familiar tools. Since you've been following my other series, let's make ourselves at home:
# Python virtual environment for our custom scripts
python3 -m venv ~/pentest-venv
source ~/pentest-venv/bin/activate
pip install requests beautifulsoup4 paramiko scapy pwntools
# Verify
python3 -c "import requests, bs4, paramiko, scapy; print('All good')"
For Zig (because we'll write low-level security tools later in the series -- buffer overflow exploits, custom network scanners, things where Python is too slow and you need to touch memory directly):
# Download Zig (check ziglang.org for latest URL)
cd /tmp
wget https://ziglang.org/download/0.13.0/zig-linux-x86_64-0.13.0.tar.xz
tar xf zig-linux-x86_64-0.13.0.tar.xz
sudo mv zig-linux-x86_64-0.13.0 /opt/zig
echo 'export PATH=$PATH:/opt/zig' >> ~/.bashrc
source ~/.bashrc
zig version
Metasploitable 2 is a deliberately vulnerable Ubuntu virtual machine maintained by Rapid7 (the makers of Metasploit). It runs outdated services with known vulnerabilities -- perfect for learning.
And when I say "vulnerable," I mean comically vulnerable. It's running services from the mid-2000s with configurations that would make any sysadmin cry. Open Telnet, anonymous FTP, unpatched Samba, a MySQL instance with no root password... it's a greatest hits album of everything you should never do in production. Which is exactly what makes it perfect for us.
Download it from sourceforge.net/projects/metasploitable. It's a .vmdk (VMware disk) file, but VirtualBox reads those just fine.
Create a new VM in VirtualBox:
.vmdkvboxnet0)msfadmin / msfadminCheck its IP:
ifconfig
# Look for the inet addr on eth0, probably 192.168.56.10x
From your Kali VM, verify connectivity:
ping 192.168.56.101 # use whatever IP Metasploitable got
If you get ping responses, your lab network is working. The two VMs can see each other, and neither can reach the internet. Perfect.
Damn Vulnerable Web Application (DVWA) is a PHP/MySQL web application specifically designed to practice web attacks -- SQL injection, XSS, CSRF, file inclusion, command injection, and more. It has adjustable security levels (low, medium, high, impossible) so you can gradually increase difficulty.
This is going to be our bread and butter for quite some episodes. When we get to web application attacks (and we will spend a LOT of time on web attacks, because that's where the money is in modern security), DVWA will be the primary playground.
The easiest way to run DVWA is with Docker. On your Kali VM (temporarily add a NAT adapter for internet access):
sudo apt update && sudo apt install -y docker.io
sudo systemctl start docker
sudo docker pull vulnerables/web-dvwa
sudo docker run -d -p 80:80 vulnerables/web-dvwa
Now remove the NAT adapter (back to host-only only). Open Firefox in Kali and navigate to http://localhost/. You should see the DVWA login page. Default credentials: admin / password.
Click "Create / Reset Database" on the setup page, then log in. You now have a web application with every common web vulnerability at your fingertips.
One thing worth mentioning: DVWA's security levels are genuinely well-designed. Low security has zero protections -- raw, exploitable code with no input validation. Medium adds basic filters that are trivial to bypass (and teaches you how real-world "security" often works -- half-measures that look protective but aren't). High requires actual technique and creativity to break. Impossible shows the correct implementation. Always study the "Impossible" source code after you've cracked "Low" through "High" -- it shows you what the fix looks like.
This is the most important habit in lab work: snapshot your clean states.
In VirtualBox, for each VM:
Now you have a restore point. After every major exercise, take another snapshot. If you break something (and you will), restoring takes seconds.
Get in the habit of naming snapshots descriptively:
- "Clean Install"
- "Post-Episode-3 - Network scanning complete"
- "Post-Episode-7 - Password cracking tools installed"
- "BROKEN - don't use - crashed during buffer overflow"
That last one is not a joke. You WILL crash VMs. You'll send malformed packets that kernel-panic the target, you'll accidentally fork-bomb yourself, you'll overflow something that corrupts the filesystem. It's part of the learning process. Snapshots mean none of that matters.
Create a file on your Kali VM:
mkdir -p ~/lab-notes
cat > ~/lab-notes/README.md << 'EOF'
# Ethical Hacking Lab Notes
## Network
- Lab network: 192.168.56.0/24 (Host-Only)
- Kali IP: (fill in after DHCP)
- Metasploitable2 IP: (fill in after DHCP)
- DVWA: http://localhost (Docker on Kali)
## Credentials
- Kali: kali / (your changed password)
- Metasploitable2: msfadmin / msfadmin
- DVWA: admin / password
## Snapshots
- Kali: "Clean Install" (date)
- Metasploitable2: "Clean Install" (date)
## Rules
1. NEVER connect lab VMs to the real network
2. ALWAYS snapshot before major exercises
3. Document everything - commands, outputs, observations
4. If something breaks: restore snapshot, don't debug for hours
EOF
Every professional pentester keeps meticulous notes. Start now. When you find a vulnerability, document: what you found, how you found it, what it means, and how to fix it. This habit will serve you wether you go into security professionally or just want to write more secure code.
Having said that, don't obsess over formatting your notes. Raw terminal output pasted into a text file is fine. Screenshots dumped into a folder is fine. The point is to have the information when you need it. During a real pentest engagement, you'll need to produce a formal report -- but in the learning phase, anything that captures the facts is good enough.
Here we go -- the moment of truth. From your Kali VM, run:
# 1. Can we reach Metasploitable?
ping -c 3 192.168.56.101
# 2. Can we see its open ports? (preview of what's coming!)
nmap -sV 192.168.56.101
# 3. Can we reach DVWA?
curl -s http://localhost | grep -o "DVWA"
# 4. Can we NOT reach the internet? (this SHOULD fail)
ping -c 3 google.com
Items 1-3 should succeed. Item 4 should FAIL with "Network is unreachable" or "Name resolution failed". If google.com responds, your network isolation is broken -- go back and fix it before continuing.
If everything checks out: gefeliciteerd! You have a professional-grade hacking lab running on your own machine. We'll be using this environment for the rest of the series.
Your lab will grow over the series. We'll add more target VMs for specific exercises -- Windows targets for Active Directory attacks, custom vulnerable apps for web testing, Docker containers for cloud/container security. But Kali + Metasploitable2 + DVWA is your starting trio, and it's enough for the next 10+ episodes.
If your machine struggles with multiple VMs (less than 8 GB RAM), you can run one target at a time. Shut down Metasploitable when working on DVWA, and vice versa. Kali stays running always -- it's your workstation.
A part from the RAM, also keep an eye on disk space. Snapshots consume space (each one stores the delta from the previous state), and they add up. I'd recommend keeping at most 3-4 snapshots per VM and deleting old ones you don't need anymore. Running out of disk in the middle of an exploit exercise is... not ideal ;-)
Exercise 1: Complete the full lab setup described in this episode. Take screenshots of: (a) your Kali VM running with ifconfig output showing the host-only IP, (b) Metasploitable2 running with its IP visible, (c) a successful ping from Kali to Metasploitable2, and (d) a failed ping from Kali to google.com. Save these screenshots in ~/lab-notes/ -- they're your proof that isolation works.
Exercise 2: From your Kali VM, run nmap -sV 192.168.56.101 against Metasploitable2 and save the full output to ~/lab-notes/metasploitable2-initial-scan.txt. Count how many open ports Nmap found. Look up THREE of those services and their version numbers -- for each one, search "CVE [service] [version]" and note whether known vulnerabilities exist. Don't exploit anything yet -- just observe and document.
Exercise 3: Log into DVWA (admin/password), go to DVWA Security and set the security level to Low. Navigate to the Command Injection page. In the input field, type 127.0.0.1; whoami and submit it. What happens? Write a short explanation (3-5 sentences) of WHY this works, referencing what you know about how operating systems handle the ; character in shell commands.
@scipio