Kali Linux Tools for Kioptrix: Nmap, curl and Gobuster

The essential Kali Linux tools for a first Kioptrix session are your terminal, Nmap, a browser, curl and a notes file. Add another tool only when you can name the question it will answer. You do not need to run every scanner, use Metasploit or guess passwords to complete the initial inventory.

Commands below are examples for your own identified, isolated lab VM. Replace uppercase placeholders with verified values. They are not captured Kioptrix results and should not be pasted unchanged.

Choose by question, not by popularity

Check the local environment before discovering targets

ip -br addr
ip route
nmap --iflist
nmap --version

Compare the interface and network with the hypervisor configuration. A VPN, wireless adapter or second VM adapter can change routing. Do not derive a target range from whichever address happens to appear first. Use the network setup guide to confirm the intended boundary.

On a confirmed dedicated local lab segment, ARP discovery can help match a VM MAC address to an IP:

sudo arp-scan --interface=LAB_IF --localnet

LAB_IF is Kali’s verified lab interface. --localnet derives the range from that interface’s address and netmask; it does not know which devices you intended to test. ARP works on the local link, not across arbitrary routed networks. Compare the returned MAC with the VM configuration before treating an address as the target. See the official Kali arp-scan reference.

Use Nmap to save a baseline, then ask a narrower question

mkdir -p evidence
nmap -sT -n -oA evidence/E001-tcp-baseline TARGET_IP
nmap -sT -n -sV -p OPEN_PORTS -oA evidence/E002-service-check TARGET_IP

The first example uses TCP connect scanning and skips reverse DNS lookups. It is a baseline, not an all-port or UDP assessment. For the second, replace OPEN_PORTS with the selected comma-separated ports from your own output. Version detection probes services; it does not confirm exploitability.

Use a new basename for each run. Record missing coverage and interruptions. If discovery skips the VM, first verify its identity and connection; do not assume “host down” means the appliance failed to boot. An intentional discovery change should be documented with its reason.

The enumeration guide explains how to interpret states and build a service record. Nmap’s output documentation explains the files produced by -oA.

Read the result before choosing another tool

Keep the literal result separate from your interpretation. These are illustrative decision checks, not output captured from a Kioptrix run.

Nmap’s port-state reference explains why a state describes the scanner’s observation. Record the source, options and coverage with every conclusion.

Find your saved baseline: -oA evidence/E001-tcp-baseline produces .nmap, .xml and .gnmap files using that basename. Read the normal text output first and retain the other files. A file on disk does not by itself prove the scan completed; check the output for completion and errors.

Browse first; automate a specific web question

Open the observed service using its actual scheme and port. Record visible paths, redirects, authentication prompts and relevant page source. A header request can provide a small repeatable observation:

curl -I --connect-timeout 5 --max-time 15 http://TARGET_IP:HTTP_PORT/

HEAD requests can behave differently from GET. Compare with the browser if the response is unexpected. Test a deliberately nonexistent path to learn the application’s error behavior before interpreting a list of discovered URLs.

Gobuster: optional path discovery

gobuster dir --help
gobuster dir -u http://TARGET_IP:HTTP_PORT/ -w WORDLIST_PATH -t 5 -o evidence/E003-web-paths.txt

Choose an existing, relevant wordlist and read the installed version’s help. Start with modest concurrency. If a run reports wildcard responses, stop and examine the control request rather than suppressing the warning blindly. Check each promising result in the browser: a status code alone may reflect a custom error or login redirect. Kali’s Gobuster reference documents directory mode and current options.

Nikto: an optional source of leads

Nikto can identify web configuration and known-file leads, but it generates many requests and needs manual verification. Run it only when that question is useful in your lab. Save its output and reproduce the specific response behind a claim. It is not a required step for every VM.

Use SearchSploit for local research, not proof

searchsploit --help
searchsploit "PRODUCT_NAME"

Search with a product you actually identified. Open the relevant entry and compare affected versions, platform, authentication, configuration and expected effects. A title match does not establish applicability. Kali’s ExploitDB documentation describes the local search utility.

Metasploit is useful when a relevant module fits verified prerequisites and you understand its options and side effects. It is not a replacement for service identification. Password guessing tools such as Hydra introduce another testing method with their own assumptions; they are unnecessary for the starter workflow presented here.

A small, repeatable session checklist

1. Confirm the lab boundary and target identity.
2. Save one baseline scan and state its coverage.
3. Identify relevant services with focused checks.
4. Record a literal observation, an uncertainty and a next test.
5. Add an optional tool only when it resolves that uncertainty.
6. Close with a snapshot reference and resume point.

Keep the commands and evidence in your lab notes. A terminal multiplexer such as tmux can preserve a shell session after detachment while its server remains running; it does not make sessions survive a host reboot. Save evidence to files regardless.

If the VM never reaches a stable boot state, return to VM import checks. If it boots but cannot be identified on the lab network, resolve that boundary before adding more scanners.