Kioptrix Level 2 Guide: Web Tests, Evidence and Next Steps

This Kioptrix Level 2 guide helps you test web behavior, interpret the result and choose your next step. It covers Level 1.1 (#2), using the updated archive as the reference image.

Scope: a lab companion with illustrative comparisons and a record tool. The example outcomes are hypothetical, not a transcript of a new end-to-end exploit run. For a separately authored full solution, open the VulnHub community walkthrough list — spoilers.

1. Confirm the image and lab

VulnHub identifies this release as Kioptrix: Level 1.1 (#2) and records a re-release after a web-application bug. Match the exact filename in its File Information listing. Identify your existing file before deciding whether another download is needed.

Do: calculate the digest of the archive you actually have. For the updated file, run:

sha1sum Kioptrix_Level_2-update.rar

Compare: the updated archive’s published SHA1 is 7A0EA0F414DFA0E05B7DF504F21B325C6D3CC53B. Save your result and source. SHA1 here is a legacy file comparison, not a signature or a safety certification.

Before continuing: use a dedicated lab segment, inspect all adapters and any forwarding or sharing, and keep the vulnerable VM off your physical LAN and unintended outbound paths. Host-only also includes the host. Record the target VM identifier and its matched current IP. Keep original files and notes outside the rollback boundary; establish a recovery method before state-changing tests.

2. Save the service inventory before testing the web application

Start when: the VM is running, its identity and current IP are matched, and you have reviewed the lab boundary and route.

Do: use the Kali tool guide to save an initial service inventory. Record the tool version, exact command, target, tested ports and completion or error status. Preserve original output rather than copying only interesting lines.

Read: select an observed HTTP service and record its actual scheme, address and port. A service label is a lead; inspect the response before assuming an application or version.

Next: if the web service responds, record the form’s action, method and field names, then continue below. If it does not, use the troubleshooting table. Do not copy a target address or assumed port list from another run.

3. Compare login requests and session state

Start when: you can reach the actual login form on your own training VM.

1. Save a deliberately invalid login request and response as E01. Record URL, method, form action, field names, response status, redirect destination and whether a session already existed.
2. Make one controlled input variation as E02. Keep the other request conditions equivalent. Use a separate fresh session with the same starting state for each comparison; do not reuse an already authenticated session as a control.
3. Check the destination and a protected function independently as E03. Repeat the comparison from equivalent initial conditions.

Next: investigate SQL-specific behavior using the OWASP SQL injection testing guide. A changed page alone does not identify the cause. Keep complete evidence privately and redact live cookies from shared copies. Continue to a post-login function only when its access is actually established.

4. Compare reflected input with command execution

Start when: your authorized VM exposes a ping-style function you can access. Record its URL, parameter and session state; the endpoint and syntax may differ in your copy.

1. Submit 127.0.0.1 as a normal loopback input and save the request and response as E04.
2. In this isolated lab only, compare the bounded teaching input 127.0.0.1; id as E05. Keep other request conditions equivalent.
3. Repeat the comparison as E06 and retain the full responses. Separate the submitted text from output produced by the server.

Example conclusion: “The changed request produced repeatable process-identity output in this illustrative case. An interactive shell and elevated privileges were not tested.” Replace this with your own results. See OWASP’s command injection explanation and the Level 2 command-injection comparison guide.

5. Review channel and privilege evidence separately

Start when: command execution has been established. Decide whether a further command channel is needed for your next question. A network connection, a working command interpreter and a privileged session are separate outcomes.

Do: if investigating an authorized channel, record the initiating endpoint, destination address and port, listener binding, route and errors. Check transport and command input/output separately. Keep the target isolated while troubleshooting.

Once a guest command channel actually works, record each command and result:

id
hostname
uname -r
uname -m

Interpret: these identify the current context and provide investigation leads. A kernel string alone does not prove that an escalation applies; distribution packages may contain backported fixes.

Next: write why a candidate fits or does not fit before testing it. If no escalation was attempted, record “not attempted.” If a test failed, retain the error and unchanged identity. If effective UID 0 is observed, preserve the before/after evidence and state the guest or namespace boundary; it does not establish host access. This guide supplies no newly reproduced root result.

6. Find the next check from the symptom

When seeking help, share the exact release, sanitized environment, one question, the action and literal result, and what you already checked. Say whether you want a hint or a worked step.

7. Save your lab record and next question

Continue: compare Level 2 command-injection results, or consult the external community solutions — spoilers. Compare image version and environment before adopting a route.

Editorial update: October 26, 2026. Added state-based navigation, comparison steps, transition criteria, troubleshooting and structured notes. Outcomes remain illustrative; no new VM boot, end-to-end exploitation or restore test was performed.