A useful Kioptrix checklist prevents a specific repeated omission. Build it from an actual session: what went wrong, when a reminder would have helped, and what evidence would show the check was satisfied.
Keep commands beside their purpose when they help reproduction. The problem is not having commands in a checklist; it is copying them without scope, prerequisites or a result to inspect. This guide turns a session mistake into one small reusable rule.
Give each rule a trigger, action and completion evidence
| Field | Purpose | Weak alternative |
|---|---|---|
| Observed omission | Explain the problem this reminder addresses. | “Do better enumeration.” |
| Trigger | State when the rule applies. | “Always run every tool.” |
| Action | One bounded inspection or test. | “Check everything.” |
| Completion evidence | Name the observation or file needed to mark it checked. | “Spent twenty minutes.” |
| Revision condition | State what would make the reminder outdated or irrelevant. | Keeping a rule forever because it once worked. |
Use explicit statuses: not checked, checked with evidence, blocked, or not applicable with a reason. Missing evidence stays missing. A high completion count must not override an unknown target identity or unresolved network boundary.
Worked example: checking identity after a restore
Illustrative example: a learner resumed using an address from an earlier session without confirming that it still belonged to the intended VM. The following rule addresses that omission; it does not assert that this happened on a specific Kioptrix release.
Omission: A stale address was reused after a VM or network change. Trigger: Starting a session, restoring a snapshot, or changing an adapter. Action: Match the current target address to the intended VM identity. Completion evidence: Current MAC/address comparison, source and time recorded. Status: Not checked until the current evidence is saved. Revision condition: Update the identification method if the platform changes.
The action is not “ping the old address.” Ping may show a response without proving that the same VM owns it. The rule tells you why the check exists and what observation is required.
When a trigger fires, inspect the current state. If DHCP assigned the same address, record that confirmation. If the address changed, update your session record before deeper testing. For the actual discovery options, use the Nmap discovery comparison and network setup guide.
A short starter checklist with evidence requirements
Adapt these to your lab. They are prompts, not a complete vulnerability assessment or a certificate of isolation.
| When | Check | Evidence to save |
|---|---|---|
| Before active testing | Confirm the intended scope and VM boundary. | Named target, every enabled adapter, addressing and relevant routing. |
| At session start or after a restore | Reconfirm target identity. | Current identity/address comparison and time. |
| After a scan | Check what actually ran. | Exact command, coverage, completion status and output filenames. |
| Before a vulnerability claim | Compare prerequisites with observations. | Source, confirmed conditions and unresolved requirements. |
| Before a state-changing experiment | Record the starting state and recovery method. | Snapshot or copy reference, planned changes and stopping condition. |
| Before ending a session | Write a usable resume point. | Last observation, open question and the next bounded action. |
A rule should be narrow enough to use at the relevant moment. Keep a short active list and link to supporting instructions. Put detailed service checks in the service inventory rather than expanding the start-of-session list into a full testing manual.
Review rules against actual use
- Read one session’s evidence and find a repeated omission or a costly assumption.
- Write the trigger that would have made a reminder timely.
- Define a small action and the observation needed to mark it checked.
- Try the rule in a later session and record whether it caught the omission.
- Revise vague wording, split oversized checks and remove duplicates.
Retire a rule when it is tied to a tool or environment you no longer use, but keep a brief reason in your change history. An unused reminder is not necessarily useless: it may belong to a rare trigger. Review the trigger before deleting it.
Do not turn the final command from a walkthrough into a mandatory checklist item. Record the condition that justified that command. If a hint supplied the condition, disclose it in the session notes and practise reconstructing the decision later.
Build one reusable checklist rule
Describe a real omission and define the evidence needed next time. The first four fields are required. Generated rules start as Not checked. This tool does not test your lab, submit entries or save them automatically. Download before leaving; reloading clears entries.
Keep the checklist, notes and report separate in purpose
The checklist prompts a future action. Notes preserve what actually happened. A report selects the evidence needed to support a claim. Link them with evidence IDs so the checklist remains brief while a reader can still trace its use.
Start with one rule from your latest attempt. After using it, ask whether another learner could tell when it applies and what counts as completion. If the answer depends on your memory, make the rule more specific.