Kioptrix Lab: 4 Essential Checks for Better First Sessions

Open the practical working record to connect this guide to your scope, evidence and next decision.

Make setup success explicit

Record the image, architecture, adapters, target identity and successful baseline observation. Keep evidence outside rollback and note what a reset will discard. Suggested time limits are organizational examples. A slow setup does not establish a skill deficit, and a working VM does not prove the intended network boundary. Reference and scope.

Choose a Task and Identify Missing Prerequisites

Choose a specific release and a bounded learning task. A guided setup, service observation or documented reproduction can be useful without requiring an independent end-to-end compromise.

VulnHub presents Kioptrix Level 1 as an easy challenge intended to teach basic vulnerability-assessment and exploitation techniques. Its published goal is to obtain root access, and the listing notes that the VM uses DHCP with an automatically assigned address.

A good first target for patient beginners

You do not need professional penetration-testing experience. You do need enough comfort with a terminal to inspect network information, save command output, read error messages, and resist the urge to replace every quiet command with a louder tool.

• Learners practicing host discovery, port scanning, and service enumeration
• Students who want a repeatable lab rather than a giant security-tool collection
• Career changers building evidence-based troubleshooting habits
• Help-desk or systems professionals learning how exposed services appear from another machine
• Beginners willing to document failed hypotheses instead of hiding them

For a wider preparation path, review the Kioptrix beginner lab guide before beginning. Readers who need more networking context may also benefit from the Kioptrix guide for networking beginners.

Pause if Linux still feels invisible

Kali Linux is convenient, but convenience is not the same as simplicity. Kali’s own documentation says the distribution is designed for professional penetration testing and security auditing, and it may not be a friendly starting point for people who are unfamiliar with Linux administration or the command line.

• You cannot yet distinguish your host computer from your attacker VM.
• Terms such as subnet, gateway, interface, port, and service still blur together.
• You expect a graphical application to identify and exploit the target automatically.
• You are considering attaching the vulnerable VM directly to a workplace or public network.

If those concepts are unfamiliar, use a guided exercise to identify the host, guest and network boundary. No fixed preparation time establishes readiness. The Kioptrix guide for Linux beginners can help close that gap before the lab begins consuming your Saturday.

The boundary that keeps the lab legitimate

Define the scope in one sentence before you scan: “My permitted target is the identified Kioptrix VM; the testing VM is used to perform only the activities recorded in this exercise scope.”

That sentence sounds almost ceremonial, but it prevents a common beginner error. When bridged networking displays the router, printer, television, phones, and family laptops beside the target, curiosity can drift faster than judgment. A written scope is a small fence with a very useful gate.

Review the official Kioptrix Level 1 listing

Check 1: Verify the Actual Virtual-Network Boundary

The virtual network is not administrative wallpaper. It decides which machines can see the vulnerable VM, whether the attacker has internet access, and whether your scan results contain only the lab or half the devices in your home.

NAT, bridged, host-only, and internal are not interchangeable

Network mode	Typical visibility	Internet access	Beginner concern	Best use in this lab
NAT	Guest usually reaches outward through the host	Usually available	Two separately NATed guests may not communicate as expected	Useful for attacker updates, often as a second adapter
NAT network	Guests on the same named NAT network can usually communicate	Usually available	Easy to confuse with basic per-VM NAT	Outbound connectivity; unsuitable for the vulnerable target’s offline segment
Host-only	Host and attached guests	Not normally available without another adapter	Requires the correct shared host-only network	Clear beginner lab with limited exposure
Internal network	Only guests using the same internal network name	No, unless you build routing separately	The host cannot inspect the network as easily	Strong isolation for a self-contained lab
Bridged	Guest appears on the physical LAN	Usually available through the LAN	Vulnerable target may sit beside real devices	Usually unnecessary for a first Kioptrix session

Oracle’s VirtualBox documentation describes host-only networking as a way to create a network containing the host and selected virtual machines without relying on the host’s physical network interface. That separation is one reason host-only networking is often easier to reason about in a beginner lab.

