The essential Kali Linux tools for a first Kioptrix session are Nmap, a browser, curl and a notes file. Use Gobuster when you have a specific reason to look for more web paths. This guide helps you save a first scan, read the result and choose one next check.
Before running commands: use an isolated training lab you control and test only the VM you have identified. Replace uppercase placeholders with your own verified values. Outputs labelled Illustrative output are teaching examples, not results captured from a new Kioptrix run.
Choose the tool for your next task
| Your task | Start here | You are done when… |
|---|---|---|
| Find the intended VM | Network and target checks | You have matched its current IP to its VM identity. |
| Find responding TCP ports | Nmap baseline | You have saved the output and checked completion. |
| Understand a web response | Browser and curl | You have compared a real page with a missing page. |
| Investigate more web paths | Optional Gobuster exercise | You have manually checked one candidate, or recorded no useful result. |
| Research an identified product | Documentation and SearchSploit | You can explain whether the lead fits your observed service. |
1. Confirm the network and target IP
Run in: Kali terminal. First inspect your interfaces and routes. Compare them with the network configured in your hypervisor.
Commands — inspect your own Kali environment
ip -br addr
ip route
nmap --iflistLook for: the interface attached to your named lab network and its address. A VPN or second adapter can change the route. Your interface may have a different name from another person’s example.
I still do not know which address is Kioptrix
Read the target VM’s MAC address in the hypervisor, then match it with its current DHCP lease or a discovery result. The host and DHCP service may also appear on the segment.
On a confirmed dedicated local lab segment, this optional command uses the selected interface’s configured range. Replace LAB_IF before running it.
sudo arp-scan --interface=LAB_IF --localnetARP discovery works on the local link. It does not identify your intended target for you. Match the returned MAC before proceeding. See the Kali arp-scan reference and lab network setup checks.
Once the IP is matched, check which route Kali will use. Replace TARGET_IP with that one address.
ip route get TARGET_IPIf the route is unexpected: resolve the adapter or network setting before scanning. If the VM cannot boot, start with the VM import checklist.
Done: you can name the target IP, the VM identity you matched and the intended lab interface. Write those in your session note, then continue.
2. Run one Nmap scan and save the result
Run in: Kali terminal. Open a new folder for this session. Record nmap --version in your notes. Replace TARGET_IP before running the scan below.
Commands — first TCP baseline
mkdir -p evidence
nmap -sT -n -oA evidence/E001-baseline TARGET_IP-sT uses TCP connect scanning; -n skips reverse DNS lookups. -oA saves three output formats. This is a default TCP port selection, so other TCP ports and UDP remain outside this scan.
Open the text result in the same session folder:
cat evidence/E001-baseline.nmapKeep the .xml and .gnmap files too. Use a new basename for another run so you retain the previous result. See Nmap output formats.
Read the STATE column before choosing another tool
Illustrative output — shortened teaching example; your ports may differ
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssnWhat to notice: these three rows say open. Start with ports from your output; you do not need to reproduce these numbers. The service labels are initial clues, not confirmed product versions.
| Your result | What to do next |
|---|---|
open | Choose a responding service and check it more closely below. |
closed | Keep the observation and review other tested ports. It says nothing about untested ports. |
filtered | Review the intended route and network configuration. Nmap could not determine whether that port is open. |
| Host appears down or the scan stops | Save the exact message and return to target and route checks. A missing inventory is not proof that every port is closed. |
For the full state definitions, use the Nmap port-state reference.
Ask Nmap about the selected services
Replace OPEN_PORTS with the comma-separated open ports you want to inspect, and replace TARGET_IP. For the illustrative output above, the selected list would be 22,80,139.
nmap -sT -n -sV -p OPEN_PORTS -oA evidence/E002-services TARGET_IPLook for: a product or version response in the saved service output. If no version appears, record that result; you can investigate the service next. A version match is a research lead, not a confirmed vulnerability.
The command failed or I cannot find the output file
command not found: check the tool’s availability in your Kali installation. An invalid port or address message: check that you replaced the uppercase placeholders. A missing file: confirm the scan’s working folder, basename and any write error. Read the original error before changing scan options.
Done: the scan has completed, you can open its saved output and you have chosen one service to inspect. If that service is HTTP, continue below. For another protocol, use the service interpretation guide.
3. Compare a web page with a page that does not exist
Open in: Kali browser. Use the scheme and port you actually observed. For an HTTP service, the template is http://TARGET_IP:HTTP_PORT/. Note the visible page, any login prompt and redirects.
Run in: Kali terminal. Record curl --version, then replace TARGET_IP and HTTP_PORT in both commands. Keep using the session folder containing evidence.
Commands — save the home page and a missing-page comparison
curl -sS --connect-timeout 5 --max-time 15 -D evidence/E003-home.headers -o evidence/E003-home.html -w 'status=%{http_code} bytes=%{size_download}
' http://TARGET_IP:HTTP_PORT/
curl -sS --connect-timeout 5 --max-time 15 -D evidence/E004-missing.headers -o evidence/E004-missing.html -w 'status=%{http_code} bytes=%{size_download}
' http://TARGET_IP:HTTP_PORT/kioptrix-control-missing-7f39Read the status, then compare the saved content
Illustrative output — possible responses, not a promised result
Home page: status=200 bytes=1200
Missing page: status=404 bytes=280What this tells you: the service handled the two paths differently in this example. The missing-page response gives you a comparison for checking later discoveries.
If both return 200, compare the saved bodies and headers. The application may return its error page with a success status. Size alone is not enough to decide whether content differs.
The browser or curl result differs from the example
- Connection refused or timeout: recheck the observed address, port, route and service availability.
- 301 or 302: inspect the saved
Locationheader. These commands do not follow redirects automatically. Confirm the destination belongs to your lab before opening it. - HTTPS or protocol error: retain the exact error and investigate the observed service’s scheme and compatibility.
- A header-only check differs:
curl -Isends HEAD; the commands here send GET. The server may handle those differently.
See the curl option reference.
Done: you have saved and compared two responses. Record one difference, or the fact that they look alike. Continue to Gobuster only if more web paths are a useful next question.
4. Try a small Gobuster exercise when needed
Run in: Kali terminal. This optional exercise creates a three-entry list, avoiding an assumed system wordlist path. It demonstrates the workflow; it is not a comprehensive search. Record gobuster --version and review gobuster dir --help for your installed version.
Commands — create the small teaching list
mkdir -p wordlists
printf '%s
' robots.txt icons test > wordlists/lab-paths.txtReplace the address and port below. The wordlist now has a known location relative to your session folder.
gobuster dir -u http://TARGET_IP:HTTP_PORT/ -w wordlists/lab-paths.txt -t 5 -o evidence/E005-paths.txtLook for: candidate paths to check in the browser. Compare one candidate with the missing-page response from step 3. A status code or a redirect alone does not establish useful content.
Gobuster reports an error, similar responses or no useful result
- Wordlist cannot be opened: check the session folder and that the list creation completed.
- Unknown option: compare the command with your installed version’s help.
- Wildcard or repeated responses: return to the missing-page comparison. Inspect content and redirects before excluding a status or length.
- No useful paths: record the list and result. This small list cannot establish that no other paths exist; you may still have completed a useful check.
Reference: Kali Gobuster documentation.
Done: you have manually checked a candidate or documented that this list added no useful lead. Choose the next question from the results already saved.
5. Research a service only after identifying it
Use the product and version evidence from your service checks to read the maintainer’s documentation or original advisory. Compare the affected versions, platform, configuration and access requirements with your VM.
Optional tools: SearchSploit, Nikto and Metasploit
SearchSploit: search a product you actually identified. Replace PRODUCT_NAME in this local search:
searchsploit "PRODUCT_NAME"A matching title is a lead to investigate. Check the original entry and prerequisites. See Kali ExploitDB documentation.
Nikto: use it when web configuration or known-file checks answer a specific question. Verify the response behind each lead.
Metasploit: consider a relevant module after checking its prerequisites, options and effects. Hydra and password guessing are outside this starter inventory workflow.
Done: you can say which conditions match, which conflict and which remain unknown. An unsupported lead can be set aside; you do not need to force a successful exploit.
Finish with one result you can explain
Before ending the session, check that you have the target identity, tool versions, exact commands, saved output and one next question. A saved scan and a clear interpretation are useful progress even when the whole VM is unfinished.
See a completed teaching note
Illustrative note: the following describes fictional observations.
Target: matched to the lab VM MAC before scanning.
E001/E002: selected TCP ports responded; UDP remains untested.
E003/E004: home page 200; missing-page response 404.
E005: one candidate redirects; destination still needs review.
Conclusion: HTTP responds; the candidate needs another check.
Next action: inspect the redirect and compare its destination.
Recovery: record the actual snapshot or working-copy reference.Keep your session note here while you work
Use sanitized notes from your own lab. This field stays only in the current page; copy it before leaving or reloading. There is no automatic saving or submission.
Choose your next task: Interpret a service you found, plan one investigation check, or open the Level 1 walkthrough when you want hints and spoilers. Keep the original files with your lab notes. tmux can preserve a detached shell while its server runs; save files separately for recovery after a reboot.
Editorial update: October 26, 2026. Reorganized the existing examples into task-based steps, added result branches and completion checks, and simplified the wording. Examples remain illustrative. No new VM scan or exploit run was performed for this update. Earlier command documentation review: October 24, 2026. Author and evidence policy.