This Kioptrix Level 1 beginner guide takes you from checking your VM setup to saving and reading your first Nmap scan. Finish with a setup note, the original scan files and one next question. You can complete a useful first session without solving the whole machine.
Lab scope: use an isolated training environment you control and test only the identified VM. Keep the vulnerable target off your physical LAN and unintended outbound connections. The checks below help you review your setup; this page cannot inspect or certify it.
1. Check these five things before your first scan
For each check, open the named place, compare what you see and tick the statement only when you have reviewed it. Record unknown items in your lab setup note. The checkboxes clear on reload and do not calculate a safety score.
Check 1 — Match the image and the computer running it
Where to look: the original VulnHub release listing, your downloaded archive, your host’s system information and your hypervisor’s About or version screen.
What to compare: original Level 1 (#1) uses Kioptrix_Level_1.rar, a VMware-format Linux VM with automatic DHCP addressing. Level 1.1 (#2) is a different release. Compare the checksum for the exact archive with the published listing; retain the original archive and work from an extracted copy.
Write the host CPU architecture and VM software version. A working ARM Kali VM does not establish that an older x86 target can run in the same software. Check the hypervisor’s guest support before changing RAM or disks.
If these do not match: resolve the image, architecture or import issue with the VM file and compatibility checklist. Renaming a disk to OVA does not convert it; keep related disk files together.
Check 2 — Compare both VMs’ network settings
Where to look: the network-adapter settings for both Kali and Kioptrix, plus the virtual-network configuration in the hypervisor. Review these before powering on an unfamiliar vulnerable target. Menu names vary by product and version.
Compare these items:
- Network name: both lab adapters must join the intended virtual segment. A similar-looking mode name alone is not enough.
- Adapter status: the intended adapter is enabled and its virtual cable is connected.
- Addressing: identify the DHCP service or deliberate address plan. The original target expects DHCP.
- Every extra adapter: inspect bridged or outward-facing adapters, port forwarding, and host/Kali routing or sharing.
Which network modes should I distinguish?
In VirtualBox, host-only networking also includes the host. Internal networking connects selected VMs without a host interface by default and still needs addressing. Ordinary per-VM NAT differs from a shared NAT Network; a NAT Network can permit outbound traffic. Use Oracle’s mode comparison for the details.
Keep the target away from bridged physical networking and unintended outward paths. If Kali uses another adapter for updates, keep the target off while updating and review the lab configuration afterward. See the lab network setup guide for the full comparison.
If the two VMs use different segments or the path is unclear: resolve the configuration before probing. Changing scan flags is not the first repair.
Check 3 — Observe what happens when the target boots
Where to look: the target VM’s console window, after reviewing its network settings in check 2.
What to record: whether the guest reaches a stable screen, such as a login prompt, or stops with an exact error. A login prompt can show that boot progressed; you do not need to reset its password merely to start investigating it from Kali.
If it stops: record the message and inspect the attached existing disk and supplied configuration. Use the import and boot guide before changing controllers or creating replacement disks. A network scan cannot fix a boot error.
Check 4 — Confirm which IP belongs to Kioptrix
Where to look: the target VM adapter’s MAC address in its settings, then the current DHCP lease or a discovery result on the confirmed local lab segment.
What to compare: match the VM’s MAC to the address record and note when you checked it. The host interface and DHCP service can also appear; the first IP you see is not automatically your target.
I have the VM MAC, but cannot find its IP
Confirm stable boot, cable connection, exact virtual-network name and the DHCP service first. In Kali, inspect ip -br addr to find the interface attached to that dedicated lab segment.
Optional local discovery — run in Kali terminal: replace LAB_IF with the verified lab interface before running:
sudo arp-scan --interface=LAB_IF --localnet--localnet derives the range from that interface’s configuration. Use it only on the confirmed dedicated lab segment. Match the returned MAC with the target settings; ARP discovery is local-link discovery, not a way to identify arbitrary routed targets. Reference: Kali arp-scan documentation.
If the match is unknown: return to the address and adapter checks. Recheck the address after a reset or network change.
Check 5 — Keep a way to return to the starting state
Where to look: your original archive’s storage location, the working VM folder and the hypervisor’s snapshot controls.
What to record: keep the original archive, identify a clean working copy or supported baseline snapshot, and note what it includes. A snapshot is a return point within the VM workflow; a separate backup protects against different failures. Keep your notes outside any state you might roll back.
If you have not tried a restore: write “restore not checked.” Distinguish an available recovery reference from a verified restore. Establish the recovery method before later experiments that change the target.
Ready for the next step? You should have the intended image, a compatible and running VM, a reviewed lab network and a matched target IP. Resolve unknown setup items before scanning. A checkbox beside an error does not mean the error is fixed.
2. Check the route, then pause to read it
Run in: Kali terminal. Replace TARGET_IP with the current IP you matched in check 4. The command below inspects Kali’s selected route.
ip route get TARGET_IPIllustrative output: these addresses and interface names are invented for explanation.
192.168.56.101 dev eth1 src 192.168.56.10Read three parts: the first address is the destination; dev eth1 is the selected interface; src 192.168.56.10 is the source address. Your values may differ. If a via gateway appears, compare it with your intended network design rather than treating it as an automatic error.
Pause here. Compare the selected interface and path with check 2. If they are unexpected, fix the adapter or route before continuing. A selected route alone does not prove that the guest responds or the network is isolated.
Done: you can explain which interface Kali will use to reach the identified target. Now run the separate scan step below.
3. Save your first Nmap scan
Run in: Kali terminal. Open a new session folder so the output names below are unused. Record the version first:
nmap --versionReplace TARGET_IP with the same verified address. Run this block only after reviewing the route above:
mkdir -p evidence
nmap -sT -n -oA evidence/E001-first-scan TARGET_IPWhat the options do: -sT uses TCP connect scanning, -n skips reverse DNS and -oA saves three output formats. This default scan covers a selection of common TCP ports; other TCP ports and UDP remain untested.
When it finishes, open the normal text output from the same folder:
cat evidence/E001-first-scan.nmapCheck: the target address, the completion or error message and the port-state rows. Retain the companion .xml and .gnmap files. A file can exist even when a run was interrupted. Use a different basename for a later scan.
The command failed or the file is missing
- Command not found: check whether Nmap is available in this Kali installation.
- Address error: check that you replaced
TARGET_IPwith the matched target address. - Host appears down: keep the exact output and recheck boot, target identity, network and route before changing discovery options.
- File not found: confirm the working folder and output basename, and inspect any permission or write error.
4. Read one result and choose what to do next
Illustrative output: a shortened teaching excerpt, not a scan captured for this article.
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssnLook at STATE first. These example rows report open ports. The service names are initial labels; versions and vulnerabilities still need investigation. Keep your own output if it differs.
| Your actual result | Your next step |
|---|---|
| One or more open ports | Write down the ports you found. Check the selected services with Nmap. |
| Filtered ports | Record the uncertainty and review the permitted network path. Filtered does not mean closed. |
| Closed ports without a useful service | Record the tested coverage and review the scan and setup. Untested ports remain unknown. |
| Host down or incomplete scan | Use the setup troubleshooting steps; save the error rather than inventing a service inventory. |
Example interpretation: “Three ports responded in this selected TCP scan. I still need to check the services and versions. UDP was not tested.” Adapt this to your actual result.
Your first-session finish line: keep a setup note, the original scan files, a short explanation and one next question. That is a complete useful first exercise. References: Nmap output formats and port states and scan coverage.
If setup still fails, find the first step that is not working
| What you see | Open and compare |
|---|---|
| Archive or import error | Compare the exact archive and extracted file types with the VM import guide; check architecture support. |
| Guest boot error | Read the VM console error, then inspect the supplied configuration and attached disk. |
| No target IP | Compare boot state, adapter connection, virtual-network name and DHCP configuration. |
| An IP appears but you cannot identify it | Return to the MAC-to-IP comparison. |
| Ping receives no reply | Compare identity and route; ping silence alone does not prove the VM is absent. |
| Unexpected physical devices or outward paths | Review every adapter and any sharing or forwarding before continuing. |
For help, save the exact message and a sanitized description of your host, hypervisor, VM and network. Leave out unrelated addresses, personal paths and account details. A setup error identifies the next task to solve; it does not measure your ability.
Save your lab setup notes
Fill the fields from what you actually observed. You can leave an item unknown and name the next check. Generate the draft, then copy, download or print it before leaving.
Use sanitized notes only. Entries stay in this page and clear on reload. Generate a draft before copying, downloading or printing. The form records your review; it cannot test your VM.
See a completed teaching example
Fictional setup note: the values below show how to write a record; they are not a tested configuration or universal settings.
- Image: original Level 1 (#1), source and local checksum comparison saved.
- Computer: host architecture and installed hypervisor version recorded; guest support checked.
- Network: named host-only segment, DHCP service identified; host also present; other adapters and routing reviewed.
- Target: VM MAC matched to its current lease; example IP
192.168.56.101. - Route: selected lab interface checked against VM settings.
- Recovery: original archive and baseline snapshot recorded; restore not yet checked.
- Next action: save and interpret one selected TCP scan.
Choose the next task from your result
Setup complete but no scan yet? Review the route and run the first scan. Scan saved? Read the result and choose the next tool. Want solution hints? Open the Level 1 walkthrough’s service investigation; later sections contain spoilers.
Keep the generated record with your lab notes and update it after changing the environment.
Editorial update: October 26, 2026. Added concrete places and criteria for setup checks, separated route review from scanning, simplified the wording and connected the first-scan result to the tool guide. The setup-note generator and export options are retained. Examples are illustrative; no new VM boot, network scan or restore test was performed for this update.