1.1 Discover attack surfaces

Strategy map | Master Notes | Operational index | Cheatsheets

Discovery establishes reachable behavior from a particular source. Keep host discovery, TCP coverage, UDP coverage and application identity separate; each produces different evidence.

Speedrun blocks: 1; revisit after new routes or hosts. Documented methods: 7.

Examples are hypothetical study material. Apply commands only to an assigned scope during the later practice phase. A method is enabled by its prerequisites; its presence here does not establish a vulnerability or practical mastery.

1.1.1 First pass: tools and findings

Use the branch matching the current host, identity and observed result. Tool output supplies leads; the linked procedure verifies and uses the exact condition.

1.1.1.1 Confirm the source route

Run from the machine that will send the scan. Keep the assigned scope explicit.

ip addr
ip route get TARGET
nmap -sn SUBNET -oA host-discovery

• If A route selects the expected interface/source: Reachability still needs a probe; a route lookup alone is not a live host. → Discover TCP ports with SYN or connect scans.
• Otherwise: No response from host discovery: test the assigned host without assuming it is offline. → Discover TCP ports with SYN or connect scans.

1.1.1.2 Build a TCP port list with Nmap

The command below scans all TCP ports with SYN privileges. Create the scans output directory first; use the complete connect-scan variant when unprivileged. Keep the fast initial pass distinct from full coverage.

sudo nmap -sS -n -p- -oA scans/tcp-all TARGET

• If An open TCP port: Run focused service detection on the discovered ports, including nonstandard ones. → Identify applications and validate selected NSE checks.
• Otherwise: Only TCP was checked: investigate UDP when the objective or DNS/SNMP/RPC clues call for it. → Probe UDP and resolve ambiguous silence.

1.1.1.3 Identify the responding application

Keep the endpoint and raw service output; choose the matching client from its response.

nmap -Pn -sV -p PORTS TARGET -oA selected-services
nmap --script-help SCRIPT_NAME

• If SMB/RPC responds: Check anonymous or known-identity share access. → Enumerate SMB/RPC shares, files and identities.
• If An HTTP response or redirect: Resolve the correct scheme and hostname before directory discovery. → Establish scheme, host, redirects and request state.
• If An unrecognized listener: Send a protocol-specific probe instead of choosing an exploit by port number. → Discriminate unknown listeners and use scanner alternatives.
• Otherwise: Results conflict with client behavior: rebuild the endpoint queue from confirmed responses. → Validate uncertain results and rebuild the service queue.

1.1.2 Discovery workflow

Start with an assigned address/list and your actual source interface; no open service is assumed.

Follow these observations into a method; the detailed recognition routes below show synthetic output and the checks still needed.

1. Confirm the source interface, route and host-discovery limitations: Validate the source path and discover hosts.
2. Separate initial TCP selection, full TCP coverage and UDP investigation: Discover TCP ports with SYN or connect scans; Probe UDP and resolve ambiguous silence.
3. Establish application evidence on discovered listeners, including nonstandard ports: Identify applications and validate selected NSE checks; Discriminate unknown listeners and use scanner alternatives.
4. Save the endpoint queue and revisit it after a new identity or route: Validate uncertain results and rebuild the service queue.

Decision rule: an observed clue opens a candidate. Choose it only after the missing conditions are verified; a failed check rules out that context, while unavailable evidence stays inconclusive.

1.1.3 Method families

• Source and reachability: Validate the source path and discover hosts, Enumerate reachable endpoints from a Windows source.
• Transport coverage and application identity: Discover TCP ports with SYN or connect scans, Probe UDP and resolve ambiguous silence, Identify applications and validate selected NSE checks, Discriminate unknown listeners and use scanner alternatives.
• Evidence and re-enumeration: Validate uncertain results and rebuild the service queue.

1.1.4 Choose a method

1.1.5 Validate the source path and discover hosts

Blocks: 1; revisit after new routes or hosts. Operational procedure | Quick sheet

1.1.5.1 Purpose and result

A source-qualified reachable-host list and a defensible discovery limitation.

1.1.5.2 Recognition clues

No response, a new subnet, or uncertainty about the interface and route.

1.1.5.2.1 Find the clue from your starting access

Where to investigate: From the assessment host inspect the assigned interface and the route to the exact target before interpreting silence.

Discovery action — reference example:

Access/context: An explicitly assigned address or host list and a known source position

ip addr
ip route get TARGET
nmap -sn SUBNET -oA host-discovery

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

TARGET via VPN_GATEWAY dev tun0 src SOURCE_IP
Nmap scan report for HOSTNAME (TARGET)
Host is up