A practical beginner arrangement is one isolated adapter shared by Kali and Kioptrix. Add a separate NAT adapter to Kali only when you need updates or documentation access. Keep Kioptrix offline: its vulnerable services should have no NAT, bridged, or internet-facing adapter. When Kali needs updates, power off the target and temporarily use NAT on Kali, then disable NAT before restarting the target. Host-only includes the host, so disable forwarding and internet sharing.

For a fuller diagram of these choices, see the Kioptrix home lab network layout and the focused Kioptrix network setup guide.

The isolation test to run before scanning

Do not begin with Nmap. Begin with four confirmations.

1. Open each VM’s adapter settings and confirm the same host-only or internal-network name, with no outward route for the target.
2. Boot Kali and inspect its active interfaces, assigned addresses, and routing table.
3. Confirm the lab subnet is different from your household or workplace subnet.
4. Check that Kioptrix is not attached to a bridged adapter or another interface that exposes it beyond the lab.

On Kali, commands such as ip addr and ip route answer different questions. The first shows addresses attached to interfaces. The second shows where Kali intends to send traffic. Read both before assuming that an interface with an address is the interface your scan will use.

Verify an address before using it as the target

Kioptrix Level 1 is configured to receive an address automatically, which means a reboot, network change, or DHCP reset can produce a different target address.

• The Kali address: You scan the attacker because it is the first private address you see.
• The host address: You mistake the host-only adapter on Windows, macOS, or Linux for the target.
• The gateway: You scan the first address in the subnet and discover a router-like service.
• An old lease: You reuse yesterday’s target address after rebooting the virtual network.
• A household device: Bridged mode places unrelated devices inside the search area.

Compare independent identity evidence such as the VM adapter MAC address and hypervisor DHCP information. Service resemblance and power-state observations are supporting clues, not unique identity proofs. One responsive host is evidence of a responsive host. It is not yet evidence of Kioptrix.

Read the official VirtualBox networking guide

Check 2: Keep a Described Recovery Point

A vulnerable VM is useful partly because it can be restored. Without a clean restore point, every later failure carries an extra question: is the test wrong, or did an earlier test change the machine?

Snapshot before curiosity takes over

Create snapshots at moments that answer a clear recovery question. “Snapshot 1” is not a useful name. “Kioptrix imported, isolated adapter confirmed, never scanned” is.

Snapshot	When to create it	What it lets you recover
Clean target	After import, boot test, and network confirmation	The original vulnerable machine state
Ready attacker	After Kali updates, folders, and core tools are prepared	A stable workstation without repeated setup
Pre-exploit target	After enumeration and immediately before active testing	A known baseline for repeated exploit validation
Post-access review	After access, before deeper inspection	A temporary state for documentation and comparison

The Kioptrix snapshot strategy offers a more detailed naming and recovery structure. The important principle is simple: every snapshot should have a purpose, not merely a timestamp.

What a snapshot protects you from

• Accidental service or permission changes
• Broken virtual adapters
• Reversible guest changes when the snapshot and required disk chain remain intact
• Unclear post-exploitation state
• Repeated package installation experiments on Kali
• The creeping suspicion that the target is no longer original

A snapshot is not an independent backup: it may depend on the same base disk and host storage. Keep separate backups for disk corruption, failed imports, or host-storage loss. Snapshots also protect the quality of your conclusions. If a technique works only after three undocumented changes, you have not demonstrated a clean path. You have demonstrated that something eventually happened.

Do not clone chaos

A clone preserves the current state, including damaged adapters, stale addresses, altered services, and mysterious configuration experiments. Cloning a malfunctioning VM gives the malfunction a twin.

Restore to the last state you can describe confidently. Then change one variable, record it, and test again. Slow-looking troubleshooting often becomes the fastest route because it leaves footprints you can follow backward.

Find the Target, Not the Whole Neighborhood

