Finding hidden files in Linux and why knowing what is concealed on a system is one of the first things a SOC analyst checks.
Introduction
Day 4. Bandit Level 3 to Level 4. The previous two levels dealt with filenames that were awkward to work with. This level introduces a different problem entirely. The file exists, it is readable and there is nothing unusual about its name. The only issue is that it is hidden. Running a standard ls command will not show it.
This level teaches how Linux handles hidden files and why the default directory listing deliberately leaves them out. That behaviour exists for good reasons in normal system use. In a security context it is also exactly the kind of thing an attacker exploits to conceal tools, scripts and stolen data on a compromised machine.
By the end of this article you will know how to reveal hidden files in any directory and why checking for them is a standard step in any host-based investigation.
Level Objective
The password for Level 4 is stored in a hidden file inside a directory called inhere, located in the home directory of bandit3. In Linux, any file or directory whose name begins with a dot is treated as hidden and excluded from standard directory listings. The goal is to find that file and read its contents.
Approach
I logged in using the password retrieved from Level 2 to Level 3:
ssh [email protected] -p 2220
The banner appeared and the prompt changed to bandit3@bandit:~$. I ran ls and saw one item in the home directory: a folder called inhere. I moved into it:
cd inhere
Inside inhere I ran a plain ls. Nothing appeared. The directory looked empty. I knew from the level description that a hidden file was in there so I ran the version of ls that reveals everything:
ls -la
A file appeared immediately: .hidden. The dot at the start of the name is what keeps it out of standard listings. I read it with cat:
cat .hidden
The password printed to the terminal.
Commands Used
# Connect to the Bandit server as bandit3 using the Level 3 password
ssh [email protected] -p 2220
# List the home directory contents to find the inhere folder
ls
# Move into the inhere directory
cd inhere
# Standard listing — shows nothing because the file is hidden
ls
# Full listing including hidden files with permissions and ownership detail
ls -la
# Read the hidden file to retrieve the password
cat .hidden
Command Breakdown
ls -la
The -l flag displays a long format listing showing permissions, ownership, size and timestamps for every file. The -a flag includes all files, including hidden ones whose names start with a dot. Together they give you the most complete view of a directory.
cd inhere
Changes your current working directory into the inhere folder. Navigation before inspection is standard practice when investigating an unfamiliar file system.
cat .hidden
Reads the contents of the file named .hidden and prints them to the terminal. The dot at the start is part of the filename, not a path prefix.
. prefix on filenames
Any file or directory in Linux whose name begins with a dot is treated as hidden by default. This is a convention built into the shell, not a permission setting. It does not make a file secure. It simply keeps it out of casual listings.
Lesson Learned
The main technical takeaway is that hidden files in Linux are not actually protected. They are simply excluded from default output. Any user with read permission on the directory can see and access them the moment they run ls -a. The dot convention exists to reduce visual clutter in normal use, not to provide security.
What surprised me was how automatic the assumption of an empty directory felt. I ran ls, saw nothing and my first instinct was to question whether I was in the right place. That instinct is exactly what an attacker is counting on. Making ls -la your default listing command rather than plain ls is a habit that pays off immediately.
Going forward I will never trust a plain ls result in an investigation context. Hidden files are too common and too significant to leave to default behaviour.
• ls -a — show all files including hidden ones without the long format detail
• ls -la — show all files with full permissions, ownership and timestamp information
• find . -name “.*” — search for hidden files recursively from the current directory
• cd .. — move back up one directory level
• cat .filename — read a hidden file by including the dot in the filename
🔴 SOC Analyst Insight
Hidden files and directories are a standard part of attacker tradecraft on Linux systems. After gaining initial access, threat actors commonly drop backdoors, persistence scripts and stolen credential files in locations designed to avoid detection. Naming those files with a leading dot keeps them out of any log review or manual inspection that relies on a plain directory listing.
# Search for hidden files modified in the last 24 hours across the entire system
find / -name “.*” -type f -newer /var/log/auth.log 2>/dev/null
During a triage of a compromised Linux host, one of the first things an analyst should do is sweep common directories like /tmp, /var/tmp, /home and user profile folders for hidden files created or modified around the time of the suspected intrusion. The command above narrows that search by recency, which is exactly the filter you want when you are working against a timeline.
This Bandit level is a clean example of why default tool behaviour is not the same as thorough investigation behaviour. The password was there the entire time. A plain ls just was not the right tool to find it.
Key Takeaway
Hidden files in Linux are not hidden from analysts who know what to look for. The dot convention keeps files out of casual view but offers zero protection against anyone running ls -la or find. Making the full listing command a reflex rather than an afterthought is one of the simplest and most impactful habits a junior SOC analyst can build. What you do not look for is what attackers rely on you missing.
📅 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. ← today
⬜ Day 5. — Bandit Level 4 → 5. | coming next
Follow along with the series as I document each level, command and lesson learned.
What you do not look for is what gets missed. Always run the full listing.
OverTheWire Bandit Walkthrough — Level 3 → 4 | 30-Day Cybersecurity Learning Journey (Day 4) was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.