Recognize this detail: The route names the intended interface/source; a responder is evidence from that source, not a global reachability claim.

Still missing before method selection: Check scope, target state and whether host-discovery probes are permitted by this path.

If you do not yet have this clue: start with this topic's discovery workflow.

1.1.5.3 Prerequisites

Starting access: An explicitly assigned address or host list and a known source position. Required conditions: Correct VPN/interface and explicit scope; discovery probes must be compatible with the path.

1.1.5.4 Discover and verify prerequisites

ip addr
ip route get TARGET
nmap -sn SUBNET -oA host-discovery

1.1.5.5 Why it works

Discovery probes identify responders; silence can be caused by filtering. A known assigned host can still require a port scan that skips discovery.

1.1.5.6 Execute and choose variants

Purpose: Confirm the source path and discover explicitly assigned hosts before spending time on port coverage.

1.1.5.6.1.1 Check the path

From the target's working folder:

mkdir -p scans
ip -br addr
ip route get TARGET

nmap -sn -n -oA scans/host TARGET

nmap -sn -n -iL targets.txt -oA scans/hosts

nmap -sn -n -oA scans/subnet SUBNET

1.1.5.7 Worked example — hypothetical

Observation: a known host is absent from the ping sweep. Test: confirm the route and scan its selected application port with discovery skipped. Illustrative output: TCP/443 is open. Interpretation: discovery missed a live service; retain the host and enumerate HTTPS.

1.1.5.8 Verify the result

Record source address/interface, route and the exact responding endpoint; a missing ping response does not prove a host is down.

1.1.5.9 Failure and fallback

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.

1.1.5.10 Continue from the interpreted result

1.1.6 Enumerate reachable endpoints from a Windows source

Blocks: 1; revisit after new routes or hosts. Operational procedure | Quick sheet

1.1.6.1 Purpose and result

Selected TCP reachability from the Windows network position.

1.1.6.2 Recognition clues

The useful vantage point is a Windows host without Nmap.

1.1.6.2.1 Find the clue from your starting access

Where to investigate: From the Windows foothold inspect interfaces/routes, then check an assigned internal host's selected service ports.

Discovery action — reference example:

Access/context: An explicitly assigned address or host list and a known source position

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Test-NetConnection TARGET -Port 445

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

InterfaceAlias   : ADAPTER
SourceAddress    : SOURCE_IP
RemotePort       : 445
TcpTestSucceeded : True

Recognize this detail: The service is reachable from this Windows source; this can reveal a useful vantage point unavailable from Kali.

Still missing before method selection: Confirm application/authentication and whether a forward or a native client can use that route.

If you do not yet have this clue: start with Validate the source path and discover hosts.

1.1.6.3 Prerequisites

Starting access: An explicitly assigned address or host list and a known source position. Required conditions: A permitted Windows shell, explicit target list and built-in networking support.

1.1.6.4 Discover and verify prerequisites

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Test-NetConnection TARGET -Port PORT

1.1.6.5 Why it works

A local TcpClient or Test-NetConnection uses the host's route and firewall context. Results from Kali do not substitute for reachability from this source.

1.1.6.6 Execute and choose variants

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

1..1024 | % {echo ((New-Object Net.Sockets.TcpClient).Connect("DC_IP", $_)) "TCP port $_ is open"} 2>$null

22,80,443,445,3389 | % {echo ((New-Object Net.Sockets.TcpClient).Connect("TARGET", $_)) "TCP port $_ is open"} 2>$null

1.1.6.7 Worked example — hypothetical

Observation: Kali cannot reach an internal WinRM endpoint. Test: check TCP/5985 from the Windows foothold. Illustrative output: TcpTestSucceeded is True. Interpretation: a new route/source exists; choose a forward or run an authorized native client there.

1.1.6.8 Verify the result

Associate each result with the actual Windows source and selected port; do not claim UDP or full-port coverage.

1.1.6.9 Failure and fallback

A false result may be routing, filtering or service absence; use route and listener evidence before deciding the service is down.

1.1.6.10 Continue from the interpreted result

1.1.7 Discover TCP ports with SYN or connect scans

Blocks: 1; revisit after new routes or hosts. Operational procedure | Quick sheet

1.1.7.1 Purpose and result

A saved TCP port-state inventory with explicit coverage.

1.1.7.2 Recognition clues

An assigned host needs an initial service queue or full TCP coverage.

1.1.7.2.1 Find the clue from your starting access

