Before investigating Kioptrix, practise these Linux tasks on your own Kali workstation: locate a file, read and search it, explain its permissions, preserve an error, and identify the machine and account producing the output. These small exercises address common blockers without requiring access to the vulnerable target.
Run the examples in one ordinary user shell on Kali, without sudo. They create practice files in a new temporary directory. They do not scan or change Kioptrix. Expected behavior below is an explanation of the examples, not output captured from a completed lab.
1. Create a fresh workspace and explain its path
practice_dir=$(mktemp -d) printf '%s ' "$practice_dir" cd "$practice_dir" pwd mkdir evidence ls -la
Check that mktemp succeeded and printed a directory before continuing. If it fails, stop and read the error. The mktemp manual describes directory creation with -d. A temporary directory is suitable for this exercise, not durable storage for important evidence.
pwd reports the current directory. The name evidence is a relative path under it; "$practice_dir/evidence" is an absolute path when the generated directory is absolute. Quotes keep a pathname containing spaces as one shell argument.
Check: explain where a file named notes.txt would be created now, and how that changes after cd. Copy the practice directory path into your notes so you can find it after closing the shell.
2. Write, read and search a small note
printf '%s ' 'Observed: this is a local practice note.' > notes.txt printf '%s ' 'Unknown: no target service has been tested.' >> notes.txt cat notes.txt grep -n 'Observed:' notes.txt cp -i notes.txt evidence/notes-copy.txt
The first redirection writes standard output to a file and can replace its existing contents. The second appends. Here the directory is new; in real evidence folders, inspect the destination and use a fresh filename before writing. cp -i asks before overwriting an existing destination.
cat shows the note. grep -n searches for the selected text and includes a line number. If the commands were run as written, the observation is on the first line. That is an expected exercise result, not a finding about the target.
Check: explain why the file says that no target service was tested. A command run on Kali does not become evidence from Kioptrix merely because a lab session is open.
3. Inspect ownership and change only the practice file
id ls -l notes.txt chmod 600 notes.txt ls -l notes.txt
For an ordinary regular file, mode 600 gives the owner read/write mode bits and no group or other mode bits. It does not encrypt the contents. The listing also identifies owner and group; compare them with id.
In symbolic notation, the permission groups are owner, group and other. Read, write and execute have different meanings for regular files and directories: directory execute permission is search/traversal permission. The chmod manual explains numeric and symbolic modes.
Check: identify the file type character and three permission groups in the listing. Do not claim you tested another account’s access just because you read the bits. ACLs, parent directory permissions and other controls can also affect access.
Do not use recursive chmod, chmod 777 or a root shell as a general repair for an unexplained permission error. Inspect the exact path, identity and operation first.
4. Preserve standard output, standard error and exit status
cat missing-file.txt > stdout.txt 2> stderr.txt printf 'Exit status: %s ' "$?" cat stderr.txt ls -l stdout.txt stderr.txt
In the new workspace, missing-file.txt has not been created. The failed read should produce a diagnostic on standard error, while the standard-output file can remain empty. Read the exit status immediately: another command changes $?.
This exercise distinguishes “no normal output” from “nothing happened.” Preserve both the exact command and its diagnostic when investigating a failure. A tool can fail before it contacts the target, for example because an option or local file is wrong.
Check: explain which file contains the diagnostic and why redirecting only standard output would not capture it. Use your shell’s installed help for redirection syntax; do not suppress errors merely to tidy a transcript.
5. Identify the local shell and inspect local TCP listeners
hostname id ps -p $$ -o pid,comm,args ss -ltn
These observations describe the environment where you ran them. id reports account identity, and the process command inspects the current shell’s PID. Record that context before comparing output from another VM or a remote shell.
ss -ltn displays listening TCP sockets numerically in the current network namespace. It does not scan the target and does not show UDP listeners. Read the ss manual for the options.
A loopback listener differs from a listener bound to a non-loopback or wildcard address. Neither binding alone proves remote reachability: routing and filtering still matter. An empty TCP-listener result is a valid local observation, not a reason to install or start a service just for the screenshot.
Keep a short practice record
Machine and current account: Shell and tool versions where relevant: Practice directory: Task and exact command: Literal output or error: Exit status and when it was read: What the result supports: What it does not establish: Next prerequisite to practise:
Copy useful notes to a persistent folder you choose before leaving; temporary files may be removed by the system. No deletion command is needed for this lesson. Review any later cleanup path carefully rather than using a broad recursive command.
For deeper guided practice, compare the official HTB Academy Linux Fundamentals module or TryHackMe Linux Fundamentals with the specific gap you encountered. These exercises are not a complete Linux curriculum or a proficiency score.
When the basic tasks are understandable, return to Level 1 preflight. Use the separate network observation exercises for addresses and routes, and keep later target evidence in your session journal.