Target discovery deserves its own stage. It is not an inconvenient prelude to the “real” scan. It is how you establish that the machine receiving your later probes is the machine you intended to test.

Start with host discovery, not a blind port scan

Nmap’s official documentation treats host discovery as a distinct process that reduces a range of possible addresses to active or interesting hosts. It also explains that -sn performs discovery without following it with a port scan, while -Pn skips discovery and treats specified targets as active.

1. Identify Kali’s lab-facing interface.
2. Read the address and subnet assigned to that interface.
3. List or discover hosts only inside the authorized lab subnet.
4. Compare responsive addresses with DHCP, MAC, and VM information.
5. Run deeper scans only against the confirmed Kioptrix target.

For example, if Kali’s lab adapter is 192.168.56.10/24, the likely local range is 192.168.56.0/24. In an isolated lab you control, a discovery scan such as nmap -sn 192.168.56.0/24 can help identify responsive hosts. Do not copy that range blindly. Read your own interface configuration first.

The one-host assumption that ruins the lab

A quiet host-only network may show two or three addresses: Kali, the host adapter, and Kioptrix. A NAT network may also include a DHCP service or gateway. The first unfamiliar address is not automatically the target.

Compare several clues:

• Did the address appear only after Kioptrix booted?
• Does the MAC vendor or prefix fit the virtual hardware?
• Does the hypervisor’s DHCP information show a matching lease?
• Does the service profile look like an older Linux server rather than a modern host service?
• Does the address disappear when Kioptrix is powered off?

A before-and-after power-state observation may support identification, but leases, filtering and discovery behavior can confound it. Correlate it with the VM configuration and MAC or DHCP record; do not scan unrelated systems to establish exclusion.

Save the first scan before running the second

Beginners often improve a scan command and overwrite the evidence that led to it. Save output with a descriptive filename or use a supported output option so the first observation remains available.

• Date and local time
• Attacker interface and IP address
• Target IP and how it was verified
• Exact command used
• Open, closed, and filtered results that matter
• Service guesses and version clues
• Errors, timeouts, and unanswered questions

A practical folder structure might separate discovery, scans, web, service-notes, and screenshots. The Kioptrix recon log template provides a reusable starting point.

Open the official Nmap host discovery guide

Enumeration Before Exploitation: Read What the Services Reveal

An initial port scan is a table of contents, not the finished book. It tells you where to read next. It does not prove what every service is, whether the detected version is accurate, or which weakness applies.

Port numbers are labels, not conclusions

Keep three layers separate in your notes:

• Port state: What did the scanner observe about reachability?
• Detected service: What protocol or application does the scanner believe is responding?
• Actual software and version: What evidence confirms the implementation behind that response?

Port 80 commonly suggests HTTP, but the useful questions begin after that label. What server responds? Is there a redirect? Is a virtual host expected? Does the page expose a default installation, application clue, error message, or different behavior over TLS?

Web service: inspect before attacking

Start with what a normal client can observe. Open the page, inspect the response headers, review the source, follow obvious links, and record differences between HTTP and HTTPS. A simple request with a browser or command-line HTTP client can often clarify more than an aggressive web scanner launched without a question.

• Visible page text and default installation messages
• Response headers and server identifiers
• Redirect locations
• Page source comments and referenced files
• Error behavior for missing paths
• Directory or filename clues discovered through authorized enumeration
• Application languages, frameworks, or legacy components suggested by responses
• Differences between services on separate web ports

Automated web tools can be helpful, but they frequently produce warnings that require manual confirmation. A result is a lead, not a verdict. The Kioptrix HTTP enumeration guide shows how to organize those leads without turning the session into scanner confetti.

File-sharing service: enumerate its boundaries

A file-sharing service can reveal naming information, protocol behavior, available shares, access policies, and version clues. Keep discovery separate from authentication. Learning that a share exists is not the same as proving that you can read it, write to it, or authenticate anonymously.