Where to investigate: After path validation, compare a first TCP pass with explicit full-port coverage; record skipped discovery or privilege limitations.

Discovery action — reference example:

Access/context: An explicitly assigned address or host list and a known source position

nmap -Pn -sT --top-ports 1000 TARGET -oA tcp-initial
nmap -Pn -sT -p- TARGET -oA tcp-full

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Initial selection: 22/tcp open ssh; 80/tcp open http
Full selection also: 18080/tcp open unknown

Recognize this detail: The high listener exists outside the first selection; its application label remains provisional.

Still missing before method selection: Confirm scan completion, source, errors and application behavior on each interesting port.

If you do not yet have this clue: start with Validate the source path and discover hosts.

1.1.7.3 Prerequisites

Starting access: An explicitly assigned address or host list and a known source position. Required conditions: SYN scanning needs raw-packet privileges; connect scanning needs OS TCP connections; specify selected versus full port coverage.

1.1.7.4 Discover and verify prerequisites

nmap -Pn -sT --top-ports 1000 TARGET -oA tcp-initial
nmap -Pn -sT -p- TARGET -oA tcp-full

1.1.7.5 Why it works

SYN and connect scans infer reachability differently but both cover only their selected ports. A common-port scan is a prioritization pass, not full TCP coverage.

1.1.7.6 Execute and choose variants

Purpose: Get quick leads, complete TCP coverage, and adapt scan type, discovery handling, timing and output to the access path.

1.1.7.6.1.1 Get initial TCP results

sudo nmap -sS -n -oA scans/tcp-initial TARGET

sudo nmap -sS -n -iL targets.txt -oA scans/tcp-initial-list

nmap -sT -n -oA scans/tcp-connect TARGET

sudo nmap -sS -n -p PORTS -oA scans/tcp-selected TARGET

sudo nmap -sS -n -p PORTS -iL targets.txt -oA scans/tcp-service-sweep

1.1.7.6.1.4 Discover listeners across the full TCP port range Complete TCP coverage

sudo nmap -sS -n -p- -oA scans/tcp-all TARGET

nmap -sT -n -p- -oA scans/tcp-all-connect TARGET

sudo nmap -sS -n -Pn --reason -p PORTS -oA scans/tcp-recheck TARGET

sudo nmap -sS -n -Pn -p- -oA scans/tcp-all-no-discovery TARGET

sudo nmap -sS -n -p- -T3 --stats-every 30s -oA scans/tcp-normal TARGET

sudo nmap -sS -n -p- -T4 --stats-every 30s -oA scans/tcp-faster TARGET

proxychains nmap -sT -Pn -n --top-ports 100 -oA scans/tcp-proxy-top100 TARGET

1.1.7.7 Worked example — hypothetical

Observation: the initial scan exposes SSH and HTTP. Test: finish full TCP selection. Illustrative output: an additional management service appears on a high port. Interpretation: add it to the queue before committing to a web-only path.

1.1.7.8 Verify the result

Retain the selected port set, source context, completion/errors and raw output; follow open ports with focused application evidence.

1.1.7.9 Failure and fallback

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.

1.1.7.10 Continue from the interpreted result

1.1.8 Probe UDP and resolve ambiguous silence

Blocks: 1; revisit after new routes or hosts. Operational procedure | Quick sheet

1.1.8.1 Purpose and result

UDP responders and documented open/filtered uncertainty.

1.1.8.2 Recognition clues

TCP enumeration is incomplete for the objective or DNS/SNMP/RPC clues suggest UDP.

1.1.8.2.1 Find the clue from your starting access

Where to investigate: Inspect discovery results and DNS/SNMP/RPC clues, then probe a separate bounded UDP selection from the same source.

Discovery action — reference example:

Access/context: An explicitly assigned address or host list and a known source position

sudo nmap -Pn -sU --top-ports 20 --reason TARGET -oA udp-initial

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

161/udp open|filtered snmp no-response
53/udp open domain udp-response

Recognize this detail: A DNS response confirms a UDP application; open|filtered SNMP silence is a candidate requiring a correctly formatted request.

Still missing before method selection: Check accepted service parameters, response identity and possible ICMP rate limiting.

If you do not yet have this clue: start with Validate the source path and discover hosts.

1.1.8.3 Prerequisites

Starting access: An explicitly assigned address or host list and a known source position. Required conditions: Raw-packet access and UDP reachability from the real source; bounded or full selection must be explicit.

1.1.8.4 Discover and verify prerequisites

sudo nmap -Pn -sU --top-ports 20 --reason TARGET -oA udp-initial
sudo nmap -Pn -sU -sV -p 53,161 TARGET -oA udp-focused

