Kioptrix Running Log: Questions, Actions and Results

Use a running log as a chronological index of an authorized lab session. Each entry connects a question, an action and an observed result to its supporting artifact. Keep later corrections visible so an early guess does not silently become a final finding.

Jump to the event template or the unresolved-question entry. For a session-level handoff, use the current-versus-stale evidence record.

State why a check is being repeated

A repeat can be justified by an incomplete earlier check, changed conditions, a comparison or a different question. Reference the earlier entry and state the reason. A failed command does not automatically rule out a vulnerability or make every repeat unnecessary.

Define the log’s role

The log is an index and decision record, not proof that you worked more efficiently or learned more. Link to relevant raw output instead of treating a polished narrative as a substitute for the underlying evidence.

Record what happened, including incomplete work

An entry may end with a completed observation, a local error, an inconclusive result or a test not performed. Activity is not necessarily progress toward the question. Mark the status and what remains unresolved.

Start with scope and handling rules

Record the intended VM, permitted activity, relevant network attachments and routes, and the basis for target identity. Pause testing if these are uncertain. A private IP or host-only adapter label alone does not establish the whole boundary.

Keep secrets outside shareable logs. Reference an access-controlled secret record by a neutral identifier if necessary; do not paste passwords, hashes, tokens or unrelated personal data into a public worksheet. Review output and images before sharing. Preserve originals according to your own handling rules and create a separately labeled sanitized copy.

Mark when a note was written

If you reconstruct an entry after the session, label it retrospective and identify the source used. Distinguish the time of the observation from the time you wrote the note. Do not invent a timestamp or missing sequence from memory.

Capture the context needed to interpret an event

Include the target and relevant state, tool or request and meaningful options, expected behavior, literal result, completion or error status, artifact location, interpretation and limitation. State the source of guidance where it affected the action or interpretation.

Record an artifact’s actual contents precisely. “The scanner printed a version label” is an observation; “the target runs a vulnerable build” needs additional evidence. A denied anonymous request does not establish the result of authenticated access, and an unreachable service does not prove it is absent.

Copy an event template

Use a stable entry identifier that later entries can reference. Fill fields from your own work; the template contains no captured lab results.

Entry ID:
Observation time / timezone, if known:
Note written time / retrospective source, if applicable:
Target / relevant environment state:
Question / expected behavior:
Action actually performed / options:
Guidance or source used:
Literal relevant result / completion or error:
Artifact location / exact excerpt or image reference:
Interpretation and conditions:
Outcome: observed / inconclusive / incomplete / not tested
Limits / unresolved question:
Next decision / reason:
Related prior entry / reason for repeat:
State changes to recheck:

Add corrections instead of erasing the trail

If later evidence changes an interpretation, add a dated correction referencing the earlier entry. State which observation remains valid and which claim changed. Keep a distinction between an unsuccessful action and a supported negative conclusion. Do not use “ruled out” unless the check actually addresses the condition under stated limits.

Give artifacts a bounded caption

For an image, identify the target, action or request, relevant visible result and conditions. A screenshot shows what was captured; it does not establish everything outside the frame or prove that a suggested cause is correct.

Use a consistent filename and record its location. If you crop or redact an image, label the shared derivative and preserve the required original separately. Choose text output when exact text is needed, and images when visual context helps interpret the result. See the artifact-caption outline.

Write an unresolved-question entry

Name the last verified stage, the missing information and the kind of help or check needed. Do not force every block into a deeper-enumeration or privilege-escalation path; setup, scope and prerequisites can remain unresolved.

Question still unresolved:
Last verified stage / supporting entry:
What was checked and under which conditions:
What is incomplete or not tested:
Candidate explanation / alternative:
Help or distinguishing check needed:
Continue / defer / pause decision and reason:

You can request an explanation, diagnosis or a worked example without waiting for a fixed period. Disclose the assistance in the subsequent entry.

Build a reader-facing account from supported entries

Select the evidence relevant to the report’s question. Keep the actual contribution, failed checks that affect the conclusion, uncertainty and untested scope. Do not replace “version inferred” with “version confirmed” merely to make the prose cleaner.

Link conclusions to entry and artifact identifiers. A report can omit unrelated detail while preserving the limits of the claim. Use the report template for a different document structure.

Close with the current state

When pausing, record active work, changed configuration, relevant processes or services and what must be verified next time. If state is uncertain, preserve evidence before deciding on a recovery action. Pausing, restarting, reverting and rebuilding are different actions; use the recovery decision record.

Logging questions

Which editor should I use?

Choose one that fits your access, export, search and handling requirements. This page does not benchmark note-taking products or establish a universally fastest format.

Must every observation have an immediate command next?

No. The next decision may be to ask for help, gather prerequisite information, defer the question or stop. Record why.

Do I need every failure in the final report?

Retain the working evidence appropriate to your task. Include failures in the report when they affect its interpretation, scope or conclusion; do not silently turn them into confirmed exclusions.

Start with a real event

Copy the event template for an authorized task. Mark missing fields unknown and link the first actual artifact. There is no required line count, writing time or completed machine before the log can be useful to a reader.

For a different task, browse Find a Guide.