Your first Kioptrix Level 1 run should leave you with an identified target, a saved baseline scan and one clear next question. Use this checklist after obtaining the original Level 1 (#1) image. Finish with a first-run record; use the separate walkthrough when you deliberately want solution hints.
1. Confirm the environment before scanning
The original Level 1 (#1) listing identifies Kioptrix_Level_1.rar, a VMware-format Linux VM with automatic DHCP addressing. Match the exact release and archive; Level 1.1 (#2) is another image. Check host CPU and hypervisor compatibility before treating a boot failure as a network problem.
Keep the intentionally vulnerable target on a controlled lab segment. Host-only networking includes the host; NAT may allow outbound traffic. Do not switch to a shared bridged network as a shortcut. If the network boundary is unclear, use the setup preflight before sending probes.
2. Identify the target rather than guessing an address
In Kali, inspect local interface and route information:
ip -br addr
ip route
nmap --iflistCompare those observations with the hypervisor’s configured lab network. Record the target VM’s adapter MAC and match it to its current DHCP lease or discovery result. A vendor name, familiar service mix or single responding address is only a clue; it does not independently identify the target.
If the address remains unknown, follow the host-only address troubleshooting guide. Record the exact symptom and stop at the unresolved setup stage. A failed ping alone does not prove that the VM is offline; do not widen discovery to your household or workplace network.
3. Save one baseline against the confirmed VM
Replace TARGET_IP with the address you matched to the intended VM. It is a placeholder, not a shell variable. Choose an unused output basename for each run; change first-run-01 if those files already exist.
mkdir -p evidence
nmap --version
nmap -sT -n -oA evidence/first-run-01 TARGET_IP-sT selects TCP connect scanning, -n skips reverse DNS resolution and -oA writes normal, XML and grepable output using the chosen basename. This is an initial TCP baseline, not all-port or UDP coverage. The command can still perform host discovery before port scanning; if the target is skipped or the run fails, record that rather than reporting a completed inventory.
Open evidence/first-run-01.nmap and retain the associated .xml and .gnmap files. Check warnings and completion status. Record the command, Nmap version, date, source interface and coverage together. The Kali tools result guide explains what common states support and what remains unknown.
4. Close the first run with one bounded conclusion
Illustrative wording: “The recorded TCP baseline returned these port states from this source VM. Other TCP ports and UDP remain unassessed. My next question is whether one observed service can be identified more precisely.” Replace that example with your own result, including failures.
Keep three things separate: the literal output, what it suggests and the check that would resolve the next uncertainty. An open port does not establish a vulnerability. You do not need a shell or root access to produce a useful first-run record.
If the run did not finish
- No stable boot: record the console error and use the import and boot checks.
- No identified address: review the virtual network, MAC and DHCP evidence before scanning.
- Scan error or target skipped: save the exact message, source route and command. Missing results are not proof that no service exists.
- Different output from a tutorial: compare the release, target identity, options and target state before repeating commands.
Working note: Preserve a first-run manifest
Replace the prompts with your own authorized lab evidence. Select the completed text and copy it to a local note before leaving. This field is not submitted or saved; reload clears edits. Do not enter passwords, tokens or personal data.
Related task: Continue with the related practical guide.
5. Choose the next guide from your result
- Target identified: plan the first service checks.
- Need a tool or output explanation: use the Kali reference.
- Want research and solution hints: continue to the Level 1 walkthrough.
- Prefer independent practice: follow the beginner roadmap.
First-run questions
Does completing the checklist mean the VM is secure?
No. These are self-recorded setup checks for an intentionally vulnerable target. They do not verify isolation automatically or make the guest safe for everyday use.
Must the first session reach root?
No. This page ends at a saved baseline and a next question. The walkthrough covers the later investigation and privilege-verification stages.
Will this page save my notes?
No. The checkboxes and working note are local to the open page and clear on reload. Copy your record to your own notes before leaving.
References and review scope
Editorial update: October 21, 2026. Release identity follows the linked VulnHub listing. Scan-method and output explanations were checked against Nmap’s scan-technique reference and output reference. The workflow is guidance for your own authorized lab; no new VM boot, scan or exploit execution was performed for this update.