1.1.8.5 Why it works

A UDP service may ignore an empty probe; ICMP errors and application responses distinguish states. Silence alone cannot distinguish open from filtered.

1.1.8.6 Execute and choose variants

Purpose: Sample UDP separately, preserve ambiguous states, and expand only when the objective or evidence warrants it.

1.1.8.6.1.1 Check UDP separately

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 -p PORTS -oA scans/udp-selected 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

sudo nmap -sS -sU -n -p T:22,80,445,U:53,123,161 -oA scans/tcp-udp TARGET

1.1.8.7 Worked example — hypothetical

Observation: UDP/161 is open|filtered. Test: a correctly formatted SNMP request with a justified community. Illustrative output: system OIDs return. Interpretation: SNMP is confirmed accessible; enumerate useful branches.

1.1.8.8 Verify the result

Use an application response for a confirmed service; document unresolved silence, coverage and ICMP rate-limit effects.

1.1.8.9 Failure and fallback

Do not translate UDP silence into a closed service. Retry a focused application-aware probe or a different permitted vantage point.

1.1.8.10 Continue from the interpreted result

1.1.9 Identify applications and validate selected NSE checks

Blocks: 1; revisit after new routes or hosts. Operational procedure | Quick sheet

1.1.9.1 Purpose and result

Application and version evidence sufficient to choose service enumeration or an exploit candidate.

1.1.9.2 Recognition clues

A listener has a port-based label or uncertain version.

1.1.9.2.1 Find the clue from your starting access

Where to investigate: Take the discovered open-port list and request protocol/version evidence rather than choosing attacks from conventional port numbers.

Discovery action — reference example:

Access/context: An explicitly assigned address or host list and a known source position

nmap -Pn -sV -p PORTS TARGET -oA selected-services

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

18080/tcp open http APPLICATION_SERVER
Service detection performed

Recognize this detail: An HTTP response on a nonstandard port routes investigation to application mapping; a product string is still only fingerprint evidence.

Still missing before method selection: Verify normal requests, hostname/TLS requirements and exact build/configuration before selecting an exploit.

If you do not yet have this clue: start with Validate the source path and discover hosts.

1.1.9.3 Prerequisites

Starting access: An explicitly assigned address or host list and a known source position. Required conditions: A reachable selected port; scripts must match the application and permitted assessment behavior.

1.1.9.4 Discover and verify prerequisites

nmap -Pn -sV -p PORTS TARGET -oA selected-services
nmap --script-help SCRIPT_NAME

1.1.9.5 Why it works

Port numbers and banners suggest a protocol; application responses and exact configuration constrain an exploit. NSE results remain candidates when the check cannot prove the vulnerable condition.

1.1.9.6 Execute and choose variants

Purpose: Identify applications on discovered ports and choose only the probing needed for the next decision.

1.1.9.6.1.1 Identify discovered applications

nmap -sT -n -sV -p PORTS -oA scans/tcp-services TARGET

nmap -sT -n -sV -sC -p PORTS -oA scans/tcp-services-default TARGET

nmap -sT -n -sV --version-light -p PORTS -oA scans/tcp-services-light TARGET

nmap --script-help http-headers

nmap -sT -n -p PORTS --script http-headers -oA scans/http-headers TARGET

sudo nmap -n -O -oA scans/os TARGET

sudo nmap -n -O --osscan-guess -oA scans/os-guesses TARGET

sudo nmap -sS -n -A -oA scans/combined-detail TARGET

1.1.9.7 Worked example — hypothetical

Observation: port 8443 is labelled HTTPS but the product is unknown. Test: version probes and a normal HTTP request. Illustrative output: a named management product and login route. Interpretation: map authentication and verify the build before exploit selection.

1.1.9.8 Verify the result

Preserve the responding product/version evidence and distinguish an inferred fingerprint from a confirmed vulnerable build.

1.1.9.9 Failure and fallback

A timeout, generic banner or scanner label leaves identity inconclusive; use native protocol clients or the unknown-port method.

1.1.9.10 Continue from the interpreted result

1.1.10 Discriminate unknown listeners and use scanner alternatives

Blocks: 1; revisit after new routes or hosts. Operational procedure | Quick sheet

1.1.10.1 Purpose and result

A validated listener/protocol candidate rather than an unverified scanner finding.

1.1.10.2 Recognition clues

A nonstandard listener, slow TCP discovery or a scanner-specific candidate.

1.1.10.2.1 Find the clue from your starting access

