Scan Results and Next Actions

← Reference index · Previous: UDP scanning · Next: Windows network checks | Strategy map | Study methods: Discover attack surfaces

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

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

Variants — Netcat verification, response reasons and readable output

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.

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.

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

Interpretation cues — preserve what the scan actually established

open establishes a reachable endpoint from the scan source; it does not establish a vulnerability or usable authentication.
closed records an explicit rejection in that context. Move on unless later evidence changes the route, source or target state.
filtered leaves the listener state unresolved because filtering, loss or the path prevented classification.
unfiltered means 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|filtered is inconclusive. A useful protocol probe may reduce uncertainty, but another silence can remain inconclusive.
closed|filtered is 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.

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