The Filesystem Hierarchy
The Linux directory tree (FHS): where configs, binaries, logs, and secrets live - and where attackers look first.
The Linux filesystem is a map of the entire system - and if you know how to read it, you know exactly where to look for credentials, configs, logs, and misconfigurations before an attacker does.
Authorized Access Only
Understanding where sensitive files live is essential knowledge for both attackers and defenders. Only explore filesystems on systems you own, operate, or have explicit written authorization to test. Unauthorized access to files is illegal regardless of whether you exploit them.
Everything Is a File
One of Linux's core design philosophies is "everything is a file." Processes? Files (in /proc). Network sockets? Files. Hardware devices? Files (in /dev). Configuration? Files. This uniformity is incredibly powerful - any tool that reads files can interact with nearly any part of the system.
It also means understanding the filesystem layout is understanding the system.
The Filesystem Hierarchy Standard (FHS)
The FHS defines where things live. Every major Linux distro follows it closely. Here's the full tree with security annotations:
Let's walk through each directory that matters:
/ - The Root
Everything in Linux lives under /. Unlike Windows (which has C:\, D:\, etc.), Linux has a single unified tree. Network shares, USB drives, virtual filesystems - they're all mounted somewhere under /.
When you see a path starting with /, it's an absolute path - unambiguous, always the same regardless of where you are.
/etc - Configuration (Attacker's First Stop)
/etc contains system-wide configuration files. This is one of the first places a post-exploitation attacker examines, and for good reason:
| File | What it contains |
|---|---|
/etc/passwd | User account info (readable by everyone) |
/etc/shadow | Password hashes (root-only read) |
/etc/hosts | Static hostname-to-IP mappings |
/etc/hostname | The machine's hostname |
/etc/crontab | Scheduled tasks (look for root-owned writable scripts) |
/etc/sudoers | Who can run what as root |
/etc/ssh/sshd_config | SSH server configuration |
/etc/network/interfaces | Network configuration (Debian/Kali) |
/etc/os-release | Distro and version information |
Why /etc/passwd Is World-Readable
In the old days, /etc/passwd actually stored password hashes. When it became world-readable (programs need it to map UIDs to usernames), the hashes moved to /etc/shadow which is root-only. If you ever find a system where /etc/shadow is readable by your unprivileged user, that's a serious misconfiguration - and the hashes inside are crackable.
/var - Variable Data (Logs Live Here)
/var holds data that changes constantly during operation. The most important subdirectory for security work:
/var/log/- system logs. Auth logs, syslog, application logs. This is where incident responders look and where attackers try to cover their tracks./var/www/- default web root. Source code for web apps often lives here./var/spool/cron/- per-user crontabs./var/lib/- persistent application data (databases, package manager state).
That last line? Someone just ran sudo /bin/bash - escalating to root. Auth logs tell the story of every login and privilege change.
/home - User Home Directories
Each regular user gets a subdirectory here: /home/alice, /home/bob, etc. Home directories contain:
- Shell config files (
.bashrc,.zshrc,.bash_history) - SSH keys (
~/.ssh/) - Browser data, saved credentials
- Personal scripts and projects
The .bash_history File
~/.bash_history records commands the user has run. In a pentest, reading it after gaining access can reveal passwords typed as command arguments, IP addresses of other systems, script locations, and more. Defenders: consider HISTCONTROL=ignorespace and audit what your users are doing.
/root - Root's Home Directory
The superuser's home directory is /root, not /home/root. It's separate and typically readable only by root. If you can read /root, you've effectively already won. Check for:
/root/.ssh/- SSH private keys that might grant access to other systems/root/.bash_history- commands run as root- Any scripts or credential files
/tmp - World-Writable Temporary Files
/tmp is readable and writable by every user. Files here are typically deleted on reboot. It's used for inter-process communication and temporary storage.
From an attack perspective:
- Uploading tools/payloads - attackers often write tools to
/tmpbecause it's always writable - Symlink attacks - if a privileged process writes to
/tmppredictably, it can be exploited - Evidence - malware often stages in
/tmp; forensics should always check here
The Sticky Bit on /tmp
Run ls -ld /tmp and you'll see permissions like drwxrwxrwt. That trailing t is the sticky bit - it means users can write files to /tmp, but can only delete their own files. Without it, any user could delete any other user's temp files. We'll cover this in the Permissions lesson.
/usr - User Binaries and Libraries
Despite the name, /usr isn't primarily about users - it contains most installed programs and libraries:
/usr/bin/- installed command-line programs (python3,curl,wget,git)/usr/sbin/- system administration programs (typically need root)/usr/lib/- shared libraries (.sofiles)/usr/share/- architecture-independent data, documentation, word lists/usr/local/- software you compiled/installed manually (not via package manager)
On Kali, /usr/share/wordlists/ contains rockyou.txt and SecLists - massive password and fuzzing wordlists that every pentester uses daily.
/bin and /sbin - Essential Binaries
On modern systems with systemd, /bin is often a symlink to /usr/bin, and /sbin is a symlink to /usr/sbin. Historically these held the essential binaries needed to boot the system before /usr was mounted.
ls -la /bin
# lrwxrwxrwx 1 root root 7 Jan 15 2024 /bin -> usr/bin/opt - Optional/Third-Party Software
Large third-party applications often install here. Think commercial software, manually installed tools, or applications that don't fit the standard hierarchy. In security contexts:
- Commercial scanners (Nessus, Burp Suite Pro) often install to
/opt - Custom applications in enterprise environments often live here
- If you see interesting directories in
/optduring a pentest, they're worth examining for config files, credentials, and privilege escalation vectors
/proc - The Process Filesystem (Virtual)
/proc is not on your disk. It's a virtual filesystem that the kernel generates on the fly to expose information about running processes and system state.
Each numbered directory in /proc corresponds to a running process ID. For any process, you can read:
/proc/<PID>/cmdline- the exact command that started the process/proc/<PID>/environ- the process's environment variables (may contain secrets!)/proc/<PID>/exe- symlink to the binary/proc/<PID>/fd/- open file descriptors
Environment Variables Can Leak Credentials
Developers often pass database passwords, API keys, and tokens as environment variables. On a compromised system, checking /proc/<PID>/environ for interesting processes (web servers, databases) is a classic privilege escalation research step.
Absolute vs. Relative Paths
This distinction trips up beginners constantly. Master it now.
An absolute path starts from the root /. It's the same regardless of where you are:
/etc/passwd # Always refers to this exact file
/home/kali/.ssh/id_rsa
/var/log/auth.logA relative path starts from your current working directory. It changes meaning depending on where you are:
passwd # The file named "passwd" in your current directory
../etc/passwd # Go up one level, then into etc/, then passwd
./script.sh # Run script.sh in the current directory.. means "parent directory." . means "current directory."
Where Attackers Look First
When a pentester gets a shell on a Linux box, they have a mental checklist of high-value locations. Here's a condensed version organized by what they're hunting:
Credentials and secrets:
/etc/passwd # usernames, UIDs, home dirs, shells
/etc/shadow # password hashes (needs root)
~/.ssh/ # SSH private keys
~/.bash_history # commands with passwords typed in plaintext
/var/www/*/config* # web app database credentials
/opt/*/config* # third-party app configs
/proc/*/environ # environment variables of running processesSystem understanding:
/etc/os-release # what distro/version
/etc/hostname # machine name
/etc/hosts # internal hostnames (reveals network topology)
/etc/crontab # scheduled tasks (privesc vector)
/var/spool/cron/ # per-user crontabs
/etc/sudoers # sudo permissionsNetwork and services:
/etc/network/ # network config
/etc/resolv.conf # DNS servers
/var/log/ # logs (auth, syslog, app logs)Think Like an Auditor
Whether you're a pentester or a sysadmin doing a security review, this same list tells you what to protect. Restrict permissions on sensitive files, monitor for unusual access, and audit what's world-readable that shouldn't be.
Key Takeaways
- The Linux filesystem is a single unified tree rooted at
/. Every file, device, and process is accessible from here. /etccontains system configuration - the most credential-rich directory for post-exploitation research./var/logcontains logs - both the evidence of attacks and a target for attackers trying to cover their tracks./tmpis world-writable and a common staging area for uploaded payloads./procis a virtual filesystem exposing live process and system state, including potentially credential-containing environment variables.- Absolute paths start with
/and are always unambiguous. Relative paths depend on your current directory. - Knowing where configs, logs, and secrets live is the foundation of both attacking and hardening Linux systems.