• Which service ports answer?
• What protocol dialects appear to be supported?
• What host or workgroup names are advertised?
• Can share names be listed without credentials?
• Does listing succeed while access fails?
• Are resources read-only, writable, or inaccessible?
• Do multiple tools agree on the server version?

When two tools disagree, do not vote by majority. Record what each tool actually observed and which protocol exchange produced the claim. A polished tool name does not make its fingerprint immune to ambiguity.

SSH and remote access: evidence, not invitation

An exposed login service tells you that remote authentication exists. It does not tell you that password guessing is the appropriate first move.

Record the protocol version, banner, supported behavior, and whether other evidence suggests a legitimate credential path. Random guessing teaches little, creates noisy logs, and can distract from a far clearer vulnerability elsewhere.

Old banners can also lie by omission. Packages may contain backported fixes, vendors may alter version strings, and scanner fingerprints may be incomplete. Treat a version banner as the beginning of vulnerability research, never the final condition check.

Exploit Roulette Is Not a Learning Strategy

The internet can hand you an exploit name before you have finished reading the service output. That speed feels productive. It can also turn the lab into a slot machine where success and failure are equally unexplained.

The copy-paste exploit trap

A proof of concept may assume a particular operating system, software build, architecture, compiler, library, network path, or target configuration. If you do not know those assumptions, a failure tells you almost nothing.

• The exploit targets a similar product but a different version.
• The code expects another processor architecture.
• The source no longer compiles with modern defaults.
• A required library or header is missing.
• The target service is present, but the vulnerable feature is disabled.
• The exploit succeeds, but you cannot explain the weakness it used.
• The target crashes, leaving you unsure whether the condition was confirmed.

Before using public code, read it. Identify required arguments, network behavior, expected success signals, and obvious side effects. Keep the target snapshot ready. A lab gives you permission to test, not permission to stop thinking.

Build an evidence-to-hypothesis chain

This chain prevents vulnerability research from becoming a catalogue of exciting names. Each candidate weakness must connect back to an observed service and forward to a condition you can verify.

A five-sentence hypothesis can be enough:

1. I confirmed a specific network service on the target.
2. The service exposed a version or behavior associated with a known weakness.
3. The weakness requires these target conditions.
4. I verified these conditions and expect these success or failure signals.
5. I will restore the snapshot if the test alters stability or produces ambiguous results.

Do not fire every Metasploit module with a familiar name

Framework modules can reduce repetitive setup, but they do not remove the need to confirm compatibility. Before running a module, understand its target product, affected versions, required options, payload behavior, reliability notes, and expected side effects.

Question	Weak answer	Useful answer
Why this module?	The name matched a port.	The detected service, version, and required feature match the module’s conditions.
What does success look like?	A session appears.	A defined callback, shell, response change, or controlled error confirms the result.
What can go wrong?	It might fail.	The service may crash, the callback may be misconfigured, or the target may not match.
How will you verify?	Run it again.	Check the target state, session identity, logs, and reproducibility from a clean snapshot.

The Kioptrix Metasploit versus manual comparison can help you decide when automation supports learning and when it conceals too much of the mechanism.

When a manual method teaches more

Manual does not always mean typing more commands. It means exposing more of the reasoning. Reading a protocol exchange, checking source code, compiling a proof of concept in a controlled environment, or reproducing one condition at a time can show you where the weakness lives.

Automation is useful when you already understand the inputs and want repeatability. Manual validation is useful when the mechanism is still foggy. Choose the method that answers the learning question, not the one that looks most impressive in a screenshot.

Show me the nerdy details

A useful exploit decision is a small dependency graph. The service fingerprint supports a product hypothesis. The product and version support a vulnerability candidate. The candidate has preconditions such as architecture, feature state, request path, authentication level, or memory protection behavior. The selected test must exercise those conditions and produce an observable result.

When a test fails, classify the failure by layer: network delivery, protocol interaction, version mismatch, missing precondition, exploit implementation, payload delivery, callback routing, or post-access instability. “Exploit failed” compresses all of those possibilities into one unhelpful sentence.

