Use this guide to finish your first documented Kioptrix practice session. The result is a four-field record that separates what you observed from what you assumed. For downloading and network preparation, use the Level 1 setup guide; for a longer sequence, use the seven-session roadmap.
Evidence status: the worked record below is an illustrative example, not a captured Kioptrix run. This update did not boot a VM or execute the example commands.
Complete one small practice loop
Prerequisites: basic terminal navigation, an intentionally vulnerable VM you control, a confirmed target identity, and a recovery point. Do not scan until the target MAC and current IP match your lab record. Keep the host and unrelated devices outside scope.
- Observe: choose one result from your own service inventory. Save its time, command, and original output.
- Interpret: write a possible meaning and an alternative explanation. A port label or banner is not proof of a vulnerability.
- Check: select one permitted action that could distinguish the explanations. State what you expect before running it.
- Review: record the actual result and the next question. Retain conflicting evidence instead of rewriting the original assumption as fact.
A four-field worked example
Illustrative Example: assume your own authorized VM has already been identified and a service check indicates HTTP. These are hypothetical observations, not expected output from every Kioptrix image.
- Observation
- The initial service scan labels one port HTTP. The raw output is saved in my session folder.
- Interpretation
- A web server may be present. The label could be based on the port number; the application and version remain uncertain.
- Next permitted check
- Visit the confirmed lab address and record the response, final URL, page title and visible links. Stop if a redirect leaves the authorized target.
- Review
- If a default page appears, record that fact. Do not invent a login form or assume the page proves a vulnerable version. Choose one question about the observed component.
The same structure works when a check fails. Preserve the exact error, whether a response arrived, and whether the setup changed. Use the troubleshooting guide when the blocker is an error rather than missing research.
Keep the record light enough to use
Use one row per decision. Keep raw outputs separately and link them from your notes. Record the tool version and target identity once per session, then repeat them when they change. A short summary cannot replace the underlying evidence.
There is no validated command-count or note-time score here. Choose a session length that lets you record a clear stopping point. If you use a hint, note which part was assisted and repeat the explanation in your own words.
Common questions
Do I need root access to complete this exercise?
No. A complete observation-to-review record satisfies this exercise. Root access is the challenge objective, not proof that your reasoning is reproducible.
What if I cannot decide what to test?
Use the next-step decision guide. If you have a hypothesis but cannot define a meaningful result, use the methodology guide.
What should I save before stopping?
Save the raw evidence, completed record, assistance used, snapshot state and one next question. Shut down the vulnerable target when finished.
First-session decision record
Complete one record, then generate a summary to copy or download. Use sanitized notes only. This tool has no server submission or automatic local saving; page reloads clear the form.
Sources and next practice
NIST SP 800-115 provides general security-testing planning guidance; the four-field exercise is an editorial learning aid. For raw-output organization, see the recon log guide. About the author and evidence labels.
Substantive revision: October 20, 2026 (UTC). Replaced repeated introductory advice and unverified anecdotes with one worked record and a usable export form. No new lab execution is claimed.
