Discriminate unknown listeners and use scanner alternatives
Needs: Explicit bounded scope; raw scanning alternatives need their required privileges and conservative rates
RustScan: fast TCP discovery, Nmap interpretation
Prerequisite: RustScan and Nmap on Kali; direct TCP reachability. Coverage: only the explicit TCP range. Decisive output: a discovered port that Nmap can reproduce and identify.
# RustScan: fast TCP discovery, Nmap interpretation
rustscan -a TARGET -r 1-65535 --ulimit 5000 -- \
-Pn -sV -sC -oA rustscan-followup
# Bounded first 1,000 TCP ports
rustscan -a TARGET -r 1-1000 --ulimit 5000 -- \
-Pn -sV -sC -oA rustscan-1000
Use only for a quick selection. It is not full TCP coverage and is not equivalent to Nmap's default top-1,000 selection.
Masscan: raw-packet discovery, then validation
Prerequisite: root/raw-packet access and a directly routed target. Choose it: for a large authorized address/port space where discovery speed matters. Failure cue: high loss or inconsistent results at the chosen rate.
# Masscan: raw-packet discovery, then validation
sudo masscan TARGET -p1-65535 --rate 500 -oL masscan-open.txt
# Treat each hit as a candidate and recheck with Nmap
PORTS=$(awk '$1 == "open" && $2 == "tcp" {print $3}' masscan-open.txt \
| sort -nu | paste -sd,)
test -n "$PORTS" && sudo nmap -Pn -sV -sC -p "$PORTS" TARGET -oA masscan-verified
# Unknown-port discrimination
nmap -Pn -sV --version-all -p PORT TARGET -oN port-PORT-version.txt
nmap --script-help banner
nmap -Pn --script=banner -p PORT TARGET -oN port-PORT-banner.txt
nc -nv TARGET PORT
openssl s_client -connect TARGET:PORT -servername HOSTNAME
curl -vk --max-time 10 https://TARGET:PORT/
Inspect a script before selecting it
# Inspect a script before selecting it
nmap --script-help SCRIPT_NAME
grep -i 'SCRIPT_NAME' /usr/share/nmap/scripts/script.db
# Run a named script against a confirmed service/port
nmap -Pn -sV --script SCRIPT_NAME -p PORT TARGET -oN nse-SCRIPT_NAME.txt
# NSE candidate checks
nmap -Pn -sV --script vuln -p PORTS TARGET -oN nse-vuln-candidates.txt
Nikto: bounded web-server candidate generation
Prerequisite: an identified HTTP(S) endpoint. Choose it: after manual baselining to identify common files, headers and server misconfiguration candidates. Decisive output: a finding manually reproduced with the same host, path and authentication context.
# Nikto: bounded web-server candidate generation
nikto -h http://TARGET:PORT -output nikto-TARGET-PORT.txt
# HTTPS, host name and tuning variants
nikto -h https://HOSTNAME:PORT -output nikto-HOSTNAME-PORT.txt
nikto -h http://TARGET:PORT -vhost HOSTNAME -output nikto-vhost.txt
nikto -h http://TARGET:PORT -Tuning 123b -output nikto-focused.txt
Tuning codes are version-sensitive. Inspect
nikto -H/ local documentation before relying on a copied code set.
Nikto is explicitly listed as allowed by the current OffSec exam guide, but its findings remain scanner candidates. Recheck the guide before an exam and manually validate anything that affects an attack decision.
Verify → Confirm the endpoint through independent application behavior and preserve the rate/scope used for discovery.
If it fails → No response may require TLS or a protocol-first request. Avoid treating speed-oriented results as complete, and keep prohibited mass vulnerability scanners outside the exam path. More detail ↓
Explanation & examples
Discriminate unknown listeners and use scanner alternatives
- USE WHEN
- A nonstandard listener, slow TCP discovery or a scanner-specific candidate
- STARTING ACCESS
- An explicitly assigned address or host list and a known source position
- RESULT
- A validated listener/protocol candidate rather than an unverified scanner finding
Recognize the clue
Select an unexplained listener from the saved queue, compare native connection behavior, then use focused version/TLS probes.
nmap -Pn -sV --version-all -p PORT TARGET
nc -nv TARGET PORT
PORT/tcp open ssl/http APPLICATION
HTTP/1.1 302 Found
Location: https://HOSTNAME/Means: TLS and an HTTP redirect suggest a hostname-selected web application rather than an attack tied to the port number.
Confirm: Reproduce the hostname/TLS request and confirm exact software/configuration.
- After validation
- A correctly addressed request produces the application: move to its normal behavior map.
- Ruled out in this context
- The banner disproves the originally assumed protocol: remove that service hypothesis.
- Still inconclusive
- No banner may mean a client-first protocol, TLS or filtering; use a discriminating normal request.
Troubleshooting: No response may require TLS or a protocol-first request. Avoid treating speed-oriented results as complete, and keep prohibited mass vulnerability scanners outside the exam path.
Use when: Nmap remains the interpretation baseline, but a faster TCP discovery pass or a bounded web-server check is useful. These tools generate candidates; Nmap/manual protocol checks confirm them.
RustScan: fast TCP discovery, Nmap interpretation
Prerequisite: RustScan and Nmap on Kali; direct TCP reachability. Coverage: only the explicit TCP range. Decisive output: a discovered port that Nmap can reproduce and identify.
If the target or network becomes unstable, lower concurrency rather than trusting an empty result. RustScan does not replace UDP work and does not prove that closed/filtered ports were tested with the same semantics as Nmap.
Bounded first 1,000 TCP ports
Use only for a quick selection. It is not full TCP coverage and is not equivalent to Nmap's default top-1,000 selection.
Masscan: raw-packet discovery, then validation
Prerequisite: root/raw-packet access and a directly routed target. Choose it: for a large authorized address/port space where discovery speed matters. Failure cue: high loss or inconsistent results at the chosen rate.
Treat each hit as a candidate and recheck with Nmap:
Masscan's raw-packet model is not suitable through a TCP SOCKS proxy. A rate that overwhelms the path can create false negatives and disrupt the lab; record the rate with the result.
Unknown-port discrimination
Start passively or with protocol-appropriate probes. Do not spray arbitrary strings at a stateful or destructive service.
Next action: route application evidence to the matching Stage 02 page. If TLS succeeds but HTTP does not, preserve the certificate names and protocol evidence instead of labelling it HTTPS.
NSE candidate checks
Inspect a script before selecting it:
Run a named script against a confirmed service/port:
The broad vuln category is candidate generation and can be intrusive or misleading. If its use is justified in the authorized lab, restrict it to identified ports and manually validate every result:
Avoid *brute* categories as a default; first establish exact service, known test identities, lockout/rate limits and explicit authorization.
Nikto: bounded web-server candidate generation
Prerequisite: an identified HTTP(S) endpoint. Choose it: after manual baselining to identify common files, headers and server misconfiguration candidates. Decisive output: a finding manually reproduced with the same host, path and authentication context.
HTTPS, host name and tuning variants
Tuning codes are version-sensitive. Inspect
nikto -H/ local documentation before relying on a copied code set.
Nikto is explicitly listed as allowed by the current OffSec exam guide, but its findings remain scanner candidates. Recheck the guide before an exam and manually validate anything that affects an attack decision.
Why it works
Fast discovery tools trade probing depth for speed. Recheck discovered ports with Nmap and a native client; a vulnerability-script label is not a complete exploit proof.
Worked example · hypothetical
Observation: fast discovery reports an unexpected high port. Test: a focused version probe and protocol request. Illustrative output: an HTTP response appears. Interpretation: treat it as a web application regardless of its port.
New identity, privilege, host or route? Re-enumerate → All topic tasks →