Check 4: Describe the Result and Its Limits

Root access is a milestone. It is not a substitute for understanding. If the shell arrives and your notes contain only a copied command, the lab has become a magic trick performed by someone else’s reasoning.

Confirm the access you actually gained

Do not assume a prompt symbol proves identity or privilege. Record the session carefully.

• Current username
• User and group identifiers
• Hostname
• Current working directory
• Network interfaces and addresses
• Shell type and limitations
• Whether the session survives reconnection
• Whether access was direct or followed privilege escalation

Verification separates initial access from elevated access. It also reveals whether a framework opened a restricted shell, a service account, a privileged process context, or something less stable than the word “session” suggests.

The privilege boundary you may have skipped

Some paths produce elevated access quickly. That can hide the most valuable question: which trust boundary failed?

• Did a network service run with excessive privilege?
• Did a local program trust user-controlled input?
• Did file permissions expose a sensitive resource?
• Did an outdated component provide direct privileged execution?
• Did a configuration choice convert ordinary access into administrative access?

Name the boundary in plain English. A technically correct explanation that you can teach is worth more than a dramatic screenshot you cannot reconstruct.

Leave a record of what was actually performed

Complete this sentence before declaring the lab finished:

If repetition serves the learning goal, preserve needed evidence before restoring and recheck identity afterward. Use guidance as needed and record it. Do not report a planned reproduction as a completed one.

For a structured finish, use the Kioptrix checklist and compare your final record with the Kioptrix enumeration report format.

Common Kioptrix Mistakes That Quietly Drain Hours

The most expensive Kioptrix mistakes rarely look dramatic. They appear as five-minute shortcuts repeated until the afternoon is gone.

The mistake and the safer alternative

Common mistake	Why it wastes time	Safer alternative
Scanning before checking Kali’s interface	You assume a subnet that may not exist in the current session.	Record the active interface, address, prefix, and route first.
Using bridged mode for convenience	The target appears beside real devices and expands the scope unnecessarily.	Use a dedicated isolated virtual network.
Treating ping failure as proof of shutdown	Discovery depends on probe type, filtering, local ARP behavior, and routing.	Check VM state, adapters, ARP, routes, and alternative discovery evidence.
Trusting only the default port range	One profile cannot answer every port and protocol question.	Begin with a baseline, then expand scans for a stated reason.
Researching vulnerabilities before confirming services	Search results become a pile of unrelated exploit names.	Verify product, version, behavior, and preconditions first.
Changing five settings at once	When the lab works, you cannot identify the fix.	Change one variable, record it, and retest.
Presenting guided reproduction as independent discovery	The record obscures which decisions and observations were your own.	Attribute the source, explain the step and record your actual observation.
Recording only successful commands	You lose the reasoning that eliminated bad hypotheses.	Record failed tests, expectations, and revised conclusions.
Deleting the VM after root	You skip reconstruction, repetition, and report writing.	Restore, reproduce, and explain the full chain.

Spend smarter on the lab, not louder

Kioptrix does not require an expensive security subscription or a glowing tower of dedicated hardware. Check the selected image, host architecture and available resources before assuming the VM can run on your computer. Money becomes useful when it removes a real bottleneck, not when it adds another dashboard.

List the measured constraint, proposed change, cost and observation that would show whether it helped. An equipment tier is not a learning or readiness grade.

Before purchasing anything, identify the constraint. Is the laptop swapping memory? Are snapshots filling the disk? Is a second monitor genuinely improving documentation, or merely displaying more distracting tabs?

The security tool stack cost calculator can help compare free and paid options without turning the first lab into a shopping expedition.

Turn Failed Attempts Into a Reusable Lab Notebook

A lab notebook is not a transcript of everything the terminal printed. It is a record of decisions. The difference is the sentence that explains why an output mattered.

Use a four-column evidence log

