Use this guide to finish your first Kioptrix Level 1 session with a setup record, one saved scan and one next question. If the appliance is not ready, use the download page or VM import guide. If it is ready, start the scan here.
Before your first Kioptrix Level 1 scan, establish five things: the correct image, a compatible host, the intended network boundary, the target’s current identity and a usable recovery point. This page is a first-session preflight, not a walkthrough or a promise that every host can run the appliance.
Keep the intentionally vulnerable target in a lab you control. Test only the identified VM. A private address, a running VM window or a host-only label does not by itself establish the full boundary.
Confirm Level 1 (#1), not a similarly named release
The VulnHub listing for Kioptrix: Level 1 (#1) identifies Kioptrix_Level_1.rar, a VMware-format Linux VM and automatically assigned addressing. Level 1.1 (#2) is another release. Match the listing and archive before using someone else’s instructions.
Compare the downloaded file with the checksum published for that exact archive. A match is an integrity comparison with the published value; it does not make an intentionally vulnerable VM secure. Preserve the original archive and extract a working copy. Use the download guide for the download-specific checks.
Five preflight checks and the evidence each needs
| Check | Record before continuing | If unresolved |
|---|---|---|
| 1. Image and compatibility | Release, source, archive, extracted file types, host architecture and hypervisor version. | Resolve import or architecture compatibility first. |
| 2. Stable boot | Observed console state and any exact error. | Diagnose the boot stage; a network scan cannot repair it. |
| 3. Intended boundary | Every enabled adapter, exact virtual-network identity, addressing and any outbound or host path. | Inspect the configuration before probing. |
| 4. Current target identity | VM MAC or other independent identifier matched to its current address, with time and source. | Do not treat the first discovered address as the target. |
| 5. Recovery | Snapshot or working-copy reference, its contents and what restoration has actually been checked. | Establish a recovery method before state-changing experiments. |
Compatibility and file handling
A working ARM Kali guest does not establish that an older x86 target will run in the same environment. Check the target architecture and the hypervisor’s support before adjusting RAM, disks or adapters. The VM import guide separates archive, configuration, architecture and boot problems.
Open the appropriate supplied VM configuration in compatible software. Do not rename a virtual disk to OVA or overwrite it with a blank disk. Preserve descriptor and extent files together when the disk format uses them.
Network boundary and addressing
For a first local exercise, choose a deliberate host-only or internal VM network. In VirtualBox, host-only includes the host; an internal network connects the selected VMs without a host interface by default and still needs addressing. Ordinary per-VM NAT and shared NAT Network behave differently. See Oracle’s networking documentation.
Audit extra adapters, port forwards and host/Kali forwarding or sharing. Keep the target off a bridged physical LAN and unintended outbound connections. If you update Kali on another network, keep the target off and recheck the lab adapters afterward. Use the network setup guide for the full mode comparison.
Identity and recovery
Record the target MAC in the VM settings and compare it with an appropriate lease or scoped discovery observation. Host-only discovery can also show the host interface or a DHCP service; these are not additional targets. Recheck identity after resets and addressing changes.
A guest login prompt may be sufficient evidence that boot progressed; it is not automatically a demand to reset the console password. A snapshot is a state reference, not a separate backup. Write what is included, keep original files separately and preserve notes outside any state you may roll back.
Start with a local observation you can explain
ip -br addr
ip route
ip route get TARGET_IPReplace TARGET_IP with the address already tied to the target identity. These checks help you inspect Kali’s interface and selected route. They do not establish a remote service or prove isolation. Record the device, selected source and any next hop.
When the setup evidence is present, choose a scoped baseline using the Kali tools guide. Save the command, coverage and completion status. Use the Level 1 walkthrough and hints for the investigation, rather than repeating setup instructions here.
Setup reviewed? Choose the next task
- One setup condition is still unknown: use the blocker table and record one bounded action in your manifest. Do not count an unchecked condition as resolved.
- Target and boundary are established, but no scan is saved: follow the first-run guide to save an Nmap baseline. Keep the command, coverage and actual result.
- A baseline is saved and you want the next investigation step: use the result interpretation guide, or open walkthrough step 2: service enumeration when you want guided investigation and later hints.
Before leaving: generate and copy or download your setup manifest. This page cannot inspect your VM or preserve an unsaved draft after reload.
A completed setup record you can compare with your own
Fictional teaching example. These values explain what a useful record looks like. They are not recommended settings for every host and are not evidence that this configuration was boot-tested. Replace every value with observations from your environment.
| Field | Example entry |
|---|---|
| Image | Original Level 1 (#1), Kioptrix_Level_1.rar; source URL and local digest saved in the session note. |
| Host and VM software | x86-64 host; installed hypervisor version copied from its About screen; supplied VMware configuration retained. |
| Lab connection | Named host-only segment lab-l1, DHCP enabled; every adapter reviewed; host is also on this segment. |
| Target identity | VM adapter MAC matched to its current lease, giving example address 192.168.56.101. |
| Kali route | Example Kali address 192.168.56.10; route to the target selects the recorded lab interface. |
| Recovery | Baseline snapshot name and original archive location recorded; restoration status stated separately. |
| Next task | Save one baseline TCP scan; no claim yet about UDP, vulnerabilities or root access. |
If you cannot fill one of these fields, use the relevant preflight check above. If you can, continue here; you do not need to open another guide just to save your first scan.
Run and read your first saved scan
Use the address you already matched to the target. In the commands below, 192.168.56.101 is an example, not an address to discover by trial and error. Start in a new session folder so the output names are unused.
mkdir -p evidence
ip route get 192.168.56.101
nmap --version
nmap -sT -n -oA evidence/E001-first-scan 192.168.56.101Read the route before running Nmap. Stop if it selects an unexpected adapter or network. The scan uses TCP connect scanning; -n skips reverse DNS and -oA writes three output formats. The default scan covers common TCP ports, not all TCP ports or UDP. If it reports the target down, return to identity and reachability before changing discovery options.
After completion, read evidence/E001-first-scan.nmap. Keep its companion .xml and .gnmap files. Check that the run completed and that the target address is correct. A file existing is not proof that a scan succeeded.
Invented excerpt for reading practice:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssnYour first note could say: “Three ports answered in this selected TCP scan. The labels suggest SSH, HTTP and SMB-related services. Versions and vulnerabilities are not yet verified; UDP remains untested.” If your output differs, retain your result rather than copying these rows.
Make one follow-up choice
| Your actual result | Next useful action |
|---|---|
| One or more open ports | Use -sV -p with those observed ports; follow the worked tool session for a completed example. |
| Host down or no expected response | Recheck target MAC/IP, route, boot and network membership. Keep the exact message. |
| Filtered ports | Record the uncertainty and inspect the permitted path. Filtered does not mean closed. |
| A saved, explained service inventory | Move to walkthrough step 2 for investigation and optional hints. |
First-session finish line: keep the setup manifest, the original scan files, a short interpretation and one next question. Root access is not required to complete this first session. References: Nmap output formats and port states and coverage.
Stop at the first unresolved setup stage
| Symptom | Next useful check |
|---|---|
| Archive or import error | Exact message, file completeness, format and architecture. |
| Boot error | Attached disk and original hardware assumptions; change one setting at a time. |
| No target address | Stable boot, adapter/cable, exact network and DHCP or static addressing. |
| Address found but identity unknown | Compare the VM identifier with lease or discovery evidence. |
| Ping silence | Identity, route and discovery method; silence alone does not establish absence. |
| Unexpected physical devices or outbound paths | Reinspect adapters, sharing and routing before continuing. |
For help, share a sanitized environment summary and exact error. Keep unrelated addresses, account information and personal paths out of the public copy. A failed preflight is a specific setup task to resolve, not a verdict on your ability.
Build a Level 1 setup manifest
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.
Review the generated manifest against the real configuration. It does not inspect your VMs or certify the network. Keep it with your session notes and update it when the environment changes.
Finished reviewing the manifest? Continue to the first saved scan, or resolve the remaining setup condition.
First-session update: October 24, 2026. Added a completed illustrative setup record and a first-scan exercise. No VM boot or network test was performed for this editorial update.