Use these Kioptrix Level 1 notes to separate observed facts from assumptions before writing a finding. Keep the source, literal result, interpretation and claim still to test in separate fields. “The scanner printed a version” and “the target is vulnerable” need different evidence.
This is an evidence-writing guide for an authorized lab, with illustrative examples rather than captured test results. For the full investigation sequence use the four-step Level 1 methodology; for solution hints use the Level 1 walkthrough.
Looking for the Level 1.2 (#3) release instead? Use the release-name comparison or Level 3 download guide.
A Level 1 first-scan note: before and after
Hypothetical example: suppose a saved scan of your confirmed lab target reports TCP 80 open. This is a writing exercise, not a result observed for this page.
Overstated note: “Port 80 is open, so the web server is vulnerable.”
- Source: the saved first-scan file, exact command, source VM, target identity and time.
- Observation: “The recorded scan reported TCP 80 open under these conditions.”
- Interpretation: “A service accepted TCP connections at that point. The application and patch state are not established by this port state alone.”
- Next question: “What response identifies the protocol or component, and what remains uncertain after that check?”
Keep “not yet established” distinct from “not vulnerable.” Write the same four parts for one result from your own lab.
Use four fields instead of one confident sentence
| Field | What belongs there | Example wording |
|---|---|---|
| Source and conditions | Target identity, exact action, time and evidence file. | “E004 contains the response to this URL from this source VM.” |
| Observation | A returned value, error, visible state or a faithful description of it. | “The saved response contains a Server header with this string.” |
| Interpretation | What that observation suggests, with alternatives. | “The header is a product clue; a proxy or custom banner remains possible.” |
| Claim to test | A specific uncertainty and the observation that would resolve it. | “Is the affected component required by this advisory actually enabled?” |
Tool output can itself be an inference. It is a direct observation that Nmap printed a product match; whether that match accurately describes the target is a separate question. Nmap documents how service probes and response matching work.
Rewrite these common notes
“Port 80 is open, so Apache is vulnerable.”
Rewrite: “The saved scan reported TCP 80 open under the recorded conditions. Application identity, exact build and vulnerability prerequisites remain unverified.” An open state concerns the observed transport behavior, not a vulnerability. See Nmap’s state definitions.
Next question: what protocol response supports an application identity, and what does it leave uncertain?
“The server banner proves the patch is missing.”
Rewrite: “The response disclosed the recorded version string. I have not established the installed package build or patch state.” Vendors may backport fixes while retaining an older upstream version; Red Hat explains this source of version-based false positives.
Next question: which advisory, package evidence or relevant behavior would establish the affected condition? Do not claim that the target is patched either; that also requires evidence.
“The exploit failed, therefore this service is secure.”
Rewrite: “This attempt did not produce the expected observation. The exact error is saved. Tool execution, reachability and prerequisites have not all been established.”
Next question: did the failure happen locally, during transport, during protocol interaction or after the tested action? Keep the cause unresolved until a check distinguishes those possibilities.
“Both tools agree, so the finding is confirmed.”
Rewrite: “Both tools reported the same lead. I have not checked whether they relied on the same banner, signature or underlying assumption.”
Next question: what evidence of the actual affected behavior or configuration would add something beyond the shared input? Agreement can be useful without being independent confirmation.
“The shell prompt says root, so the entire host is compromised.”
Rewrite: “The prompt text alone does not establish identity. Record the account information in the identified guest context and any demonstrated operations separately.” The id manual describes current process user/group information.
Next question: what identity and permissions were actually demonstrated in which VM? A privileged guest result does not establish host access or a VM escape.
Capture the context before shortening the result
For an identified HTTP service in your isolated lab, this example saves response headers and body separately. Replace all uppercase placeholders and choose unused evidence filenames:
mkdir -p evidence curl --connect-timeout 5 --max-time 15 --dump-header evidence/O001-headers.txt --output evidence/O001-body.html http://TARGET_IP:HTTP_PORT/
The request uses GET and does not automatically follow redirects. Inspect a redirect destination before making another request. Save the exact command, time, source context, errors and requested URL. The curl manual explains the output and timeout options.
Quote only the relevant line in the ledger, with a reference to the full private evidence. Keep status, headers and body distinct. A heading on a web page and a protocol header are different evidence, even if both contain a product name. Sanitize the sharing copy if responses include cookies, tokens or personal information.
Keep contradictions visible
Suppose a scanner identifies one product, while a later application response suggests something different. Preserve both records. Check target identity, time, port, hostname, request method, proxy path and VM state before choosing which explanation to prefer.
Do not replace the old note silently. Add: “Earlier interpretation superseded by [evidence ID] under [conditions].” A changed result can reflect a changed environment, not necessarily a mistaken earlier capture.
Write your Level 1 observation ledger
Use your own sanitized evidence. This field is not submitted or automatically saved. Select and copy the completed text to your notes before leaving or reloading.
Use the session notes template for the broader activity log. When the next check is clear, use the claim verification guide to define prerequisites and controls. For a final write-up, use the report template. Keep the strength of the wording no greater than the evidence supporting it.
Editorial update: October 21, 2026. Clarified the Level 1 note-writing task, added an illustrative first-scan rewrite and an editable ledger. No VM execution or scan was performed for this update.