Kali Linux Ethical Hacking, Part 2: Nmap Recon on Your Own Lab
Series: Kali Linux Ethical Hacking, Part 2. Previous: Part 1, a safe practice lab with Kali Linux 2026.2. Next: Part 3, web app testing on OWASP Juice Shop.
Nmap recon on your own lab means mapping what’s alive and listening before you touch anything. You find live hosts with nmap -sn, scan the common ports, then all 65,535, and use -sV to confirm services. Every scan stays inside your own lab or one you have written permission to test, and every result goes into your notes.
First, the legal bit
Disclaimer: This post is for education and authorized security testing only. Scanning or accessing a computer, network or account without permission is illegal, including under India’s Information Technology Act, 2000 and similar laws in other countries. Only scan systems you own, or systems where you have clear written permission from the owner before you start.
Every command below points at a private lab network that you built yourself. If you practise on TryHackMe or Hack The Box, scan only the machine you were assigned, and follow that platform’s rules.
What does Nmap recon mean in an authorized test?
Recon simply means finding out what is there before you touch anything. Which machines are alive? Which ports are open? Which services are listening, and which versions are they running?
Why it comes first
In a real engagement, the client gives you a written scope: a list of addresses you may test, and when. Recon builds the map inside that scope. Everything later, from web testing to reporting, depends on how good that map is. A sloppy map leads to missed findings, and worse, to traffic that wanders outside scope.
Passive and active
Passive recon gathers information without sending packets to the target, such as reading public documentation. Active recon sends traffic to the target, which is what Nmap does. Active recon is exactly the part that needs permission, which is why we keep it inside the lab.
Which Nmap version should you use in October 2026?
As of 21 October 2026, the Nmap changelog lists Nmap 7.992 as the latest release, dated 15 October 2026, after 7.991 on 6 August 2026 and 7.99 on 26 March 2026. The nmap.org homepage (checked 21 Oct 2026) also points to 7.992.
Kali packages may lag a little behind upstream. On the Kali package tracker (checked 21 Oct 2026), the version in kali-rolling is 7.991+dfsg-1kali1. That is fine for everything in this post. Check what you have with:
nmap --version
If you just updated from the older 2026.1 image, run sudo apt update && sudo apt full-upgrade -y and reboot, as we covered in Part 1.
If your Nmap version looks old, follow my Kali update routine before you scan again.
How do you scan your own lab with Nmap?
What you need before you start
- The lab from Part 1: a Kali VM and one practice target (for example Juice Shop on port 3000) on a host only network, with no bridged adapters.
- Your target’s lab address. The examples use
192.168.56.101; replace it everywhere with yours. - A notes folder: run
mkdir -p ~/lab-notes/$(date +%F)once before you start. - About 30 minutes. Every scan below is numbered and saved with
-oA, so you finish with a full set of evidence.
Follow Steps 0 to 6 in order.
Step 0: Confirm your network
Before scanning, confirm which network is yours. On the Kali VM, run:
ip -br addr
Expected output (sample, your names and numbers may differ):
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 10.0.2.15/24
eth1 UP 192.168.56.102/24
Look for the address on your host only adapter. In the examples below I’ll use 192.168.56.0/24 as a sample lab subnet, because that is a common host only default. Replace it with whatever your own lab uses, and never with an address you don’t own.
Step 1: Find live hosts
sudo nmap -sn 192.168.56.0/24 -oA ~/lab-notes/$(date +%F)/01-discovery
Expected output (sample from a generic lab):
Nmap scan report for 192.168.56.1
Host is up (0.00020s latency).
Nmap scan report for 192.168.56.101
Host is up (0.00031s latency).
Nmap scan report for 192.168.56.102
Host is up.
Nmap done: 256 IP addresses (3 hosts up) scanned in 2.10 seconds
The -sn option tells Nmap to discover which hosts are up without scanning ports (Nmap reference guide). In a small lab, you should see your Kali VM, your target, and possibly the hypervisor’s own virtual adapter. If you see anything you don’t recognise, stop and check your network settings. It may mean your lab is not as isolated as you thought.
Step 2: Scan the common ports on your target
Say your target is at 192.168.56.101:
sudo nmap 192.168.56.101 -oA ~/lab-notes/$(date +%F)/02-top1000
Expected output (sample for a Juice Shop target):
PORT STATE SERVICE
3000/tcp open ppp
The service name ppp is only Nmap’s guess from the port number. Step 4 fixes that.
With no extra options, Nmap scans the 1,000 most common TCP ports. It’s quick and gives you a first picture.
Step 3: Scan every TCP port
Services sometimes sit on unusual ports. A full scan covers all 65,535:
sudo nmap -p- 192.168.56.101 -oA ~/lab-notes/$(date +%F)/03-allports
Expected output: the same kind of port table, possibly with extra ports the default scan missed, and a final Nmap done line. On a minimal Juice Shop VM you may see port 22 too if SSH is installed.
This takes longer, but in a lab you have time. Patience is part of the job.
Step 4: Ask services who they are
Once you know which ports are open, ask Nmap to identify the services on just those ports:
sudo nmap -sV -p 22,80,3000 192.168.56.101 -oA ~/lab-notes/$(date +%F)/04-versions
Expected output (sample, details will differ):
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH (version shown here)
80/tcp closed http
3000/tcp open http (Node.js web app details or a fingerprint)
If Nmap can’t name the service, it prints a fingerprint block instead. That is normal for custom web apps.
Swap in the ports you actually found. The -sV option probes open ports to work out the service and version. OWASP Juice Shop, for example, usually listens on port 3000 when run with its defaults, but trust your scan over my example.
Step 5: Run the default scripts, gently
sudo nmap -sC -sV -p 3000 192.168.56.101 -oA ~/lab-notes/$(date +%F)/05-scripts
Expected output: the port line from Step 4, plus indented script results under it, such as an http-title line showing the shop’s page title.
-sC runs Nmap’s default script set, which gathers extra details such as page titles and server headers. On your own lab target, it’s a good way to learn what Nmap can tell you. On anything you don’t own, the answer is simple: don’t.
Step 6: Check your evidence
ls ~/lab-notes/$(date +%F)/
Expected output: three files for each scan, ending in .nmap, .xml and .gnmap, for example 01-discovery.nmap, 01-discovery.xml and 01-discovery.gnmap. Fifteen files means all five scans were saved.
How do you read Nmap results without guessing?
Nmap output looks dense at first. Take it one column at a time.
Port states
Each line shows a port, its state and a service name. “open” means something answered. “closed” means the host replied but nothing is listening there. “filtered” means something, often a firewall, stopped Nmap from getting a clear answer. Filtered does not mean safe. It only means unknown.
Service names are a best guess
In a plain scan, the service column is just Nmap’s guess from the port number. Port 80 says “http” because that is the usual service, not because Nmap checked. Only after -sV does Nmap try to confirm the service and version. Treating that guess as a finding is a common mistake in beginner write ups.
Versions need double checking
Even with -sV, a version can be wrong or incomplete. A web app might hide its version, or a proxy might answer in front of it. Treat a version as a lead to check, not a fact to report. In your lab, you can confirm it directly because you installed the target yourself, which makes the lab a good place to learn how often Nmap is right.
What defenders see
My day job sits close to network detection and response, and from that side, a full port scan is loud. Hundreds of connection attempts from one address in a few seconds stand out clearly. That’s a useful lesson for both sides: an attacker’s recon is often a defender’s best early warning. If you want open source tools for the defending side too, my roundup of security GitHub repos for October 2026 is a good next stop.
When I’m ready to use these scans to fix my own systems rather than just map them, I follow the steps in my Kali Linux defensive audit with Lynis and oletools.
If you want to see exactly what your scan looks like on the wire, capture it in your own lab with Wireshark and tshark.
How should you keep notes and scope files?
Good notes turn a scan into evidence. They also protect you if anyone ever asks what you did and when.
Save every scan
Nmap can write its results to files for you:
mkdir -p ~/lab-notes/2026-10-21
sudo nmap -sV -p- 192.168.56.101 -oA ~/lab-notes/2026-10-21/target-full
The -oA option saves normal, XML and grepable output at once (Nmap reference guide). The XML version is handy later, because many reporting tools can import it.
Keep a scope file
Create a small text file with the addresses you are allowed to scan, one on each line, and point Nmap at it:
echo "192.168.56.101" > ~/lab-notes/scope.txt
sudo nmap -sV -iL ~/lab-notes/scope.txt
With -iL, Nmap reads its targets from the file, so you can’t fat finger an address on the command line. It is a small habit that keeps real engagements inside scope.
Screenshots and a short log
Alongside the files, keep a short daily log: date, time, target, command and one line on what you learned. Add a screenshot only when it shows something the text doesn’t. When you write your first report, you’ll be glad you did.
What to do next
Here is your practice plan for this week:
- Run
nmap --versionand note the version alongside today’s date. - Confirm your lab subnet with
ip -br addrand write it intoscope.txt. - Run the five steps above against your own target, one at a time, and save each with
-oA. - For every open port, write down what Nmap guessed, what
-sVconfirmed, and what you know to be true because you installed it. - Compare a default scan with a full
-p-scan and note any ports the default missed. - Try one beginner network room on TryHackMe or an easy machine on Hack The Box, scanning only the assigned target.
- When you’re comfortable reading these scans by hand, you can let an AI agent run the same Nmap commands with your approval. My step by step MCP setup for Kali shows you how to keep it inside your lab.
In Part 3 of Kali Linux Ethical Hacking, we’ll take one of those open ports, the Juice Shop web app, and start mapping it with an intercepting proxy. It’s live now: Web App Testing Basics on OWASP Juice Shop. And if you’d like an AI agent to run these same scans for you, fully offline, I walk through that in Fully Local AI for Kali.
Leave a comment