Your target for this lab is a single host on the internal network: webserver2. You know nothing about it yet. The first job of any assessment is always the same: find out what is listening.
Run a default Nmap scan against the target:
nmap webserver2Read the output. Nmap prints a table of the ports it found open, the state of each, and a guessed service name.
💡 Hint: The simplest invocation isnmap TARGET . With no other flags, Nmap scans the 1000 most common TCP ports.
A server offers services (web, mail, SSH and so on) on numbered ports, from 0 to 65535. Scanning asks each port one simple question: are you accepting connections?
To open a TCP connection your machine sends a
There are 65535 TCP ports, but scanning all of them takes time. By default Nmap scans the 1000 most commonly used ports, ranked by how often they turn up open in the real world. That is why the report ends with a line like
Now scan a single port. Check whether port 6379 (Redis) is open on webserver2:
nmap -p 6379 webserver2💡 Hint: The-p flag chooses which ports to scan.-p 443 scans only that one.
When you already know what you are looking for, scanning a single port is fast and quiet. The moment you pass
Targeted scans generate far less traffic, which matters when you are trying not to trip an intrusion detection system.
Notice there is noNot shown line this time. You asked about one port, so there is nothing to summarise.
You can list several ports at once, separated by commas. Scan ports 21, 23 and 25 on webserver2
These are ftp, telnet and smtp: three older, plaintext protocols. See which are open.
💡 Hint: Use a comma separated list with no spaces:-p 21,23,25 .
Finding telnet (23) or ftp (21) open is immediately interesting to an attacker: both send credentials in cleartext, so anyone on the network path can read them.
Part of scanning is not just listing ports, but recognising which ones represent real risk. A comma separated list lets you probe a hand picked set of interesting ports in a single command instead of scanning everything.
Scan a whole range of ports, from 20 to 1200, on webserver2
💡 Hint: Ranges use a dash:-p start-finish . To scan every single port from 1 to 65535, use-p- .
A range is convenient, but it cuts both ways. This scan stops at port 1200, so any service listening above that number stays invisible. This host happens to run something on a much higher port that you will not see here at all.
Attackers routinely hide services on unusual high ports precisely because lazy scans miss them.
So far you have scanned one known host. In a real engagement you are usually handed a range and must first work out which addresses are even alive, before wasting time port scanning empty ones.
Find out which hosts on the your local network eth0 is connected to network are up, without port scanning any of them. At least one other machine besides your target will answer.
💡 Hint: Runnmap -h and read the HOST DISCOVERY section. One option there performs discovery only and disables the port scan entirely. A whole network is written in CIDR notation, like10.11.12.0/24 .
To tell whether a host exists, Nmap sends a mix of probes and waits for any reply: an ICMP echo (a classic ping), an ICMP timestamp request, and TCP packets to ports 80 and 443. On a local network segment like this one it can also use ARP, which is fast and almost impossible to block. If anything comes back, the host is marked up.
Port scanning 256 addresses when only a handful are live is slow and noisy. Host discovery turns a big blind range into a short list of real targets. This is the top of the recon funnel: discover hosts, then scan ports, then identify services.
Some hosts are configured to ignore ping probes. Nmap then reports them as down and refuses to scan them at all. Scan port 80 of 10.11.12.216 in a way that skips the discovery step and treats the host as online no matter what.
💡 Hint: Look again at HOST DISCOVERY innmap -h . You want the option that means "no ping". Combine it with the port flag you already know.
By default, if host discovery gets no reply, Nmap prints
It says: skip discovery, assume the host is alive, go straight to the port scan. The trade off is speed against completeness. On modern, firewalled targets it is one of the most useful flags you will reach for.
Every scan so far has told you a port is open and guessed a service from the port number alone. That guess is often wrong, and on this host it is sometimes a deliberate lie. Time to actually interrogate the services.
Scan port 80 of webserver2 and make Nmap report the exact software and version running behind it, not just the port number's usual service name. A new
💡 Hint: Check the SERVICE/VERSION DETECTION section ofnmap -h . The flag you want is two characters after the dash.
Nmap opens the port, sends a series of carefully chosen probes, and compares the reply against a large database of known service fingerprints. That is how it turns
Apache 2.2.14 was released in 2009. A version that old is a giant flashing sign that says: look for known vulnerabilities against me. Half of exploitation is just matching a version number to a public advisory.
Banners are set by the server, so they can be faked. A defender can make a fully patched server claim to be an ancient one, and this target does exactly that. Some of its ports even defeat detection entirely and show up with a question mark, like
Nmap is not just a port scanner. It ships with the Nmap Scripting Engine (NSE): hundreds of small Lua scripts that probe deeper, grabbing page titles, testing for anonymous logins, enumerating shares and checking for well known vulnerabilities.
Run the default set of NSE scripts against port 80 of webserver2. You will know it worked when extra lines appear underneath the port, each one prefixed with a pipe character.
💡 Hint: See SCRIPT SCAN innmap -h . There is a short two character flag that is exactly equivalent to writing--script=default .
NSE scripts are grouped into categories:
The
On a web port, the default scripts pull things like the page title and the HTTP methods the server allows.
You can also run one specific script by name instead of a whole category. Run the script called
💡 Hint: The long option for choosing scripts takes a name or a comma separated list. You saw its shorthand in the previous challenge; this time write it out in full and pass it the script name.nmap --script-help banner will tell you what it does first.
The banner should reveal
This is the whole point of banner grabbing: a single line of text turned an open port into a known, exploitable target. Whether this particular host is truly vulnerable, or just pretending to be in order to bait attackers, is exactly the kind of question the rest of your recon has to answer.
Browse scripts by category with wildcards, for example
Reading Nmap output by eye is fine for one host. When you scan thousands, you need output a script can chew on.
Scan ports 22 and 80 of webserver2 and produce greppable output, printed straight to your terminal rather than saved to a file. Each host should collapse onto a single line.
💡 Hint: The OUTPUT section ofnmap -h lists several flags that start with-o , one per format. Pick the greppable one. Every-o flag needs a filename, and a lone- means standard output.
Nmap can write results in several formats, even all at once:
The greppable format is a favourite for quick pipelines, for example pulling every host with port 22 open. XML is what you import into larger frameworks. Getting into the habit of always saving output with
You have learned to find hosts, find ports and identify services, one flag at a time. Sometimes you just want all of it at once.
Scan webserver2 with the single flag that turns on everything: version detection, the default scripts, OS detection and traceroute, all together.
💡 Hint: It is one uppercase letter, and it is listed near the top ofnmap -h under SCAN TECHNIQUES as enabling OS detection and version detection at the same time. This scan takes noticeably longer than the others.
Aggressive scanning throws a lot of probes at the target, which is exactly what defenders watch for. In a stealth engagement it would light you up instantly. It is perfect for a lab or an authorised, time boxed assessment, and a poor choice when you are trying to stay quiet. Note that OS detection needs root (raw socket access), so run unprivileged, that part is skipped or guessed.
Step back and look at everything you found on this host: an ancient Apache, a backdoored FTP, a cleartext telnet, odd services on high ports. Real machines are rarely this conveniently vulnerable.
That is because this target is a honeypot: a decoy that fakes a zoo of tempting, deliberately old services to attract attackers, waste their time, and quietly log every probe, including yours. Every banner you trusted was written to fool you.
The final lesson of recon is the most important one: enumeration tells you what a host claims to be, and confirming what is actually true is a separate job.