Cybersecurity Terminal - Wazuh / Kali is part of Practice Tools. Sign in or create an account, then subscribe for ₦4,000/month to unlock it.
Step-by-step exercises for Cybersecurity Terminal - Wazuh / Kali - read them here, then practice live in the tool above.
A fully offline, simulated Linux terminal for practicing everyday recon and sysadmin commands. Nothing you type here touches a real system.
Kali is a real Linux distribution built specifically for security work, and Wazuh is a real open-source security monitoring platform. Together, this simulator's name signals what it's teaching: the everyday command-line habits a security analyst or sysadmin uses constantly — checking who you are, what's running, what's listening on the network, and what files are around — before doing anything more advanced.
This simulator is a safe, offline stand-in. Every command you type is matched against a small, fixed set of realistic canned responses — nothing here executes on a real machine, and nothing you do can break anything or affect a real network.
Launch the simulator from your dashboard. You'll see a terminal prompt: practice@kali:~$. Type help at any time to see every command this sandbox supports.
whoami, id, pwd)| Command | What it does |
|---|---|
help | Lists every supported command |
whoami | Shows the current user |
pwd | Shows the current working directory |
id | Shows user ID, group ID, and group memberships |
uname -a | Shows system/kernel information |
ls / ls -la | Lists files in the current directory (long form shows permissions/size) |
cat <file> | Prints the contents of a file |
ps aux | Lists running processes |
netstat -tulpn | Lists listening network ports and the programs behind them |
ifconfig | Shows network interface configuration |
history | Shows every command you've run this session |
clear | Clears the terminal screen |
uid= tell you? What does it mean that this user is in the sudo group specifically — what kind of power does that group generally grant on a real Linux system?ls first. Then run ls -la and compare the output. What extra information does the long-form listing (-la) give you that plain ls doesn't?catnotes.txt. What does this note tell you about what this machine was being used for before you got here? Now try cat flag.txt — what do you see? (This is a harmless, self-contained training marker, not a real secret — but noticing it and reading it carefully is still the skill being tested.)cat /etc/passwd. On a real Linux system, this file lists every user account. How many user accounts do you see listed here, and what are their usernames?cat doesnotexist.txt — a file you know doesn't exist. What error do you get, and why is it useful that the system tells you clearly rather than just doing nothing?ps aux yourself. Identify which process is owned by root and which are owned by practice. What does PID 1 (/sbin/init) represent on a Linux system, and why does it always run as root?notes.txt from Part 4 — is this machine part of that same range?history and confirm it shows everything you've typed so far, in order. Why is a full command history valuable during a real investigation, beyond just personal convenience?ls -la because plain ls "already showed the files." The extra detail (permissions, size) is often exactly what a real investigation needs.cat doesnotexist.txt). Learning what an error looks like is just as useful as learning what success looks like.Click 💾 Save This Session as a Project inside the simulator before you close it — this saves every command you ran and its output. Title it clearly, e.g. "Kali Terminal — Beginner Lab", and include your Part 9 host summary in your saved notes or a short attached write-up.
notes.txt one more time. It mentions checking for default credentials — based only on what you found in this lab (the process list, the open ports, the files), what would your very next step be if this were a real investigation and you actually could run more commands?whoami and id — they both tell you about the current user, but they don't give you the same information.You already know each command individually. This lab is about cross-referencing them into a coherent picture of one machine.
The Beginner lab taught you what each command does in isolation. Real analysts almost never care about a single command's output on its own — the value comes from correlating multiple commands together: does the user's group membership match what they're actually able to see? Does the process list match the open ports? Does a file's content change how you read everything else?
This lab has no new commands to learn. Every task below uses the exact same command set from the Beginner lab — the difference is entirely in how deliberately you connect their outputs.
help and check yourself. Any gap here is worth closing before continuing — this lab assumes fluent recall.-rw-r--r-- vs. -rw-------). In plain terms, who else besides the file owner can read notes.txt? Who else can read flag.txt? Now connect this to the id output — being in the sudo group affects what commands this user can run with elevated privileges, but does it change these specific file permissions on its own? Explain the distinction between "elevated privileges available" and "elevated privileges currently being used."nginx) appears in the port list on port 80, but does not appear anywhere in your ps aux output. Write 2–3 sentences on what this mismatch could mean in a real investigation, and why a mismatch like this is exactly the kind of thing that should make an analyst pause rather than move on.| Field | Your finding |
|---|---|
| Current user & privilege level | |
| OS / kernel | |
| Own IP address | |
| Running processes of note | |
| Open ports & matching (or mismatched) processes | |
| Notable file contents | |
| Your #1 priority follow-up, and why |
grep, no piping commands together, no sudo -l to check what the current user can actually run with elevation, no way to check scheduled tasks (cron), and no way to check for unusual startup programs. In 4–5 sentences, explain: if this were a real machine and you had a real terminal, what would be the very next 2–3 commands you'd want to run, based specifically on the PID 1200 mismatch from Part 3 and the default-credentials warning from Part 4? You don't need real syntax memorized perfectly — describe what you'd want to check and why.notes.txt once and not returning to it. Part 4 is designed to show that context you gathered earlier should actively change how you read facts you gather later.rwx-style string (e.g. -rw-r--r--) showing who can read, write, or execute a file — owner, group, and everyone elseSave your session before closing the simulator, with a short note on what stood out to you. Title it "Kali Terminal — Intermediate Investigation", and attach your full Deliverable write-up alongside the saved session.
ps aux even though it's clearly listening on port 80. Why is it useful to also consider the mundane explanation, not just the alarming one?No walkthrough. No hints. A machine has been handed to you with one sentence of context — investigate it the way a real analyst would.
A colleague hands you SSH-style access to a box and says only: "This host got flagged by our monitoring as behaving a little strangely. Can you take a quick look and tell me if it's actually a problem?"
No other hints. No pointer to a specific file, process, or port. You have exactly the command set this sandbox supports — nothing more — and your job is to reach a defensible verdict and write a handover note a colleague could act on without redoing your work.
Write down, before running a single command:
grep, no sudo -l, no cron inspection, no log files beyond what cat can reachwhoami, id, and pwd. Record the user, their UID/GID, and their group memberships. State explicitly: does this user's group membership grant elevated privileges in principle, and separately, is there any evidence in this session that elevated privileges are currently in use? These are two different questions — answer both.uname -a and ifconfig. Record the OS/kernel version and the machine's own IP address. Note whether the kernel version looks current or outdated to you, based on general knowledge — this becomes relevant context later, not a standalone finding on its own.ls -la and record every file, its permissions, and its size. Then cat every single file you can access — including /etc/passwd — even ones that don't look immediately interesting. Record each file's content and its permission string side by side.ps aux and netstat -tulpn. Build a single combined table with every process and every listening port, and explicitly mark, for each open port, whether its stated PID/program has a matching entry in your process list.| Port | Program | PID | Matches a process in ps aux? |
|---|---|---|---|
| 22/tcp | sshd | 812 | |
| 80/tcp | nginx | 1200 |
| Finding | Confirmed (direct evidence from this session) or Suspected (would need more access to confirm) |
|---|---|
What you found and your overall verdict, written for someone who will read only this section.
User/privilege, OS/kernel, IP, and a clean version of your Phase 4 process/port table.
The Phase 5 mismatch, your list of plausible explanations, and what's needed to close each one out.
The exact commands and outputs backing every confirmed item from Phase 7 — specific enough that a colleague could re-run this exact session and see the same thing.
Every suspected item from Phase 7, and the specific additional access or tooling that would resolve each one.
A real, specific next step — not "investigate further" alone.
2–3 sentences on what this fixed-command sandbox structurally cannot check (piped/chained commands, sudo -l, cron jobs, log files beyond what's readable here) — and why a real investigation would need that access before this could be fully closed out.
| Criteria | What "expert level" looks like |
|---|---|
| Investigation order | Identity → system → filesystem → process/network → follow-up, self-directed, not copied from a fixed checklist without reasoning |
| Mismatch handling | Phase 5 treats the unmatched port as a genuinely open question with multiple explanations, not a rushed verdict either way |
| Confirmed vs. suspected discipline | Phase 7 table is honest — not everything gets labeled "confirmed" just because it was found |
| Cross-phase reasoning | Phase 6 genuinely connects filesystem content to the network/process finding, rather than treating them as separate sections |
| Evidence precision | Section 4 of the deliverable is specific enough to be reproduced by someone else |
| Honest limitations | Section 7 correctly names what this specific sandbox cannot check, not a generic disclaimer |
sudo -l, cron) and what it would have let you check.Save your full session as your final report before closing the simulator. Title it "Kali Terminal — Expert Host Triage", and attach your complete 7-section Handover Note alongside the saved session.
grep? sudo -l? something else?) Justify your choice in 2–3 sentences.