Step 97. Bandit 6~10 — Mastering Conditional Searches with find

Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: you’ve finished the solving cycle from Step 96 and the Bandit 0→6 password chain. You know the basics of pipes (|).

What you need: an SSH connection environment, the password record you found in Step 96, and a local Linux/WSL setup for experiments.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
About the legal practice ground: OverTheWire Bandit is a legal learning platform whose operators officially permit attack practice. Use today’s search commands only on that server and in practice folders on your own computer.

The first question anyone asks when entering a server is "what’s in here?" The king of tools that answer that question is find. Name, size, owner, group, permissions, modification time — it’s a command that sweeps every file against any attribute you set as a condition. Bandit 6~10 is this tool’s training ground: a series of "find the file matching these conditions anywhere on the server" problems. Today’s real harvest isn’t the commands — it’s the thinking circuit that translates natural-language questions into condition combinations.

1. Learning Objectives

By the end of this chapter, you will be able to:

Combine find conditions (-user, -group, -size, -perm, -mtime, -writable) with AND to extract exactly the files you want
Filter out permission errors with 2>/dev/null and explain how it works
Pull the answer out of data with grep, sort | uniq -u, strings, and base64 -d
Explain what SUID files are and why they’re a staple reconnaissance target, and list them
Translate real-world questions like "recently changed files" or "files I can write to" into one-line find commands

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Linux shell (Bandit server + local WSL)
Today’s commands	`find`, `grep`, `wc`, `sort`, `uniq -u`, `strings`, `base64 -d`
Concepts needed	AND combination of conditions, redirection (`2>`), the SUID permission bit, encoding vs. encryption
Today’s artifact	Bandit 6→11 password chain + a find condition card document

2-1. find Syntax — Conditions Like Lego Bricks

find where -condition1 -condition2 ...

The more conditions you list, the more they narrow down with AND. Here are the condition pieces we’ll use today.

Condition	Meaning	Example
`-type f` / `-type d`	files only / folders only	`find . -type d`
`-name pattern`	name (wildcards allowed)	`-name "*.log"`
`-user name`	owner	`-user bandit7`
`-group name`	owning group	`-group bandit6`
`-size Nc`	size (c = bytes)	`-size 33c`
`-perm /4000`	SUID bit set	more on this later
`-mtime -1`	modified within a day	`-mtime -7` = last week
`-writable`	ones I can write to	`-writable -type f`

A ! in front of a condition is negation ("not"). And remember the tail 2>/dev/null, which discards the permission errors that flood the screen during a whole-server search. 2 is the error output channel’s number, and /dev/null is the discarding hole.

2-2. SUID — find’s Real Prey

Linux file permissions include one special bit. An executable with SUID (Set User ID) set runs with the file owner’s privileges the moment it executes. A program owned by root with SUID runs with root’s power no matter who launches it.

This mechanism exists because it’s needed — most notably passwd (the password-changing tool) must modify system files on behalf of regular users, so it’s SUID. But a vulnerable SUID program becomes a ladder that lifts a regular user up to administrator. That’s why the essential reconnaissance question is "what SUID files exist on this server?"

find / -perm /4000 -type f 2>/dev/null

-perm /4000 is the condition "SUID bit set." Today we’ll run it ourselves on our own computer.

2-3. One Line in the Data — The grep Family of Tools

The remaining problems in levels 6~10 are not "finding" but "extracting": one pattern from a tens-of-thousands-line file (grep), the unique line among endless duplicates (sort | uniq -u), readable strings from a blob of binary (strings), and unwinding a Base64-tangled string (base64 -d).

See the common thread? They’re all tools that "leave only the signal when there’s a lot of it." That work is the daily routine of log analysis and incident response.

3. Follow Along

3-1. Level 6 → 7 — A Whole-Server Conditional Search

Goal: "a file somewhere on the server, owned by bandit7, in group bandit6, 33 bytes in size."

Input (on the server, Screen example)

ssh bandit6@bandit.labs.overthewire.org -p 2220
find / -user bandit7 -group bandit6 -size 33c 2>/dev/null

How to read it: starting from / means we sweep the entire server. Three conditions overlap with AND to pinpoint one file out of tens of thousands. Thanks to 2>/dev/null, the screen stays clean.

Let’s reproduce the same conditional search on our own computer: make a 33-byte file, change its owner, then find it (measured 2026-09-09, WSL):

printf 'x%.0s' {1..33} > target33.txt
echo hello > other.txt
chown nobody:nogroup target33.txt
find . -user nobody -group nogroup -size 33c 2>/dev/null

Output (measured 2026-09-09):

./target33.txt

The three overlapping conditions filtered out other.txt and left only target33.txt. chown is the command that changes ownership — use it only on local experiment files.

3-2. Level 7 → 8 — One Line in a Huge File

Goal: the value next to the word "millionth" in data.txt.

Input (on the server, Screen example)