Where to investigate: Select an unexplained listener from the saved queue, compare native connection behavior, then use focused version/TLS probes.

Discovery action — reference example:

Access/context: An explicitly assigned address or host list and a known source position

nmap -Pn -sV --version-all -p PORT TARGET
nc -nv TARGET PORT

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

PORT/tcp open ssl/http APPLICATION
HTTP/1.1 302 Found
Location: https://HOSTNAME/

Recognize this detail: TLS and an HTTP redirect suggest a hostname-selected web application rather than an attack tied to the port number.

Still missing before method selection: Reproduce the hostname/TLS request and confirm exact software/configuration.

If you do not yet have this clue: start with Validate the source path and discover hosts.

1.1.10.3 Prerequisites

Starting access: An explicitly assigned address or host list and a known source position. Required conditions: Explicit bounded scope; raw scanning alternatives need their required privileges and conservative rates.

1.1.10.4 Discover and verify prerequisites

nmap -Pn -sV --version-all -p PORT TARGET
nc -nv TARGET PORT

1.1.10.5 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.

1.1.10.6 Execute and choose variants

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.

1.1.10.6.1.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.

rustscan -a TARGET -r 1-1000 --ulimit 5000 -- \
  -Pn -sV -sC -oA rustscan-1000

1.1.10.6.1.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.

1.1.10.6.1.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/

1.1.10.6.1.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.

1.1.10.6.1.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

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

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.

1.1.10.7 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.

1.1.10.8 Verify the result

Confirm the endpoint through independent application behavior and preserve the rate/scope used for discovery.

1.1.10.9 Failure and fallback

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.

1.1.10.10 Continue from the interpreted result

1.1.11 Validate uncertain results and rebuild the service queue

Blocks: 1; revisit after new routes or hosts. Operational procedure | Quick sheet

1.1.11.1 Purpose and result

An evidence-labelled queue of endpoints, access contexts and next tests.

1.1.11.2 Recognition clues

Scanners disagree, a result is ambiguous, or a new identity changes accessible behavior.

1.1.11.2.1 Find the clue from your starting access

Where to investigate: Compare saved scan results with one direct connection and a service-native request for the endpoint that changes your next decision.

Discovery action — reference example:

Access/context: An explicitly assigned address or host list and a known source position

nc -nvz TARGET PORT
nmap -Pn -sT -p PORT --reason TARGET

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Connection to TARGET PORT succeeded
PORT/tcp open SERVICE syn-ack

Recognize this detail: Independent TCP reachability supports an endpoint candidate, not credentials, read permission or execution.

Still missing before method selection: Identify the application and validate the particular next-layer action.

If you do not yet have this clue: start with Validate the source path and discover hosts.

1.1.11.3 Prerequisites

Starting access: An explicitly assigned address or host list and a known source position. Required conditions: A selected endpoint and a test that can resolve the decision-changing uncertainty.

1.1.11.4 Discover and verify prerequisites

nc -nvz TARGET PORT
nmap -Pn -sT -p PORT --reason TARGET

1.1.11.5 Why it works

A TCP connection proves transport reachability, not successful protocol authentication or useful rights. Re-enumeration is required when identity or route changes.

1.1.11.6 Execute and choose variants

Purpose: Resolve uncertainty that affects a decision, preserve coverage limits, and turn scan output into a service-enumeration queue.

1.1.11.6.1.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.

nc -nv -w 3 -z TARGET PORTS

nc -nvv -w 3 -z TARGET PORTS

sudo nmap -sS -n -v --reason -p PORTS -oN scans/tcp-check.txt TARGET

1.1.11.6.1.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

1.1.11.6.1.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.

1.1.11.7 Worked example — hypothetical

Observation: one scan calls a port filtered while Netcat connects. Test: repeat the focused scan and speak the application protocol. Illustrative output: a service banner returns. Interpretation: keep the application evidence and investigate timing/source differences.

1.1.11.8 Verify the result

Record which layer was demonstrated: transport, application, authentication, read/write or execution.

1.1.11.9 Failure and fallback

Connection success with no useful response needs a protocol-aware test; repeated identical failures without new evidence do not justify repeating the same path.

1.1.11.10 Continue from the interpreted result

1.1.12 Sources and shared concepts

Supplied PEN-200 Ch 6 pp136–165. Nmap scan techniques, port selection, NSE.

Commands and their adjacent variant conditions are synchronized extracts of the linked operational procedures. Those procedures own complete execution details; this guide owns method selection, explanations and worked reasoning. Tool availability on the learner's Kali or a target must be checked in that environment.