After a port scan, build a service inventory before choosing an exploit. The useful result is a record of what answered, how you identified it, what you have actually tested, and what remains uncertain.
This guide covers four checks for your identified, isolated Kioptrix target: scan coverage, service identity, application behavior and vulnerability prerequisites. For help choosing between competing next actions, use the separate next-step guide.
1. Record what the scan covered
Save the exact command, target identity, time and output files. Note TCP or UDP, the selected ports, whether the scan completed, and whether host discovery affected the run. A default Nmap scan checks a commonly used subset of TCP ports; an omitted port is not a negative test result. UDP requires its own testing.
| Result | What it supports | What it does not prove |
|---|---|---|
| Open | An application accepted traffic on that port under the test conditions. | Its product, exact version, authentication policy or vulnerability. |
| Closed | The port was reachable but no listening application was detected. | That no service can appear later or through another interface. |
| Filtered | Nmap could not determine whether the port was open because probes or responses were blocked or otherwise unavailable. | That a service exists behind the filter. |
| Open|filtered | The probe could not distinguish the two states. | A confirmed listening service. |
These are scan observations from your vantage point, not permanent properties of the VM. See Nmap’s state definitions for the full set of states.
Keep coverage gaps explicit. If a scan was interrupted, record it as incomplete. If the host was skipped, verify identity and network conditions before changing discovery options. Do not broaden the scan to a home or workplace subnet just because the target did not answer.
2. Separate a port label from an identified service
A familiar port number is a starting hypothesis. Use protocol responses and, when appropriate, version detection to refine it. Replace all placeholders below; OPEN_PORTS means the comma-separated ports selected from your own results.
mkdir -p evidence nmap --version nmap -sT -n -sV -p OPEN_PORTS -oA evidence/E002-service-identification TARGET_IP
This is a focused TCP connection and version-detection example, not a complete host assessment. Use a new output basename if the files already exist. Record failed probes and uncertainty as well as product matches.
Nmap version detection sends probes and compares responses. Its output is stronger than a port-name lookup, but it still needs interpretation. Confirm important details through another appropriate observation rather than converting a banner into a vulnerability claim.
3. Test the behavior of the service you actually found
HTTP: compare responses, not just status codes
Record the exact scheme, address, port and path. For an HTTP listener, start with the browser and a bounded request:
curl -I --connect-timeout 5 --max-time 15 http://TARGET_IP:HTTP_PORT/
-I requests headers using HEAD. If the application does not support HEAD, compare with an ordinary browser GET request before diagnosing a failure. Use HTTPS only when that is the identified protocol, and record certificate errors rather than hiding them.
Compare the intended path with one deliberately nonexistent path. Record status, redirect destination and relevant body differences. A 200 response can be a custom error page; a redirect may lead every request to a login page. These controls help you recognize false positives before using a directory discovery tool.
Check visible links, page source and authentication boundaries. Record a hostname dependency if redirects or links reveal one, and verify that the hostname belongs to this lab before configuring local resolution. Do not assume that every Kioptrix image uses the same hostname.
SMB: identify the stage that failed
| Stage | Record separately |
|---|---|
| Transport | Could the client reach the observed SMB port? |
| Negotiation | Did the client and server agree on a protocol dialect? |
| Authentication | Was the supplied identity accepted, rejected or not tested? |
| Authorization | Which operation on which share was actually allowed? |
Keep the exact client error. A negotiation failure is not proof that credentials are wrong; a successful session is not proof of access to every share. Legacy lab services can conflict with current client defaults. Investigate a specific compatibility requirement in the isolated lab instead of globally weakening client security settings.
Other protocols
Use the protocol’s own evidence. A connection greeting, documented help response or access-denied message can narrow the next question. Keep authentication attempts bounded and relevant to the exercise; a large password attack is not a substitute for understanding an exposed service.
4. Check applicability before calling a lead a finding
For each vulnerability lead, write down the affected product and version, architecture, required features, authentication level and any configuration dependency. Then mark each prerequisite confirmed, contradicted or unknown. If the lead requires a feature you have not observed, the lead remains provisional.
Preserve this distinction in your inventory:
Observed: [literal response and evidence ID] Identified service: [product/protocol, basis and uncertainty] Research lead: [source and claimed prerequisites] Confirmed prerequisites: [evidence IDs] Unknown or contradicted prerequisites: [specific gaps] Next test: [one question, expected observation and stopping condition]
Do not run an exploit merely because its title contains a matching version string. Read the implementation and prerequisites, consider its effects on the VM, and use the intended exercise scope. The Kali tools guide explains where local exploit research fits in the workflow.
Record one service
Use sanitized notes only. This form does not submit or automatically save your entries; reloading clears them. Generate and download a draft before leaving. It does not test your VM or verify your claims.
Finish with a reviewable inventory
Create one record per relevant service. Unexamined services stay marked unexamined. A defensible inventory makes it possible to explain why you selected a path and why other paths remain open. Keep the underlying command history in your session notes, then promote supported claims into the report template.