wc -l data.txt
grep millionth data.txt

Here’s a local reproduction that includes the habit of checking scale first (measured 2026-09-09, WSL — we made a 20,000-line file and planted the answer line at the end):

20001 data.txt
millionth R3alPassW0rdHere

How to read it: wc -l counts lines so you know the scale first, and grep pattern file extracts only the lines containing the pattern. "Pulling one pattern out of huge data" is log analysis itself.

3-3. Level 8 → 9 — The Line That Appears Exactly Once

This time the answer is "the only line that appears just once."

Input (on the server, Screen example)

sort data.txt | uniq -u

Local reproduction (measured 2026-09-09, WSL):

printf 'apple\nbanana\napple\ncherry\nbanana\nunique_line_xyz\napple\n' > data.txt
sort data.txt | uniq -u

cherry
unique_line_xyz

How to read it: once sort gathers identical lines together, uniq -u keeps only "the lines that appeared exactly once." Note that the two ends of the pipe are a set — using uniq without sorting misses duplicates that aren’t adjacent.

3-4. Level 9 → 10 — Strings Inside Binary

This data.txt is a binary file of mostly broken bytes, and the answer is a string with a few = characters inside it.

Input (on the server, Screen example)

strings data.txt | grep "=="

Local reproduction (measured 2026-09-09, WSL — an experiment file with a string planted inside binary):

printf '\xde\xad\xbe\xefReadablePart==secret_token==\x00\xffmore_binary\x01' > data.txt
strings data.txt | grep '=='

ReadablePart==secret_token==

How to read it: strings extracts only "human-readable string fragments" from binary. It’s also the first analysis command you run when you receive an unfamiliar executable.

3-5. Level 10 → 11 — Reversing Base64

This file is a long Base64 string of letters and digits.

Input (on the server, Screen example)

cat data.txt
base64 -d data.txt

Local reproduction (measured 2026-09-09, WSL):

echo 'VGhlIHBhc3N3b3JkIGlzIGJhbmRpdF9yb2Nrcwo=' > b64.txt
base64 -d b64.txt

The password is bandit_rocks

How to read it: Base64 isn’t encryption — it’s an encoding: the translation table is public, so anyone can reverse it with the same command. The trailing = is the telltale sign of Base64. A secret hidden in Base64 isn’t hidden — it’s merely written in odd-looking letters.

3-6. Listing SUID Files — A Standard Reconnaissance Scene

Input (measured 2026-09-09, WSL, Ubuntu 24.04):

find / -perm /4000 -type f 2>/dev/null

Output (measured 2026-09-09, partial):

/usr/bin/passwd
/usr/bin/sudo
/usr/bin/su
/usr/bin/mount
/usr/bin/umount
/usr/bin/chsh
/usr/bin/gpasswd
... (14 total)

How to read it: these are all "legitimate tools that need privileges." The problem is when something that has no reason to be there is mixed into this list. Attackers search this list for weak programs; defenders compare this list against a "known-good list." Same command, two perspectives.

Note: WSL is a minimal setup, so we got 14, but a typical server may have more. What matters isn’t the count — it’s the procedure of listing and comparing.

3-7. Condition-Design Training — Translating Questions into Commands

The core of find skill is "natural-language question → condition combination" translation. Try writing these five yourself first. The answers are in section 5.

All .log files under /var modified within the last 7 days
Files in my home folder larger than 10MB
Files under /tmp that I don’t own
Non-folder entries (files only) under /etc
Files with execute permission in the current folder

In +10M, the + means "more than" (the opposite, -10M, means "less than"); ~ is my home folder; $(whoami) is substitution syntax that places a command’s result right there.

Try it (verified by measurement on 2026-09-09, WSL): find . -type f -printf '%T+ %p\n' | sort | head -3 prints modification times together with paths, finding "the oldest file." Once you can craft output formats yourself with -printf, find is fully in your hands.

4. Missions & Exercises

Mission — A find Condition Card and Three Real Questions

Complete the Bandit 6→11 password chain and record each level in the write-up format from Step 96
Extract the SUID list on your own computer with find / -perm /4000 -type f 2>/dev/null, and organize what each entry is in a table (research its purpose with man or a search)
Create find-condition-card.md in your wiki — at least 7 condition options with example commands
Answer these three questions with one line of find each: ① files of 1MB or more in my home ② files modified today ③ all files with the .pem extension (key files)

Exercises

Exercise 1. Explain the role of each part (starting path, three conditions, tail) in find / -user bandit7 -group bandit6 -size 33c 2>/dev/null.

Exercise 2. What problem arises if you remove sort from sort data.txt | uniq -u?

Exercise 3. What does strings do, and in what situation is it the first tool you reach for?

Exercise 4. You’ve found a password written in Base64. State in one sentence why this is not "a safely protected password."

5. Model Answers & Completion Criteria

Mission Model Answer

