Identify applications and validate selected NSE checks
Needs: A reachable selected port; scripts must match the application and permitted assessment behavior
4. Identify discovered applications
Purpose: Identify applications on discovered ports and choose only the probing needed for the next decision.
# 4. Identify discovered applications
nmap -sT -n -sV -p PORTS -oA scans/tcp-services TARGET
# Identify applications on discovered ports
nmap -sT -n -sV -sC -p PORTS -oA scans/tcp-services-default TARGET
# Lighter version probing when time or fragile service behavior matters
nmap -sT -n -sV --version-light -p PORTS -oA scans/tcp-services-light TARGET
# 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
# 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
Next: choose service-specific enumeration from application evidence. A version match alone does not establish exploitability.
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.
OS guesses are hypotheses. These use default TCP coverage;
-Adoes 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. More detail ↓
Explanation & examples
Identify applications and validate selected NSE checks
- USE WHEN
- A listener has a port-based label or uncertain version
- STARTING ACCESS
- An explicitly assigned address or host list and a known source position
- RESULT
- Application and version evidence sufficient to choose service enumeration or an exploit candidate
Recognize the clue
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
18080/tcp open http APPLICATION_SERVER
Service detection performedMeans: An HTTP response on a nonstandard port routes investigation to application mapping; a product string is still only fingerprint evidence.
Confirm: Verify normal requests, hostname/TLS requirements and exact build/configuration before selecting an exploit.
- After validation
- Native protocol responses agree with the fingerprint: use that service's enumeration guide.
- Ruled out in this context
- A presumed SSH port instead speaks HTTP: discard the SSH-specific method for that endpoint.
- Still inconclusive
- Generic banners or timeouts do not identify a build; try protocol-aware/TLS discrimination.
Troubleshooting: A timeout, generic banner or scanner label leaves identity inconclusive; use native protocol clients or the unknown-port method.
Additional prerequisite checks
nmap -Pn -sV -p PORTS TARGET -oA selected-services
nmap --script-help SCRIPT_NAME
Purpose: Identify applications on discovered ports and choose only the probing needed for the next decision.
4. Identify discovered applications
Next: choose service-specific enumeration from application evidence. A version match alone does not establish exploitability.
Variants — default scripts, named scripts and OS fingerprints
Identify applications on discovered ports
Version probing plus the default NSE script set: use when those scripts answer relevant enumeration questions.
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:
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.
Select a named script
Inspect behavior locally:
After identifying HTTP, inspect its relevant port(s):
Returned headers are clues. Choose scripts for the question they answer and their behavior.
OS fingerprinting and bundled probing
Estimate OS from network-stack behavior:
Request more tentative OS guesses:
Bundle OS/version detection, default scripts and traceroute:
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.
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.
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.
New identity, privilege, host or route? Re-enumerate → All topic tasks →