Ethical pen-testing course
Lesson 1 of 19 — jokes in the margins, seriousness in the scope: real commands, lab-shaped examples, quizzes that explain the “why.” Only poke boxes you own or got in writing.
Introduction to ethical hacking
What penetration testing is, how it differs from criminal hacking, scoping, contracts, and responsible disclosure.
Adulting first: signed permission, clear scope, and “how will I prove this later?” habits—then the shiny tools get to play.
After this lesson you should be able to say
- Skills are trainable; systems fail—keep curiosity and “where is trust assumed?” on the same team.
- CIA triad + threat / vulnerability / risk / exploit = shared vocabulary so your report does not sound like vibes.
- Black, grey, white box only changes how much context you start with—not whether you need a written yes.
- Screenshots are dessert; raw logs, hashes, and UTC timestamps are the vegetables auditors still eat.
Hands-on tutorial
Step 1: Install Kali Linux (VM, bare metal, or cloud) — pick the couch, not the courtroom
Most humans run Kali in a **virtual machine** (VirtualBox, VMware, QEMU/KVM) so snapshots keep your daily driver out of the drama. Dual-boot if you need native Wi-Fi toys; cloud images if your laptop is mostly a paperweight with Wi-Fi. Give the VM at least two vCPUs and 4–8 GB RAM so Burp and Metasploit do not sound like a dying lawnmower. After install, run `sudo apt update && sudo apt full-upgrade` on a schedule you can actually keep—Kali rolls forward; frozen labs grow weird mold.
One sentence in your notes is enough. If the answer is “I never thought about it,” congratulations—you just passed the secret level called adult backups.
Checking account…Step 2: Kali on Android: NetHunter + Termux (without turning your phone into a drama factory)
You do not “install full Kali as your phone OS” like installing Windows—think **NetHunter**: Kali-flavored tooling layered on Android. **Rootless** works on normal phones via Termux + the NetHunter store—great when your bootloader is shy. **Lite/full** need root/custom recovery and sometimes special Wi-Fi hardware for spicy radio tricks. Grab Termux from **F-Droid** (community builds play nicer), expect chunky downloads, and read the prompts like they are Terms & Conditions written by someone who cares about your storage.
Honest answer wins: Rootless protects your daily driver; “because TWRP README scared me” is also valid—just pick the path that matches your risk appetite, not TikTok hype.
Checking account…Step 3: Mindset: growth brain + security brain (the “hacker mindset” without the cosplay)
Two habits to grow on purpose. **Growth habit:** skills are trainable; confusion is just data; "not yet" is a starting line, not a verdict on your soul. **Security habit** (Schneier energy): systems get tired, humans click shiny things, and policy PDFs lose to incentives—so you hunt where trust is assumed without proof. Ethical testers keep both: stubborn curiosity plus careful paranoia that still shows receipts. Some courses shout "Try harder"; we prefer "read the error, shrink the problem, celebrate a boring win." Calling yourself "not a terminal person" is how gear keeps default passwords forever—you are allowed to be a beginner without being that router.
If nothing comes to mind, pick “I thought `ping` proved a host was down.” We have all hugged that false negative.
Checking account…Step 4: CIA triad + vocabulary (without the pop quiz sweat smell)
**Confidentiality** — only the right eyes see the secret. **Integrity** — nobody swapped the recipe while you blinked. **Availability** — the thing is actually there when humans need it (DDoS and ransomware both bully this leg). **Threat** — anything mean enough to use a weakness. **Vulnerability** — the actual hole (patch missing, config oops, logic whoops). **Risk** — how likely × how painful in *your* world (money, safety, legal drama). **Exploit** — the gadget that weaponizes the hole; without permission it is crime cosplay, not a flex. When you write findings later, tie each issue to CIA + business pain so executives stop asking “but is it bad-bad or brunch-bad?”
Sketch: confidentiality (secrets read), integrity (future forged mail), availability maybe untouched. Threat actor = human story; vulnerability = MFA gap or training gap—argue both sides in two lines.
Checking account…Step 5: What is a penetration test?
A penetration test is a time-boxed, permissioned dress rehearsal for real attackers—but with brakes, coffee breaks, and a spreadsheet. You do not wander the network improvising; you follow a signed scope: which hosts, URLs, APIs, and hours are fair game, what is explicitly off-limits (credential stuffing prod logins, phishing staff without a program, etc.), and how to yell for help if something wobbles. The deliverable is not a folder of flex screenshots—it is a story with receipts: what you tried, what you proved, how findings chain, and what to fix first so sleep returns to on-call. Good testers also spell out how to retest fixes so nobody argues in circles.
Hint: asset list, forbidden actions, emergency contact. If you answered “my hourly rate,” you are technically correct but legally lonely.
Checking account…Step 6: Engagement styles you will see
**Black box:** outside-in—you get almost no map and earn every clue like an invited burglar with a badge. **Grey box:** curated hints (VPN profile, staging creds, an API PDF) so you spend less time guessing hostnames and more time on logic bugs. **White box:** diagrams, configs, maybe source—think insider or supply-chain story, not just script kiddie speedruns. The roadmap order (footprint, scan, enumerate) does not change; only your starting intel and how you write the narrative do. Always log which assumptions you used so retest day can replay your brain honestly.
Starting assumptions, supplied diagrams, creds used, and what you would not know in pure black box—retest depends on that lens.
Checking account…Step 7: Map your work to PTES-style phases
Roadmaps usually mirror PTES-ish phases even when nobody prints the sticker: pre-engagement, intel, threat modeling, vuln analysis, exploitation, post-exploitation, reporting. You do not need to quote PTES like poetry—you need a checklist that maps your notes to buckets so 2 a.m. you does not skip steps. Example: threat modeling might be drawing trust lines between DMZ APIs and internal payroll; post-exploitation might mean documenting lateral paths you stopped at because scope said first shell only. Folder names like `01_recon/` and `02_scan/` are how teammates and auditors hug you later.
Most mortals skip reporting notes until Sunday night. If that is you, automate: one `notes.md` per host with timestamps as you go.
Checking account…Step 8: Evidence chain on Kali
Evidence is what survives a grumpy engineering lead and sometimes a lawyer. A screenshot without context looks staged; pair it with the exact command, UTC time, tool version, and the scope line it satisfies. Keep raw logs next to human summaries—nmap XML, PCAP hashes, redacted secrets. When you rerun a command after a patch, write a new dated file instead of stomping the old one so everyone can diff what changed. That boring discipline is the difference between hobby scans and invoices someone actually pays.
Raw logs are diffable and hashable; screenshots are dessert. Auditors eat vegetables first.
Checking account…What to expect: Timestamps in UTC, one kernel line, and a single nmap version line you can paste straight into a report appendix.
# Example: log tool versions for the appendixdateuname -anmap --version 2>/dev/null | head -n 1
Tue May 12 14:22:03 UTC 2026Linux kali 6.12.0-kali-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.5-1kali1 (2026-01-15) x86_64 GNU/LinuxNmap version 7.95 ( https://nmap.org )
Step 9: Warm up on Kali: your lab checklist
Before your NIC sends anything spicy, write the exact IPs, hostnames, and URLs you may touch plus the approved window. Make one folder per client or lab story so PCAPs never mingle with grocery lists. Drop a short `scope.txt` with the ROE summary and your tester handle so future-you remembers why the folder exists. If you discover a new subnet and get excited, pause—confirm it is in scope. Roadmaps teach moves; contracts still own legality.
Use client code + date + your handle—future you greps faster and fewer souls get hurt.
Checking account…What to expect: A new folder under your home, a `scope.txt` file with today’s date on the first line, and your pasted target list appended—zero drama if permissions are wrong (you will see “Permission denied” immediately).
mkdir -p ~/lab-engagements/demo1 && cd ~/lab-engagements/demo1 && date > scope.txt && echo "Targets: (paste from ROE)" >> scope.txt$ mkdir -p ~/lab-engagements/demo1 && cd ~/lab-engagements/demo1 && date > scope.txt && echo "Targets: (paste from ROE)" >> scope.txt$ ls -latotal 12drwxr-xr-x 2 kali kali 4096 May 12 14:25 .drwxr-xr-x 3 kali kali 4096 May 12 14:25 ..-rw-r--r-- 1 kali kali 32 May 12 14:25 scope.txt$ cat scope.txtTue May 12 14:25:11 UTC 2026Targets: (paste from ROE)
Example pen-test slice
Mini example: internal web app kickoff
You are hired to test https://app.internal.example (fictional). The client gave you a PDF scope listing that single URL and two staging IPs.
Playbook
- Read the scope PDF twice. Highlight forbidden actions (DoS, social phishing of staff, etc.).
- Create engagement folder, copy scope summary into notes, list test windows.
- Tell the client when you will start and which source IP your Kali VM uses.
What to expect: Silent success; `pwd` should end in `client-app`.
mkdir -p ~/engagements/client-app && cd ~/engagements/client-app$ mkdir -p ~/engagements/client-app && cd ~/engagements/client-app$ pwd/home/kali/engagements/client-app
What to expect: One public IPv4 or IPv6 string—exactly what SOC pastes into an allowlist.
curl -s ifconfig.me && echo$ curl -s ifconfig.me && echo203.0.113.44
Extra tools on this topic (Kali)
End-of-lesson challenge
Pick the best answer for each question, then reveal results. Wrong answers still teach—read every explanation.