Answers to the condition-design training (3-7):

find /var -name "*.log" -mtime -7 2>/dev/null
find ~ -type f -size +10M
find /tmp -type f ! -user $(whoami) 2>/dev/null
find /etc ! -type d
find . -type f -executable

Answers to the three real questions: ① find ~ -type f -size +1M ② find ~ -type f -mtime -1 ③ find / -name "*.pem" 2>/dev/null.

How to verify: ① does each option on the condition card have "an example I ran myself" attached? ② does each entry in the SUID table have a one-line purpose? ③ did you actually run the commands for the three questions and confirm the results with your own eyes? If you got at least three of the five problems right on your own, you’ve moved beyond "knowing" find to "using" it.

Exercise Answers

Answer 1. / is the search starting point (the whole server); -user/-group/-size 33c are three conditions overlapping with AND; and 2>/dev/null is the tail that discards permission-denied error output. Together they mean "from the entire server, quietly show me only the files that satisfy all three of these attributes."

Answer 2. uniq only compares adjacent lines, so without sorting it can’t catch identical lines that are far apart. sort | uniq is a set.

Answer 3. It’s a command that extracts only human-readable string fragments from a binary file. When you receive an unknown executable or dump, "strings first" is the first step of analysis (see how we pulled ==secret_token== out of binary in the measurement in section 3-4).

Answer 4. Because it’s an encoding with a public translation table, so anyone can reverse it with base64 -d without a key. The criterion separating encoding from encryption is "can it be reversed without a key?"

Completion Criteria Checklist

[ ] I can combine three or more find conditions to extract exactly the files I want
[ ] I can explain what 2>/dev/null means (discarding error output) and why it’s needed
[ ] I can explain what SUID is and why it’s a monitoring target
[ ] I can use grep, sort | uniq -u, strings, and base64 -d appropriately for each situation
[ ] I can translate a natural-language question into one line of find
[ ] Mission: I completed the chain, the condition card, and the SUID table

6. Common Pitfalls & Fixes

Wall 1. find comes back empty

Symptom: something should be there, but nothing shows up.
Cause: get even one condition wrong and AND leaves you empty-handed. Omitting the c in -size 33c is the most common cause (we hit the same wall in Step 96).
Fix: remove conditions one at a time and narrow down which condition is producing zero results. "Subtracting conditions" is the standard way to debug find.

Wall 2. "Permission denied" dominates the screen

Symptom (measurement-style messages):

find: '/root': Permission denied
find: '/proc/1234': Permission denied
... hundreds of lines

Cause: the fate of searching all of / — an error fires for every folder your permissions can’t reach.
Fix: append the 2>/dev/null tail. Starting narrow from folders of interest (/home, /tmp) is also a valid strategy.

Wall 3. sort | uniq -u shows a strange number of lines

Symptom: only one line should be unique, yet several lines appear.
Cause: differences in trailing newlines or whitespace can make "lines that look the same" actually different.
Fix: look at occurrence counts first with sort data.txt | uniq -c | sort -n | head. Once you can see the counts, the situation reads itself.

Wall 4. find takes forever on the Bandit server

Symptom: the / search takes minutes.
Cause: that’s normal — it’s sweeping tens of thousands of files.
Fix: wait, or narrow down in order starting from likely candidates (/etc, /var). Reconnaissance is a game with priorities too. On your own computer, find / also gets very slow if it sweeps mounts like /mnt/c — narrowing the scope is the answer (in the 2026-09-09 WSL measurement, we confirmed a full scan took over a minute).

7. Summary

Today’s Concepts

Concept	One-line explanation
AND combination of conditions	the more find conditions overlap, the narrower the result
`2>/dev/null`	sends error output (channel 2) into the discarding hole
SUID	a bit that makes a program run with the file owner’s privileges
Reconnaissance (recon)	the full sweep of "what is where" before an attack
Signal vs. noise	grep, uniq, strings are tools that leave only the signal in a crowd of data

Today’s Commands

Command	What it does
`find path -condition ...`	the king of conditional search
`find / -perm /4000 -type f 2>/dev/null`	full listing of SUID files
`grep pattern file`	extract only lines containing a pattern
`sort file \| uniq -u`	lines that appear exactly once
`strings file`	readable strings inside binary
`base64 -d file`	reverse Base64
`wc -l file`	check line count (scale)

An Instinct More Important Than Commands

All of today’s commands are one-liners. Yet that one line pulls "something odd" out of an entire server. Hacking tools don’t need to be grand — when the question is precise, the command gets short. And remember the two perspectives on the same command. The command that lists SUID files is both an attacker’s ladder hunt and a defender’s checklist. Tools are neutral; perspective sets the direction. Once find is in your hands, a server is no longer a black box — to the one who sets the conditions, every file becomes a list entry.

Once every box is checked, Step 97 is complete. Click the checkbox in the sidebar to save your progress.