KW KeAndre Williams Financial Analyst · Data Scientist · Systems Builder

Lab / 2025-03-02

OverTheWire Bandit — Linux fundamentals, levels 0–5

A working log of the first six Bandit levels — completed 0 through 5 — framed as the Linux and shell concepts each one drills, not as answers to copy.

Environment
OverTheWire practice servers (SSH)
Tools
Linux, bash, ssh, cat, file, find, ls

Scope — levels 0–5, and no passwords

I completed levels 0 through 5. This is not a full-game walkthrough, and it deliberately contains no level passwords. Each entry records the concept the level teaches and the command pattern that solves that class of problem — which is the part that transfers to real work. The specific answers are left out on purpose; publishing them defeats the exercise and hiring managers can tell the difference.

Progress

Levels 0 → 5 completed (6 levels). Each level's password unlocks SSH access to the next, so the chain is linear: solve level n to log into level n+1.

Why these levels are worth documenting

The opening Bandit levels aren't a security challenge so much as a filesystem and shell-fluency drill. They force you into the corners of tools you think you know: files whose names fight the shell, hidden files, distinguishing text from binary, and locating a file by its metadata instead of its name. Those are exactly the primitives you fall back on during log triage and forensic work, which is why I kept notes.

Level 0 → 1 — reading a file in place

The starting point: SSH in, and read a plainly named file in the home directory.

cat readme

Concept: the absolute basics — where you land on login, and reading a file's contents to stdout. Nothing adversarial yet; it's establishing the loop of "connect, look around, read."

Level 1 → 2 — a filename the shell treats as a flag

The file is named -, which cat tries to interpret as an option, not a path.

cat ./-        # disambiguate with a relative path
cat < -        # or feed it via stdin redirection

Concept: arguments beginning with - are parsed as flags. You break the ambiguity by giving a path the parser can't mistake (./-) or by routing the file through redirection so it's never an argument at all. This exact problem shows up any time you handle attacker- or user-controlled filenames.

Level 2 → 3 — spaces in a filename

The filename contains spaces, so the shell splits it into several arguments.

cat "--spaces in this filename--"      # quote the whole thing
cat \-\-spaces\ in\ this\ filename\-\- # or escape each space

Concept: word-splitting. Quoting or escaping makes the shell treat the whole string as one argument. The same reflex prevents a whole category of scripting bugs — and injection bugs — later on.

Level 3 → 4 — hidden files

The target is a dotfile, invisible to a plain ls.

cd inhere
ls -la          # -a reveals dotfiles; -l shows details
cat .hidden     # (name taken from the ls -la output)

Concept: files beginning with . are hidden by convention, not permission. ls -a exposes them. In practice this is where configuration, credentials, and persistence mechanisms hide — a defender checks dotfiles by habit.

Level 4 → 5 — telling text from binary

The directory holds many files; only one is human-readable text.

cd inhere
file ./*        # classify each file by its actual contents
cat ./-file07   # read the one reported as ASCII text (name will vary)

Concept: file inspects contents rather than trusting the extension or name. Knowing what a file actually is before you open it is a basic safety and triage habit — you don't cat an unknown binary into your terminal.

Level 5 → 6 — finding a file by its attributes

The password file is somewhere in a tree, identified only by its properties: a specific size, a regular file, not executable.

find inhere/ -type f -size 1033c ! -executable
# then read whatever path find returns

Concept: find with predicate filters — -type f for regular files, -size 1033c for an exact byte count, ! -executable to exclude executables. This is the single most transferable skill in the set: locating files by metadata is the core move in forensic triage, hunting for artifacts, and sweeping a compromised host for files that match a known indicator.

Where this connects to defensive work

Every primitive here reappears when you audit or harden a host: dotfiles hide config and persistence, file keeps you from trusting a name over contents, and find by size, type, permission, or modification time is how you sweep a system for what shouldn't be there. The levels are toy-sized; the muscle memory isn't.

What I did next

Carried the find-by-metadata pattern straight into the Active Directory detection lab, where the same instinct — locate artifacts by their properties, not their labels — is what turns a pile of logs into a detection.

All work described here was performed against systems I own, in a network-isolated lab, for defensive research.