Kioptrix Level 1 Walkthrough: 6 Steps, Hints and Evidence

This Kioptrix Level 1 walkthrough takes you through six steps: identify the target, save a service inventory, choose a research lead, document an attempt, verify the resulting identity and explain the outcome. It focuses on the original Level 1 (#1) image.

On this page

Evidence scope: the worked examples are explicitly illustrative. This revision checked documentation and improved the teaching sequence; it did not execute a new VM or exploit. For an independent full solution, use the original release’s walkthrough index linked below.

Preparing the machine? Use VM import checks, then your first saved scan. Already have results? Start at step 2. For command options, open the Kali tools reference and worked session.

Confirm the original Level 1 image

The VulnHub release entry identifies Kioptrix_Level_1.rar, a VMware-format Linux guest with automatic addressing. The challenge objective is root access, and the listing allows more than one solution. Level 1.1 (#2) is a different image.

Record the source, filename, checksum comparison, host architecture, hypervisor version and baseline snapshot. Do not assume a universal root.txt path. Completion evidence must come from the guest you actually investigated.

Before the six-step walkthrough

Use only your own identified target on a deliberate lab network. Review all VM adapters and any forwarding through Kali or the host; keep the vulnerable guest off bridged and unintended outward-facing connections. Host-only includes the host. An internal network needs an addressing plan. See Oracle’s network-mode documentation.

Keep the original archive and a recoverable working copy. Match the target MAC to its current address and exclude the host, DHCP service and other devices. Stop here if the machine will not boot or the target identity is uncertain.

Step 1: identify the target and save a baseline

Start in Kali by reading the local interface and route. Replace TARGET_IP with the address independently tied to the target VM; it is not the first address that happens to answer.

ip -br addr
ip route
ip route get TARGET_IP
nmap --version
mkdir -p evidence
nmap -sT -n -oA evidence/E001-baseline TARGET_IP

Run each session from a new working directory and use unused output basenames: rerunning a command can overwrite earlier evidence. The default scan normally checks the 1,000 most common TCP ports, not every TCP port and not UDP. The -sT option uses TCP connect scanning; -n skips DNS resolution; -oA writes normal, XML, and grepable output using the chosen basename. Keep terminal errors as well as output files.

Leave this step with: target identity, exact command, tool version, timestamp, coverage and the three output files. References: host discovery and Nmap output formats.

nmap -sT -n -p- -oA evidence/E001b-all-tcp TARGET_IP

Step 2: turn open ports into a service record

Illustrative excerpt, not a captured Kioptrix scan:

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
139/tcp open  netbios-ssn

In this example, replace OPEN_PORTS with 22,80,139, with no spaces. Use the open TCP ports from your own file rather than copying the example list. Replace TARGET_IP with your identified lab guest’s address:

nmap -sT -n -sV -p OPEN_PORTS -oA evidence/E002-services TARGET_IP

Keep literal output separate from your explanation. A failed service probe is useful evidence of an unresolved condition. See Nmap’s version-detection reference.

Step 3: inspect the web service and choose a research lead

Open the actual scheme and port observed on the target. Save a GET response and compare a deliberately nonexistent path. A default page can still reveal a service; it does not imply the SQL-injection login found in a different Kioptrix level.

curl -sS --connect-timeout 5 --max-time 15 -D evidence/E003-web.headers -o evidence/E003-web.html http://TARGET_IP:HTTP_PORT/

For the missing-path comparison, use a path you have not observed on the guest and save it under a different basename:

curl -sS --connect-timeout 5 --max-time 15 -D evidence/E004-missing.headers -o evidence/E004-missing.html http://TARGET_IP:HTTP_PORT/kl-check-missing-45

Compare the status code and content of E003 and E004. A 200 response can be a default or custom error page; it is not automatically a discovered resource. By default, curl may return success after transferring an HTTP 404 or 500 response, so check the saved response status separately. See curl’s HTTP response guide.

Read the saved status, headers and body. A redirect needs its destination checked; a legacy TLS error needs the exact message retained. Neither proves a vulnerability. The worked tool session shows the normal/missing-path comparison.

Step 4: record one attempt and its actual outcome

Use a decision card before a state-changing test. A useful card identifies exactly what the method is meant to establish and what result would send you back to enumeration.

This is a filled reasoning example, not a success claim. A banner match alone is insufficient, and repeated attempts without a new hypothesis do not improve the evidence. Do not replace missing attempt evidence with a screenshot from another author. If a service stops responding, preserve the error and check VM state before deciding to restore the baseline.

If you need a complete independently authored solution, consult the release’s community walkthrough index. Disclose that assistance in your own report and compare its release and environment with yours.

Step 5: verify the resulting identity

Run these checks in the target session, not accidentally in a Kali terminal:

id
whoami
hostname
uname -a

Retain the session context with the output. If effective UID 0 is demonstrated on the target, explain that result and the guest boundary. If access is unprivileged, record the starting identity and investigate a supported local path. An extra escalation stage is unnecessary when the initial session already has root privileges.

Step 6: write the evidence chain and recovery note

Completed teaching example — hypothetical investigation:

Scope: original Level 1 (#1), current target identity recorded.
E001: baseline TCP scan; remaining TCP/UDP coverage noted.
E002: selected service probes; uncertain version evidence retained.
E003: HTTP response saved; no login form assumed.
Decision: research a Samba advisory; applicability still incomplete.
Outcome: no exploit run and no root access claimed in this example.
Next task: resolve the missing prerequisite and preserve the result.
Recovery: baseline reference recorded; target powered down after notes were saved.

When your own investigation reaches access, add the actual attempt and identity artifacts between the decision and outcome. Keep failed attempts and assistance visible. Your report should explain the relevant fix—such as replacing unsupported exposed services or applying an applicable vendor patch—and how you would verify it. Samba 2.2.8a is a historical fix reference, not a recommendation to deploy that obsolete version today.

Save originals privately and redact a separate sharing copy. Preserve notes outside any snapshot you may restore. Use the record below to consolidate the session.

Questions that change the next step

My output differs from the example. Is it wrong?

Not necessarily. Check release, current target MAC/IP, network and scan coverage. Retain your output and investigate the difference. The sample rows above are teaching data.

Must I finish the box in one session?

No. Finish with a saved artifact, a clear unresolved question and a resume point. Setup and compatibility work may take a separate session.

Does this prove current OSCP exam readiness?

No. This legacy VM practices enumeration, research and reporting. Check the provider’s current exam scope and tool rules separately.

Do I need a separate privilege-escalation exploit?

Only if your supported path requires it. If the resulting target session already demonstrates effective UID 0, record that evidence rather than adding an unnecessary stage.

Why does my request return a page for every path?

Compare a known page and a deliberately missing path. Record status, body, and redirects; a custom error page can make an automated discovery result misleading.

What should the completion record say when I stop early?

State exactly what was attempted, what remains unresolved, and the next check. Generating a record does not verify root access or mark a lab as completed.

Sources and reproduction scope

Reviewed October 24, 2026. Release identity, command semantics and the historical Samba lead were checked against the primary documentation linked above. The command and result examples are instructional, not logs from a new VM run. Keep your own image hash, host/hypervisor versions, network identity, tool versions, commands and outcome files with the report.

For further practice, choose a specific gap from your record or follow the seven-session roadmap. See the author and evidence policy.

Walkthrough completion evidence record