A single laptop can hold an entire enterprise: a vulnerable Linux host, a Windows box with an ancient SMB service, and a router you forgot you configured. The trick is learning to interrogate that network methodically before you start throwing exploits at it. Nmap tells you what is present and what it is talking; Metasploit lets you confirm that a finding is real without wrecking the machine. This walkthrough covers the whole loop on an isolated lab network — discovery, scanning, enumeration, and careful validation.

Set Up an Isolated Lab First

Do not point these tools at anything you do not own or have written permission to test. Unauthorised scanning is illegal in many jurisdictions, and "I was only practising" is not a defence. If you are unsure where you stand, get qualified advice before you start.

For a home lab, the safest pattern is a host-only or internal network inside your hypervisor — VirtualBox, VMware, Proxmox, or Hyper-V. Guests on that network can reach each other but have no route to your home LAN or the internet. Deliberately vulnerable targets such as Metasploitable 2, DVWA, or an evaluation build of Windows Server make good first subjects, because every finding you make is expected.

Give the attacker machine a static address, for example 192.168.56.10/24, and note the subnet. Everything below assumes a target at 192.168.56.20 on that range.

Host Discovery: Find Out What Exists

Start with a ping sweep rather than a port scan. It is fast, quiet, and it tells you how large the problem is.

nmap -sn 192.168.56.0/24

The -sn flag skips port scanning and probes only for live hosts. On a local segment Nmap uses ARP, which is far more reliable than ICMP — plenty of hosts ignore ping requests and still answer ARP. If you are scanning across a router and get nothing back, add -Pn later to assume hosts are up and push straight to ports.

Write the live addresses to a file. Every later step gets shorter when you feed Nmap a target list instead of a CIDR block.

nmap -sn 192.168.56.0/24 -oG - | awk '/Up$/{print $2}' > targets.txt

Port Scanning Without Losing the Afternoon

Now map the attack surface. A SYN scan (-sS) is the default when you have root and is quicker than a full TCP connect; -T4 is a reasonable timing template on a lab network. Start broad, then narrow.

• Quick sweep: nmap -sS -F 192.168.56.20 scans the hundred most common ports.
• Wider net: --top-ports 1000, or -p- for all 65,535 TCP ports when you suspect a service hiding high up.
• UDP: nmap -sU --top-ports 50 catches DNS, SNMP, and TFTP, but it is slow — keep the list short.
• Hosts that block discovery: add -Pn so Nmap scans regardless.

Read the state column carefully. Open means something is listening. Closed means the host replied but nothing is there. Filtered usually means a firewall dropped your probe — that is a finding in itself, not a failure.

Enumeration Is Where the Value Is

A port number is a hint; a service banner is evidence. Turn on version detection and the default script set together.

nmap -sS -sV -sC -p 21,22,80,139,445,3306 192.168.56.20 -oA scan-20

The -oA flag writes three output formats at once, and you will want the XML version for Metasploit. Expect -sV to take noticeably longer than a plain scan, because it interrogates each listener instead of simply noting that it answered.

When a banner looks interesting, drill in with the Nmap Scripting Engine.

nmap --script smb-os-discovery,http-title -p 445,80 192.168.56.20

Note what you find: exact version strings, hostnames, share names, HTTP titles, certificate subjects. That text is what you will search against later, and vague notes such as "SMB looks old" will cost you an hour when you come back to them.

Moving into Metasploit

Launch the console and create a workspace so this session stays separate from anything else you have stored.

msfconsole -q

workspace -a lab1

Import the XML file Nmap produced. That loads hosts, services, and ports into the database and makes the hosts and services commands usable as quick targeting shortcuts.

db_import /home/user/scan-20.xml

services

Now search for modules using the version string you recorded.

search type:exploit platform:linux samba

Pick a candidate, load it, and set your options.

use exploit/linux/samba/is_known_pipename

set RHOSTS 192.168.56.20

set LHOST 192.168.56.10

check

The check command is the part people skip. When a module supports it, it can confirm whether the target is vulnerable without firing a payload at all. Run it first. When it is unavailable, read the module description and its references before you run anything.

Keep the Exploitation Boring

In a training lab the goal is proof, not persistence. A few habits keep things safe and repeatable.

1. Confirm access with the smallest possible action — id, whoami, hostname — then stop.
2. Never leave backdoors, scheduled tasks, or modified credentials behind.
3. Snapshot the target VM before each attempt so you can roll back to a clean state.
4. Record the exact module, options, and output for every session you open.

If a module fails, resist the urge to hammer it with different payloads. Go back to enumeration. A mismatched version, a service on a non-standard port, or a firewall rule may explain the failure.

Turn One Test into a Reusable Method

The loop is always the same, and it gets faster each time you run it. Discover hosts, scan ports, identify services, search for modules matching those exact versions, validate with the least invasive option available, then write down what happened.

Keep a plain text log per target: date, subnet, command lines, raw findings, conclusions. Next session, start from those notes instead of a blank terminal. That habit — not a longer exploit list — is what turns a handful of commands into genuine penetration testing skill.

Photo: Brett Sayles / Pexels