Notes From the Lab

How I Use Nmap

Nmap is the first tool I open on almost every engagement, and it's the first one I put in front of students. Before you can defend or attack a network, you need to know what's actually on it. Nmap answers three questions in order: which hosts are alive, which ports they have open, and what's listening behind those ports.

Start with host discovery

I never scan blind. On a fresh subnet I run a ping sweep first so I'm only spending time on machines that respond, instead of hammering dead addresses.

nmap -sn 10.0.0.0/24

The -sn flag means "no port scan" — just tell me who's home. This gives me a clean list of live hosts to focus on.

Then scan the hosts that answered

Once I have targets, I run a service and version scan with default scripts. This is the command I use most:

nmap -sC -sV -oA scan 10.0.0.5

Breaking it down: -sV detects the version of each service, -sC runs Nmap's safe default scripts, and -oA scan saves the output in all three formats (normal, greppable, and XML) using the base name scan. That last flag matters more than people expect — I want everything on disk so I can grep it later and drop the XML into a report.

Go deeper only when it's justified

A full port scan and OS detection is loud and slow, so I reserve it for hosts that look interesting:

nmap -p- -sV -O -oA full 10.0.0.5

-p- scans all 65,535 ports instead of the top 1,000, and -O attempts OS fingerprinting. I only do this when the quick scan hinted at something worth the extra time and noise.

How I read the results

• Open ports that shouldn't be exposed (RDP, SMB, database ports) go straight to the top of my notes.
• Version numbers get checked against known vulnerabilities — an old service is a lead, not a conclusion.
• Anything unexpected gets flagged for a manual look rather than trusted blindly.

Nmap doesn't exploit anything. It builds the map. Everything I do afterward is more accurate because I took the time to enumerate properly first.

Getting Started with Burp Suite

If Nmap is how I understand a network, Burp Suite is how I understand a web application. The single idea that makes Burp click for people is this: your browser and the server aren't really talking in pages, they're talking in requests. Burp sits in the middle and lets you see and change every one of them.

Set up the proxy

Burp runs an intercepting proxy, usually on 127.0.0.1:8080. You point your browser at it and install Burp's certificate so HTTPS traffic can be read. The cleanest way to do this is Burp's built-in Chromium browser, which is already configured — no system settings to untangle.

With interception on, every request pauses so you can inspect it. With it off, traffic flows normally but is still recorded in the history. New users should turn intercept off at first and just browse the target — then look at everything Burp quietly captured.

The three tabs that do most of the work

• Proxy — see the live request/response and edit anything before it's forwarded.
• Repeater — send the same request over and over with small changes. This is where you actually test ideas: change one parameter, resend, compare the response.
• Intruder — automate that same idea across a list of values, for things like checking many inputs or IDs.

A simple first exercise

On a deliberately vulnerable target like OWASP Juice Shop or DVWA, log in normally, find the request in the Proxy history, and send it to Repeater. Then change a value — an account ID, a quantity, a price field — and resend it. Watching the server accept something it shouldn't is the moment the whole tool makes sense.

POST /rest/user/login HTTP/1.1
Host: lab.local
Content-Type: application/json

{"email":"test@lab.local","password":"..."}

Send that to Repeater, edit the JSON, resend, and read the response carefully. Burp doesn't find bugs for you — it removes everything between you and the raw conversation so you can.

One rule I repeat constantly: only ever point Burp at applications you own or are explicitly authorized to test. The lab is where you learn; someone else's site is where you get in trouble.

Cracking Passwords in the Lab

I teach password cracking for one reason: nothing convinces people to use long passphrases and MFA faster than watching a weak password fall in seconds. Everything below is done on hashes I generate myself, in an isolated lab. The goal is understanding, not breaking into anything.

Why hashing matters first

Systems don't (or shouldn't) store your password. They store a hash — a one-way fingerprint of it. When you log in, the system hashes what you typed and compares. Cracking a password means guessing inputs, hashing each guess, and checking for a match. So the strength of a password comes down to how many guesses an attacker has to make.

The two approaches I demonstrate

A dictionary attack tries a list of likely passwords. Most real-world compromises happen here, because people reuse common ones. In a lab I run something like:

hashcat -m 0 -a 0 hashes.txt rockyou.txt

Here -m 0 tells hashcat the hashes are MD5, and -a 0 selects a straight wordlist attack against a classic training wordlist. Common passwords like password123 or qwerty match almost instantly.

A brute-force attack tries every combination in a defined space. It works on short passwords and becomes hopeless as length grows:

hashcat -m 0 -a 3 hashes.txt ?a?a?a?a?a?a

Each ?a is one position of any printable character. Add one more character and the time to exhaust the space multiplies. This is the demo that sells passphrases.

The lesson I want students to keep

• Length beats complexity. A long, memorable passphrase outlasts a short string of symbols.
• Uniqueness matters. A reused password is only as safe as the weakest site it's on.
• Defenders should hash slowly. Algorithms like bcrypt or Argon2 make each guess expensive on purpose.
• MFA is the backstop. Even a cracked password fails without the second factor.

I never target real accounts, and neither should you. Generate your own hashes, crack those, and take the lesson back to how you protect real systems.