10.1 Discovery and Scanning Cheatsheet
Establish reachability, discover listeners, then identify the exposed applications.
Start the first checks →Resolve ambiguous results and select the next service investigation.
Follow the finding →← Cheatsheet index · Complete procedures · Next: service opportunities · Mechanics | Strategy map | Study methods: Discover attack surfaces
Use when: an assigned IP/list must become a defensible queue of reachable applications. Replace every placeholder and stay inside explicit scope.
10.1.1 Fast baseline: one directly reachable host
mkdir -p scans
ip -br addr
ip route get TARGET
sudo nmap -sS -n -oA scans/tcp-initial TARGET
sudo nmap -sS -n -p- --stats-every 30s -oA scans/tcp-all TARGET
nmap -sT -n -sV -sC -p PORTS -oA scans/tcp-services TARGET
sudo nmap -sU -n --top-ports 20 -oA scans/udp-top20 TARGET
Read: initial TCP gives quick leads;
-p-covers TCP 1-65535;-sV -sCacts only on the discovered PORTS; UDP is a separate 20-port sample. Start service enumeration while wider coverage runs.
Build one line per useful endpoint:
SOURCE -> TARGET | tcp/udp PORT | STATE | APPLICATION EVIDENCE | COVERAGE LIMIT | NEXT TEST
Carry that line into the service opportunity sheet and append access context, namespace/object, effective right, result and next action. New hosts/routes/listeners return here; a new credential normally triggers authenticated service re-enumeration instead of an automatic complete rescan.
10.1.2 Choose a method that matches your access and required result Command chooser
10.1.2.1 Check source and route
ip -br addr
ip route get TARGET
Decisive output: the intended interface and source address. A route does not prove two-way reachability.
10.1.2.2 Discover an assigned host, list or subnet
nmap -sn -n -oA scans/host TARGET
nmap -sn -n -iL targets.txt -oA scans/hosts
nmap -sn -n -oA scans/subnet SUBNET
Choose SUBNET only when the whole CIDR is assigned. No response is not proof that a host is off.
10.1.2.3 Find common TCP listeners for an initial service map Initial/common TCP selection
sudo nmap -sS -n -oA scans/tcp-initial TARGET
Coverage: Nmap's 1,000 common TCP ports, not ports 1-1000.
10.1.2.4 Discover listeners across the full TCP port range Full TCP coverage
sudo nmap -sS -n -p- --stats-every 30s -oA scans/tcp-all TARGET
Coverage: TCP 1-65535. This says nothing about UDP.
10.1.2.5 Discover TCP listeners without raw-packet privileges No raw-packet privileges
nmap -sT -n -p- --stats-every 30s -oA scans/tcp-all-connect TARGET
Choose connect scanning for ordinary OS connections. A SYN scan normally requires elevated raw-packet access.
10.1.2.6 Scan a known-running host when discovery probes receive no reply Known-running target skipped by discovery
sudo nmap -sS -Pn -n --reason -p PORTS -oA scans/tcp-recheck TARGET
-Pn skips liveness proof; it does not fix a bad route. Read actual port responses, not only a host-up label.
10.1.2.7 Selected ports across an assigned list
sudo nmap -sS -n -p PORTS -iL targets.txt -oA scans/tcp-service-sweep
Useful for locating one service family. It is not a full port map.
10.1.2.8 Discover TCP services through an established SOCKS route TCP through an established SOCKS route
proxychains nmap -sT -Pn -n --top-ports 100 -oA scans/tcp-proxy-top100 TARGET
Only ordinary TCP connect calls traverse this route. SYN and UDP probes do not become proxy-compatible. Record the 100-port limit.
10.1.2.9 Identify applications on discovered TCP ports
nmap -sT -n -sV -p PORTS -oA scans/tcp-services TARGET
nmap -sT -n -sV -sC -p PORTS -oA scans/tcp-services-default TARGET
Use the first for application probes; add default scripts only when their interactions answer a useful question. A version match is an exploit candidate, not proof.
10.1.2.10 Inspect and run one named NSE script
nmap --script-help http-headers
nmap -sT -n -p PORTS --script http-headers -oA scans/http-headers TARGET
Decisive output: behavior or metadata relevant to the chosen question. Read script help before use. The example performs an HTTP HEAD request for /.
10.1.2.11 Select UDP coverage and resolve ambiguous replies UDP common sample, focused detail and full coverage
sudo nmap -sU -n --top-ports 20 -oA scans/udp-top20 TARGET
sudo nmap -sU -n --top-ports 100 -oA scans/udp-top100 TARGET
sudo nmap -sU -n -sV -p PORTS -oA scans/udp-detail TARGET
sudo nmap -sU -n -p- --stats-every 60s -oA scans/udp-all TARGET
Choose a bounded sample first, a protocol-aware focused probe when a candidate matters, and full UDP only when the objective/time justifies it. Silence can remain open|filtered; full coverage can be slow.
10.1.2.12 Verify one TCP endpoint
nc -nv -w 3 -z TARGET PORTS
sudo nmap -sS -n -v --reason -p PORTS -oN scans/tcp-check.txt TARGET
Use one port for the Netcat check. Success confirms connection acceptance; refusal is explicit rejection; timeout is unresolved. --reason shows what drove Nmap's classification.
10.1.2.13 Discover services from your Windows foothold Windows source position
Test-NetConnection -ComputerName TARGET -Port PORTS
22,80,443,445,3389 | % {echo ((New-Object Net.Sockets.TcpClient).Connect("TARGET", $_)) "TCP port $_ is open"} 2>$null
Use one port with Test-NetConnection. The loop prints successful ordinary TCP connections and hides errors; no line does not classify a port as closed. Results belong to the Windows host's route and filtering context.
10.1.3 Choose the next action from confirmed scan results State decisions
Run/context: interpret saved output from the actual scanning source and route. Decide: an open listener needs application-specific enumeration; filtered or silent results do not establish absence. Use failure repair for a coverage gap and rescan triggers when access or routing changes.
| State | What it establishes | Next action |
|---|---|---|
open | An endpoint accepted the selected connection/probe from this source | Identify and enumerate the application |
closed | Explicit rejection in this context | Move on unless target/source state later changes |
filtered | Filtering, loss or path behavior prevented a decision | Diagnose only when the endpoint matters |
unfiltered | Reachable by the chosen probe; open versus closed unresolved | Use a scan type that answers that distinction |
| `open | filtered` | Either listening silently or filtered |
| `closed | filtered` | Either rejected or filtered |
A port-number service label is a clue. -sV, protocol behavior and configuration evidence raise confidence. None of them alone proves exploitability.
10.1.4 Prioritize services and findings by the access they may enable Prioritization
Prefer the cheapest test likely to produce one of these:
- direct anonymous or supplied-credential access;
- exposed files, configuration, backups or useful metadata;
- a clear application/product/configuration prerequisite for a public exploit;
- credentials, names, shares or routes that expand another surface;
- a decisive disproof that lets you leave a path.
Investigate applications, not port stereotypes. Keep an explicit return item for incomplete full TCP, UDP or application coverage.
10.1.5 Repeat discovery when new identity or reachability changes coverage Rescan triggers
- New route, source host or tunnel: repeat the relevant network checks from that position.
- Target restart or changed assignment: confirm the IP and refresh affected results.
- New credential or identity: re-enumerate authentication-dependent service behavior; a complete port rescan is not automatically necessary.
- Foothold: inspect local and internally bound listeners, then map how to reach them.
- Higher privilege: re-enumerate protected configuration, credentials, services and routes.
- Lossy or inconsistent evidence: repeat only the decisive focused test with the same tuple and clearer diagnostics.
Do not repeat an unchanged disproven scan merely because an exploit failed.
10.1.6 Failure repair
| Symptom | Check |
|---|---|
| Every host appears down | Portal/target state, current IP, interface and route; then one assigned known endpoint |
| SYN scan lacks privileges | Use sudo or switch to -sT |
| Discovery omits a known-running target | Focused -Pn scan and actual response reasons |
| Only filtered results | Route/source, loss and one known/relevant endpoint |
| Kali and Windows disagree | Hold target, transport, port and time constant before blaming source filtering |
| Scan is slow | UDP silence, service probes, retries, loss and selected coverage; use progress output |
| Few results | Confirm default/common versus selected/range/full port coverage |
tcpwrapped or early close | Treat as an early-close observation, not a product or vulnerability; probe further only if identity matters |
10.1.7 Retain the evidence needed to reproduce the finding Evidence minimum
Save commands and output with different prefixes. Record source, target, transport, selected ports, discovery mode, scan type, time, state, application confidence, uncertainty and the next action. -oA PREFIX writes normal, grepable and XML output; keep the readable .nmap and the raw formats.
Sources: supplied PEN-200 2025 edition, sections 6.4.2-6.4.3, pp142-156; Nmap port states, scan techniques, version detection, NSE usage, timing, and output. Supplemental source: Hexdump live enumeration cheatsheet.
10.1.8 Discover and recognize candidates
Use these discovery checks to find a candidate, then validate the missing conditions. Cues are illustrative; complete synthetic outputs and three-outcome examples are in the linked study entries.
10.1.8.1 Discover attack surfaces
10.1.8.1.1 Find: Validate the source path and discover hosts
From the assessment host inspect the assigned interface and the route to the exact target before interpreting silence.
ip addr
ip route get TARGET
nmap -sn SUBNET -oA host-discovery
Recognize: The route names the intended interface/source; a responder is evidence from that source, not a global reachability claim.
Validate next: Check scope, target state and whether host-discovery probes are permitted by this path.
Validate the source path and discover hosts.
10.1.8.1.2 Commands and use-case variants
Need: An explicitly assigned address or host list and a known source position. Correct VPN/interface and explicit scope; discovery probes must be compatible with the path
Purpose: Confirm the source path and discover explicitly assigned hosts before spending time on port coverage.
10.1.8.1.2.1 Check the path
From the target's working folder:
mkdir -p scans
ip -br addr
ip route get TARGET
Read: selected interface/source address. A route lookup does not prove reachability.
10.1.8.1.2.1.1 Variants — discover one host, a host list or a subnet
10.1.8.1.2.2 Identify reachable hosts within the assigned scope Host discovery
One host:
nmap -sn -n -oA scans/host TARGET
Assigned list: put IPs in targets.txt, one per line.
nmap -sn -n -iL targets.txt -oA scans/hosts
Explicitly assigned subnet:
nmap -sn -n -oA scans/subnet SUBNET
No response does not establish that a host is offline. A list of assigned hosts does not imply the surrounding subnet is in scope.
Verify: Record source address/interface, route and the exact responding endpoint; a missing ping response does not prove a host is down.
If it fails: No route or wrong VPN interface is an environment failure. If only discovery is blocked, use the known-host TCP method; a SOCKS path requires a compatible connect-based client.
10.1.8.1.3 Find: Discover TCP ports with SYN or connect scans
After path validation, compare a first TCP pass with explicit full-port coverage; record skipped discovery or privilege limitations.
nmap -Pn -sT --top-ports 1000 TARGET -oA tcp-initial
nmap -Pn -sT -p- TARGET -oA tcp-full
Recognize: The high listener exists outside the first selection; its application label remains provisional.
Validate next: Confirm scan completion, source, errors and application behavior on each interesting port.
Discover TCP ports with SYN or connect scans.
10.1.8.1.4 Commands and use-case variants
Need: An explicitly assigned address or host list and a known source position. SYN scanning needs raw-packet privileges; connect scanning needs OS TCP connections; specify selected versus full port coverage
Purpose: Get quick leads, complete TCP coverage, and adapt scan type, discovery handling, timing and output to the access path.
10.1.8.1.4.1 Get initial TCP results
sudo nmap -sS -n -oA scans/tcp-initial TARGET
Coverage: 1,000 common TCP ports. Review
scans/tcp-initial.nmapin a text editor.
10.1.8.1.4.1.1 Variants — host list, connect scan or selected ports
10.1.8.1.4.2 Find common TCP listeners for an initial service map Initial view: 1,000 common ports
Assigned host list, SYN scan:
sudo nmap -sS -n -iL targets.txt -oA scans/tcp-initial-list
One host, connect scan without raw-packet privileges:
nmap -sT -n -oA scans/tcp-connect TARGET
Default coverage is the common-port selection, not ports 1-1000.
10.1.8.1.4.3 Selected ports or a range
One host: replace PORTS with, for example, 25,43 or 1-1024.
sudo nmap -sS -n -p PORTS -oA scans/tcp-selected TARGET
Find relevant services across assigned hosts:
sudo nmap -sS -n -p PORTS -iL targets.txt -oA scans/tcp-service-sweep
A focused service sweep is not a full port map.
10.1.8.1.4.4 Discover listeners across the full TCP port range Complete TCP coverage
sudo nmap -sS -n -p- -oA scans/tcp-all TARGET
Coverage: TCP 1-65535. Investigate useful initial results while this runs.
10.1.8.1.4.4.1 Variants — connect scan, blocked discovery, timing and progress
10.1.8.1.4.5 Discover listeners across the full TCP port range All TCP ports: 1-65535
Connect scan:
nmap -sT -n -p- -oA scans/tcp-all-connect TARGET
Inspect additional endpoints before narrowing the investigation. TCP coverage says nothing about UDP.
10.1.8.1.4.6 Discovery skips a running target
Recheck relevant ports with response reasons:
sudo nmap -sS -n -Pn --reason -p PORTS -oA scans/tcp-recheck TARGET
Proceed with full TCP coverage despite failed discovery:
sudo nmap -sS -n -Pn -p- -oA scans/tcp-all-no-discovery TARGET
-Pn assumes online status; inspect actual responses. It does not fix routing. Use -sT without sudo if ordinary TCP connections are needed.
10.1.8.1.4.7 Timing and progress
Full TCP with normal timing and periodic progress:
sudo nmap -sS -n -p- -T3 --stats-every 30s -oA scans/tcp-normal TARGET
Faster timing on a stable path:
sudo nmap -sS -n -p- -T4 --stats-every 30s -oA scans/tcp-faster TARGET
-T3 is normal timing; -T4 is more aggressive. Periodic progress changes display, not coverage. Recheck decisive results if loss or filtering makes observations uncertain.
10.1.8.1.4.8 Discover TCP services through an established SOCKS route TCP-only access through a SOCKS proxy
Use ordinary connect calls when a previously established proxy is the only route. This is a bounded first view, not complete TCP coverage:
proxychains nmap -sT -Pn -n --top-ports 100 -oA scans/tcp-proxy-top100 TARGET
proxychains cannot turn SYN probes or UDP into proxied TCP connections. -Pn avoids discovery probes that may not traverse the proxy. Confirm the proxy route first, preserve the 100-port limit, and expand with another connect scan only when scope and path permit it.
Verify: Retain the selected port set, source context, completion/errors and raw output; follow open ports with focused application evidence.
If it fails: Filtered is not closed. Through SOCKS use supported TCP-connect behavior and skip unsupported raw discovery/UDP; if results conflict, compare from the actual source.
10.1.8.1.5 Find: Identify applications and validate selected NSE checks
Take the discovered open-port list and request protocol/version evidence rather than choosing attacks from conventional port numbers.
nmap -Pn -sV -p PORTS TARGET -oA selected-services
Recognize: An HTTP response on a nonstandard port routes investigation to application mapping; a product string is still only fingerprint evidence.
Validate next: Verify normal requests, hostname/TLS requirements and exact build/configuration before selecting an exploit.
Identify applications and validate selected NSE checks.
10.1.8.1.6 Commands and use-case variants
Need: An explicitly assigned address or host list and a known source position. A reachable selected port; scripts must match the application and permitted assessment behavior
Purpose: Identify applications on discovered ports and choose only the probing needed for the next decision.
10.1.8.1.6.1 Identify discovered applications
nmap -sT -n -sV -p PORTS -oA scans/tcp-services TARGET
Next: choose service-specific enumeration from application evidence. A version match alone does not establish exploitability.
10.1.8.1.6.1.1 Variants — default scripts, named scripts and OS fingerprints
10.1.8.1.6.2 Identify applications on discovered ports
Version probing plus the default NSE script set: use when those scripts answer relevant enumeration questions.
nmap -sT -n -sV -sC -p PORTS -oA scans/tcp-services-default TARGET
Read the application evidence and script results. Default scripts add interactions; they do not complete service enumeration or prove exploitability.
Lighter version probing when time or fragile service behavior matters:
nmap -sT -n -sV --version-light -p PORTS -oA scans/tcp-services-light TARGET
Light mode tries fewer uncommon probes and can miss an identity that the default intensity finds. Use the default first unless a concrete constraint justifies the tradeoff.
10.1.8.1.6.3 Select a named script
Inspect behavior locally:
nmap --script-help http-headers
After identifying HTTP, inspect its relevant port(s):
nmap -sT -n -p PORTS --script http-headers -oA scans/http-headers TARGET
Returned headers are clues. Choose scripts for the question they answer and their behavior.
10.1.8.1.6.4 OS fingerprinting and bundled probing
Estimate OS from network-stack behavior:
sudo nmap -n -O -oA scans/os TARGET
Request more tentative OS guesses:
sudo nmap -n -O --osscan-guess -oA scans/os-guesses TARGET
Bundle OS/version detection, default scripts and traceroute:
sudo nmap -sS -n -A -oA scans/combined-detail TARGET
OS guesses are hypotheses. These use default TCP coverage; -A does not mean all ports. Choose this bundle only when its additional probing is useful.
Verify: Preserve the responding product/version evidence and distinguish an inferred fingerprint from a confirmed vulnerable build.
If it fails: A timeout, generic banner or scanner label leaves identity inconclusive; use native protocol clients or the unknown-port method.
10.1.8.1.7 Find: Probe UDP and resolve ambiguous silence
Inspect discovery results and DNS/SNMP/RPC clues, then probe a separate bounded UDP selection from the same source.
sudo nmap -Pn -sU --top-ports 20 --reason TARGET -oA udp-initial
Recognize: A DNS response confirms a UDP application; open|filtered SNMP silence is a candidate requiring a correctly formatted request.
Validate next: Check accepted service parameters, response identity and possible ICMP rate limiting.
Probe UDP and resolve ambiguous silence.
10.1.8.1.8 Commands and use-case variants
Need: An explicitly assigned address or host list and a known source position. Raw-packet access and UDP reachability from the real source; bounded or full selection must be explicit
Purpose: Sample UDP separately, preserve ambiguous states, and expand only when the objective or evidence warrants it.
10.1.8.1.8.1 Check UDP separately
sudo nmap -sU -n --top-ports 20 -oA scans/udp-top20 TARGET
Limit: this is a sample.
open|filteredremains inconclusive; expand when evidence or the objective warrants it.
10.1.8.1.8.1.1 Variants — larger sample, selected ports, application probes and TCP + UDP
10.1.8.1.8.2 Common-port samples
Expand to 100 common ports when more coverage is warranted:
sudo nmap -sU -n --top-ports 100 -oA scans/udp-top100 TARGET
These are samples. open|filtered is inconclusive; TCP results cannot fill UDP gaps.
10.1.8.1.8.3 Selected ports
Check a relevant UDP port/list:
sudo nmap -sU -n -p PORTS -oA scans/udp-selected TARGET
Add application probes to resolve a useful candidate:
sudo nmap -sU -n -sV -p PORTS -oA scans/udp-detail TARGET
A reply can resolve ambiguity; no reply can leave it inconclusive. If discovery skips an assigned running host, add -Pn with the same limitations as TCP.
10.1.8.1.8.4 Full UDP coverage when the objective justifies the cost
sudo nmap -sU -n -p- --stats-every 60s -oA scans/udp-all TARGET
This selects UDP ports 1-65535 and may take a long time because silence requires waiting and ICMP errors may be rate-limited. It is the coverage-expansion option, not a universal first command. Continue service work in parallel and preserve the result if the scan cannot finish.
10.1.8.1.8.5 Combined TCP/UDP selection
Example selection: change the TCP (T:) and UDP (U:) lists for the actual question.
sudo nmap -sS -sU -n -p T:22,80,445,U:53,123,161 -oA scans/tcp-udp TARGET
The port lists are examples, not complete coverage. UDP waiting can extend the combined scan.
Verify: Use an application response for a confirmed service; document unresolved silence, coverage and ICMP rate-limit effects.
If it fails: Do not translate UDP silence into a closed service. Retry a focused application-aware probe or a different permitted vantage point.
10.1.8.1.9 Find: Validate uncertain results and rebuild the service queue
Compare saved scan results with one direct connection and a service-native request for the endpoint that changes your next decision.
nc -nvz TARGET PORT
nmap -Pn -sT -p PORT --reason TARGET
Recognize: Independent TCP reachability supports an endpoint candidate, not credentials, read permission or execution.
Validate next: Identify the application and validate the particular next-layer action.
Validate uncertain results and rebuild the service queue.
10.1.8.1.10 Commands and use-case variants
Need: An explicitly assigned address or host list and a known source position. A selected endpoint and a test that can resolve the decision-changing uncertainty
Purpose: Resolve uncertainty that affects a decision, preserve coverage limits, and turn scan output into a service-enumeration queue.
10.1.8.1.10.1 Resolve a result that changes your next action
Keep source, destination, transport and port consistent when comparing results. Revisit relevant checks after a new route, foothold or identity changes access.
10.1.8.1.10.1.1 Variants — Netcat verification, response reasons and readable output
10.1.8.1.10.2 Netcat connection check
One TCP port: replace PORTS with one number.
nc -nv -w 3 -z TARGET PORTS
Short port range: replace PORTS with a range such as 3388-3390.
nc -nvv -w 3 -z TARGET PORTS
Success establishes TCP connection acceptance; refusal and timeout differ. The second form gives more verbose output. A three-second wait may be insufficient on a slow path.
10.1.8.1.10.3 Output and diagnostics
Readable text only, with verbose output and port-state reasons:
sudo nmap -sS -n -v --reason -p PORTS -oN scans/tcp-check.txt TARGET
Open saved .nmap or .txt output in a text editor. -oA writes .nmap, .gnmap and .xml; -oN writes only normal text. Use a different output prefix when retaining another run.
10.1.8.1.10.4 Build the service queue
Open the saved .nmap files in a text editor. For every useful endpoint, capture one line with this structure:
SOURCE -> TARGET | tcp/udp PORT | OBSERVED STATE | APPLICATION EVIDENCE | COVERAGE LIMIT | NEXT TEST
Next: carry the complete endpoint tuple into Stage 02 service enumeration and choose the cheapest protocol-aware test that can change your understanding or access. Keep an explicit return item for incomplete TCP, UDP or application coverage.
10.1.8.1.10.4.1 Interpretation cues — preserve what the scan actually established
openestablishes a reachable endpoint from the scan source; it does not establish a vulnerability or usable authentication.closedrecords an explicit rejection in that context. Move on unless later evidence changes the route, source or target state.filteredleaves the listener state unresolved because filtering, loss or the path prevented classification.unfilteredmeans the selected probe reached the port but could not determine whether it was open or closed; use a scan type that can answer the required question.- UDP
open|filteredis inconclusive. A useful protocol probe may reduce uncertainty, but another silence can remain inconclusive. closed|filteredis also an explicit ambiguity. Preserve it unless resolving the distinction changes the next action.- A port-based service label is a clue. Use application evidence before treating product, version, operating system or machine role as confirmed.
- Record the exact target, transport, selected ports and source position. A successful narrow scan does not cover untested ports, the other transport or another network position.
10.1.8.1.10.5 Prioritize and know when to rescan
Rank candidates by the cheapest test likely to produce access, credentials, sensitive information or a decisive prerequisite. Prefer observed application behavior over conventional port numbers. Keep at least one return item for incomplete coverage so an attractive early service does not erase the rest of the map.
Re-run network discovery after a new source host, route, tunnel or target restart. Re-enumerate a service after a new credential or identity. Inspect local listeners after a foothold. Recheck a previous result when the source, target state, port selection or network conditions changed—not simply because the first attack failed.
Verify: Record which layer was demonstrated: transport, application, authentication, read/write or execution.
If it fails: Connection success with no useful response needs a protocol-aware test; repeated identical failures without new evidence do not justify repeating the same path.
10.1.8.1.11 Find: Enumerate reachable endpoints from a Windows source
From the Windows foothold inspect interfaces/routes, then check an assigned internal host's selected service ports.
Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Test-NetConnection TARGET -Port 445
Recognize: The service is reachable from this Windows source; this can reveal a useful vantage point unavailable from Kali.
Validate next: Confirm application/authentication and whether a forward or a native client can use that route.
Enumerate reachable endpoints from a Windows source.
10.1.8.1.12 Commands and use-case variants
Need: An explicitly assigned address or host list and a known source position. A permitted Windows shell, explicit target list and built-in networking support
Purpose: Test TCP reachability from a Windows host when source position or available tooling matters.
Test one TCP port from the Windows source host:
Test-NetConnection -ComputerName TARGET -Port PORTS
Read:
TcpTestSucceeded, source and destination addresses. Use one number for PORTS. Failure does not distinguish a closed port, filtering or a path problem.
10.1.8.1.13 Variants — scan ports 1-1024 or a selected port list
10.1.8.1.13.1 Scan a low-port range
1..1024 | % {echo ((New-Object Net.Sockets.TcpClient).Connect("DC_IP", $_)) "TCP port $_ is open"} 2>$null
10.1.8.1.13.2 Check a selected port list
The example list can be changed to the endpoints of interest.
22,80,443,445,3389 | % {echo ((New-Object Net.Sockets.TcpClient).Connect("TARGET", $_)) "TCP port $_ is open"} 2>$null
$_ is the current port; errors are hidden. No printed result does not prove every port is closed. Results reflect the Windows host's access and the stated port selection.
Verify: Associate each result with the actual Windows source and selected port; do not claim UDP or full-port coverage.
If it fails: A false result may be routing, filtering or service absence; use route and listener evidence before deciding the service is down.
10.1.8.1.14 Find: Discriminate unknown listeners and use scanner alternatives
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
Recognize: TLS and an HTTP redirect suggest a hostname-selected web application rather than an attack tied to the port number.
Validate next: Reproduce the hostname/TLS request and confirm exact software/configuration.
Discriminate unknown listeners and use scanner alternatives.
10.1.8.1.15 Commands and use-case variants
Need: An explicitly assigned address or host list and a known source position. Explicit bounded scope; raw scanning alternatives need their required privileges and conservative rates
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.
10.1.8.1.15.1 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 -a TARGET -r 1-65535 --ulimit 5000 -- \
-Pn -sV -sC -oA rustscan-followup
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.
10.1.8.1.15.1.1 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.
10.1.8.1.15.2 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.
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
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.
10.1.8.1.15.3 Unknown-port discrimination
Start passively or with protocol-appropriate probes. Do not spray arbitrary strings at a stateful or destructive service.
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/
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.
10.1.8.1.15.4 NSE candidate checks
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
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:
nmap -Pn -sV --script vuln -p PORTS TARGET -oN nse-vuln-candidates.txt
Avoid *brute* categories as a default; first establish exact service, known test identities, lockout/rate limits and explicit authorization.
10.1.8.1.15.5 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 -h http://TARGET:PORT -output nikto-TARGET-PORT.txt
10.1.8.1.15.5.1 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.