Begin a Kioptrix privilege review by recording the identity and permissions you actually have. A sudo entry, a SUID file or an old kernel string is a lead to investigate; none alone proves a working escalation route.
Confirm the starting state
Use this checklist only after obtaining authorized access to your training VM. Record the release, target identity, current account, groups, access method and evidence location. If the current identity is already root, document it rather than inventing an additional escalation stage.
Basic local observations such as id, whoami and uname -a help describe the environment. Retain their output and time. Avoid publishing environment dumps that contain secrets. If you are still seeking initial access, return to the Level 1 walkthrough and hints.
Classify candidates before attempting a change
| Lead | Record | Do not conclude yet |
|---|---|---|
| Sudo policy | Runas identity, exact command path, argument limits, authentication and environment rules | NOPASSWD does not authorize arbitrary root commands. |
| SUID or SGID binary | Owner, group, file type, permissions, mount conditions and program behavior | A marked file is not automatically root-owned or exploitable. |
| Kernel or package version | Architecture, build, patch provenance and advisory prerequisites | A matching-looking version does not establish vulnerability. |
| Writable service-related file | Who uses it, under which identity, when and with what input restrictions | Write permission alone does not prove privileged execution. |
Read the complete sudo rule
A permitted sudo -l review can describe allowed commands. Authentication failure or an unavailable listing is an unresolved condition, not evidence that the account has no sudo rights. Record the exact response without guessing credentials.
Read the entire matching rule and the behavior of the named command. Distinguish permission to execute a particular program from evidence of what that execution would do. Consult the policy manual for the installed version. Keep the original rule in private lab notes and sanitize any publication copy.
Worked example: a restricted command
Illustrative example. A listing permits one named maintenance command as a service account without a password. The defensible observation is the exact authorization shown. Calling it “root access” would add two unverified claims: that the Runas account is root and that the command permits arbitrary execution.
The next record should identify the Runas account, path and restrictions, then consult the program documentation. If the behavior or prerequisites remain unknown, park the candidate with the missing fact. Do not run a destructive action merely to complete the checklist.
Distinguish an attempted action from a result
- State the candidate, evidence and missing prerequisites.
- Define a permitted check, its expected observation and stop condition.
- Preserve the current evidence and recovery point before a state change.
- Record what actually happened, including errors and incomplete execution.
- Verify any claimed resulting identity and connect it to the exact attempt.
No fixed twelve-minute sequence guarantees success. If identity or scope becomes uncertain, pause. For a state change use the restart and restore checklist; for a finding use a traceable evidence record.
Documentation and limits
Use the sudoers policy manual as a reading reference and compare it with the version in your VM. General assessment context comes from NIST SP 800-115. This is an editorial review workflow, not a newly executed exploit chain.
Editorial revision: October 25, 2026. Replaced repetitive introductions with a task-specific workflow, comparison and illustrative example. No new VM execution, measured learning effect or hiring outcome is claimed. Author and evidence policy.
Working note: Replace time-to-root estimates with prerequisite checks
Replace the prompts with your own authorized lab evidence. Select the completed text and copy it to a local note before leaving. This field is not submitted or saved; reload clears edits. Do not enter passwords, tokens or personal data.
Related task: Continue with the related practical guide.