Identifying human-readable files using the file command and why knowing what type of data you are looking at is a fundamental triage skill.
Introduction
Day 5. Bandit Level 4 to Level 5. Every level so far has had one file to deal with. This one has ten. They all sit in the same directory, they all have similar names and only one of them contains the password in a format you can actually read. The challenge is figuring out which one without opening each file individually.
This level introduces the file command, one of the most useful tools in a Linux analyst’s toolkit. It reads the contents of a file and tells you what type of data it contains, regardless of what the file is named or whether it has an extension. That capability matters enormously in security work where files are frequently mislabelled, renamed or stripped of their extensions to avoid detection.
By the end of this article you will know how to identify file types at scale using a single command and why that skill belongs in every analyst’s standard triage workflow.
Level Objective
The password for Level 5 is stored in the only human-readable file inside a directory called inhere in the home directory of bandit4. The directory contains ten files named -file00 through to -file09. Most of them contain binary data that will not display cleanly in a terminal. One of them contains ASCII text, which is the human-readable file you need.
Approach
I logged in using the password retrieved from Level 3 to Level 4:
ssh [email protected] -p 2220
The banner appeared and the prompt changed to bandit4@bandit:~$. I ran ls and found the inhere directory. I moved into it:
cd inhere
Running ls -la showed ten files: -file00 through to -file09. Opening each one with cat was not a realistic approach. Binary files dumped into a terminal produce garbled output and can disrupt the terminal display entirely.
Instead I used the file command with a wildcard to check all ten files at once:
file ./*
The output listed every file alongside its data type. Nine of them showed binary or data output. One showed ASCII text. That was the file I needed. I read it directly:
cat ./-file07
The password printed cleanly to the terminal.
Commands Used
# Connect to the Bandit server as bandit4 using the Level 4 password
ssh [email protected] -p 2220
# List the home directory to locate the inhere folder
ls
# Move into the inhere directory
cd inhere
# List all files including hidden ones with full detail
ls -la
# Check the file type of every file in the directory at once
file ./*
# Read the human-readable file identified by the file command
cat ./-file07
Command Breakdown
file ./*
The file command reads the contents of a file and reports what type of data it contains. The ./* wildcard tells it to run against every file in the current directory. The ./ prefix is required here for the same reason as Level 1 to Level 2: the filenames start with a dash and without the path prefix the shell misinterprets them.
file
One of the most reliable identification tools available in Linux. It does not trust the filename or extension. It reads the actual bytes inside the file and identifies the format from the content itself.
ASCII text
When file reports this output it means the file contains plain readable characters that will display correctly in a terminal. This is the indicator you are looking for when searching for a password or readable credential among binary files.
./*
A wildcard expression that expands to every file in the current directory. Combined with ./ it correctly handles filenames that begin with dashes or other special characters.
Lesson Learned
The main technical takeaway is that filenames and extensions cannot be trusted to tell you what a file actually contains. The file command reads the raw data and identifies it from the content itself. That approach is reliable in a way that relying on names or extensions is not.
What made this level click was seeing how quickly file ./* resolved a problem that would have taken much longer if I had approached it manually. Ten files is manageable by hand. A directory with a hundred files is not. Building the habit of using file at scale from the start means you are already prepared for that scenario.
The other thing worth noting is that dumping binary files into a terminal with cat can corrupt your session display. Running reset fixes a corrupted terminal but it is better to identify file types first and avoid the problem entirely.
• file ./* — identify the type of every file in the current directory at once
• file filename — check the type of a single specific file
• reset — restore a terminal display that has been corrupted by binary output
• strings filename — extract readable text from a binary file
• ls -la — always check the full directory listing before acting on its contents
🔴 SOC Analyst Insight
In a real investigation, analysts regularly encounter directories full of files with no extensions, misleading names or renamed malware samples. An attacker who renames a malicious executable as update.log or config.bak is counting on the analyst or automated tool trusting the name rather than inspecting the content. The file command cuts through that immediately.
# Identify the true file type of all files in a suspicious directory during triage
file /tmp/* 2>/dev/null | grep -v “directory”
During malware triage on a compromised Linux host, running file across commonly abused directories like /tmp, /var/tmp and /dev/shm is a standard first step. An ELF executable masquerading as a text file or a shell script renamed to look like a log will not fool the file command. It tells you what the file actually is and that distinction matters when you are building an evidence picture under time pressure.
This Bandit level is a direct simulation of that triage workflow. Ten files, one correct answer, one command to find it efficiently. That is exactly how a prepared analyst approaches an unknown directory.
Key Takeaway
The file command is one of the most underrated tools in Linux security work. Filenames and extensions are trivial to fake. File contents are not. Building the habit of running file before cat on any unknown file protects your terminal session, saves time and gives you accurate information regardless of how the file has been named or labelled. In security work, trusting the content over the name is always the correct instinct.
📅 30-Day Cybersecurity Learning Journey — Progress
✅ Day 0. — Setup & Series Introduction. | OverTheWire Bandit
✅ Day 1. — Bandit Level 0 → 1. | SSH
✅ Day 2. — Bandit Level 1 → 2. | Special characters
✅ Day 3. — Bandit Level 2 → 3. | Spaces in filenames
✅ Day 4. — Bandit Level 3 → 4. | Hidden files
✅ Day 5. — Bandit Level 4 → 5. | File types. ← today
⬜ Day 6. — Bandit Level 5 → 6. | coming next
Follow along with the series as I document each level, command and lesson learned.
The filename tells you what someone wants you to think the file is. The file command tells you what it actually is.
OverTheWire Bandit Walkthrough — Level 4 → 5 | 30-Day Cybersecurity Learning Journey (Day 5) was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.