Illustrative entries only — not a test log; add dates, time zones and artifact references to your own record.

Timestamp	Observation	Interpretation	Next test
10:15 AM	A new host responds after Kioptrix boots.	It may be the target, but identity is not confirmed.	Compare MAC and repeat discovery with the VM powered off.
10:22 AM	A web service responds on the confirmed target.	A normal HTTP observation may answer the next question.	Inspect headers, source, redirects, and normal page behavior.
10:41 AM	A version clue suggests an older component.	A known weakness may apply.	Verify affected versions and required target conditions.
11:08 AM	The first test fails before reaching the target.	The issue may be local compilation or configuration.	Separate tool setup from target compatibility.

Label statements visibly:

• Confirmed: Directly supported by output or repeated observation
• Likely: Supported by several clues but not yet verified
• Unknown: Important condition with no evidence yet
• Contradicted under stated conditions: Record the completed test and evidence against the particular claim

The Kioptrix note-taking workflow provides a fuller structure for commands, evidence, screenshots, and session summaries.

Screenshot less, annotate more

A screenshot preserves pixels. It does not preserve your reasoning. Add a filename and one sentence explaining why the output matters.

• 01-discovery-target-appears.png: The address appeared only while Kioptrix was running.
• 02-http-header-version-clue.png: The response suggests a product family that requires manual confirmation.
• 03-test-failed-local-error.png: Failure occurred before network traffic reached the target.
• 04-access-identity-confirmed.png: User and group checks confirm the privilege obtained.

Capture the smallest useful area, protect unrelated personal information, and avoid filling the notebook with ten nearly identical terminal images. One annotated image can carry more meaning than a gallery of black rectangles.

Write the dead ends down

Record unsuccessful attempts when they matter to the next decision. An incomplete or inconclusive attempt does not necessarily narrow the hypothesis.

• What did you expect?
• What actually happened?
• Was the failure local, network-related, service-related, or target-related?
• Which assumption was wrong?
• What evidence changed your direction?
• Would you repeat the test after restoring a clean snapshot?

Illustrative example: the scan that found the router

A beginner boots Kali and Kioptrix, remembers seeing a 192.168.1.x address in a tutorial, and scans the household subnet. One host responds with a web interface, so the learner spends forty minutes researching the server banner.

The page behaves strangely because it is not Kioptrix. It is the home router.

After checking ip addr, the learner notices Kali also has a host-only interface on a different subnet. A discovery scan there reveals another machine that disappears when Kioptrix is powered off.

The important lesson is not “scan the other subnet.” It is “derive the subnet from the current interface, then verify the target independently.” That habit transfers to every future lab, while memorizing an address range transfers only to disappointment.

If a session has become tangled, use the Kioptrix recovery routine instead of adding more tools to an already unclear state.

Check whether Kali Linux fits your current skill level

FAQ: First-Weekend Kioptrix Troubleshooting

Why can’t Kali find my Kioptrix VM?

The machines may be attached to different virtual networks, Kioptrix may not have received an address, Kali may be scanning through the wrong interface, or the chosen subnet may belong to the host’s physical network rather than the lab.

Check both VM adapter names, Kali’s interfaces and routes, the hypervisor’s DHCP information, and whether the target appears or disappears when Kioptrix is started or stopped.

Should Kioptrix use NAT, bridged, or host-only networking?

Use an internal or carefully configured host-only network for the vulnerable target. Host-only networking is clear when you want the host and both VMs to communicate. An internal network offers tighter guest-only isolation. A named NAT network can provide outbound access and should not be used as the default containment network for Kioptrix.

Bridged mode is rarely necessary for a first attempt because it places the vulnerable VM on the same physical network as unrelated devices.

Why can Kioptrix behave differently in VirtualBox and VMware?

Kioptrix Level 1 is distributed as a VMware-format virtual machine. Running an older appliance in a different hypervisor can require adjustments to disk controllers, adapter types, import settings, or other virtual hardware choices. Confirm the original VM format, take a clean snapshot, and change one compatibility setting at a time.

Do I need Kali Linux to complete Kioptrix?

No. Kali packages many useful security tools, but the methodology matters more than the distribution. Another authorized Linux environment can perform discovery, service inspection, note-taking, and controlled testing if the required tools are available.

Kali can also feel demanding to readers who are still learning ordinary Linux administration. Learning a few basic shell, networking, file-permission, and package-management skills first may make the Kioptrix session much calmer.

Should I use Metasploit on my first attempt?

Use it after you can state the detected service, likely version, required vulnerability conditions, module options, expected result, and possible side effects. Starting with a module search can conceal the reasoning the lab is meant to teach.

Is getting root enough to say I completed the lab?

It may satisfy the immediate technical objective. Document the access actually observed, the assistance used, the evidence and the limits. Restoration or reproduction can be separate follow-up tasks; mark them planned until performed.

Why does Nmap show different results after a reboot?

The DHCP-assigned target address may have changed, another interface may be active, the network mode may differ, the target may still be booting, or the new scan may use different discovery and port options. Compare the commands and network state before assuming the target changed its services.

Is it safe to connect Kioptrix to my home network?

Isolation is the safer default because Kioptrix is deliberately vulnerable. Avoid bridged placement where household devices can reach it. Use a dedicated virtual network, confirm adapter settings before booting, and restore or shut down the target when the authorized session ends.

A Resumable Checkpoint Before an Active Test

Before an active test, check the relevant target identity, permission, prerequisites, expected observations and recovery plan. Leave missing conditions unresolved rather than treating a completed checklist as proof of safety or success.

Now write five sentences: what you observed, what you believe, what must be true, how you will test it, and what result will make you continue or stop. Do this before opening another exploit page.

That note converts the session from command collecting into security practice. If the result is unclear, record it as inconclusive and state the next question instead of inventing a cause.

Last reviewed: 2026-08

Technical guidance updated: 2026-10-13. Kept the vulnerable target offline, clarified that snapshots do not replace independent backups, and repaired table-of-contents navigation.

Record the appliance version before debugging the exploit

Keep the exact Kioptrix level, download source, archive filename, published checksum, VM disk/controller settings, and hypervisor version in your lab record. The VulnHub Level 1 listing identifies a specific appliance; instructions for another level or a converted image may not reproduce on yours.

Compare the downloaded archive with the publisher’s checksum before importing. An old MD5 or SHA-1 checksum can help detect an accidental mismatch but is not a modern authenticity guarantee against a malicious replacement. Keep the source record and isolate the legacy appliance regardless. If it fails to boot, resolve the import or controller issue before treating absent network responses as a vulnerability-testing problem.

Editorial review: 16 October 2026. Examples are illustrative; this review does not represent an audit or live control test.

First-weekend lab readiness record

Use this when: you are a beginner preparing a contained VM exercise and a recoverable first session. Copy these fields into your notes and replace each prompt with a dated response. Keep assumptions and unresolved questions visible.

Suggested working record — add your own evidence

Field	What to record	Your evidence / owner / next check
Release and host	Record image version, source, hypervisor and host architecture.	To complete
Network proof	Identify intended lab peers and the boundaries checked.	To complete
Recovery proof	Record the baseline and what has actually been restored successfully.	To complete
Stop rule	Define the first bounded task and when to pause for a setup problem.	To complete

Next action: Demonstrate the recovery path before beginning an experiment that may alter the target. Mark the relevant row confirmed, provisional or unresolved. Keep the supporting record, responsible person and next check beside it so another reader can continue the work without treating an assumption as a result.

This is a blank practice record, not a report of a test performed by Kioptrix. Add the actual versions, approved conditions and observations from your own session.

Worksheet change record — October 20, 2026

Added this first-weekend lab readiness record with four article-specific fields and an evidence-based next action. Existing source notes retain their own review dates. This addition is not a fresh verification of every statement or a newly executed test.