Attackers read /etc/passwd to enumerate local accounts, usernames and home directories, then use that information for password guessing, phishing or lateral movement. In older systems, the file also exposed password hashes. Defenders should keep it world-readable only as required, protect /etc/shadow separately and remove unnecessary accounts.
Why /etc/passwd Is Valuable to Attackers Before They Touch a Password
/etc/passwd is not usually the secret itself, but it is a high-value source of naming and structure. Attackers use it to map valid local accounts, spot default or service-style usernames, and infer home directory paths, login shells, and naming conventions. That reconnaissance helps them choose better guesses, target phishing, or pivot from one host to another once they find a reusable password or token.
The file can also reveal which accounts are worth testing first. Even when no password hashes are stored there, the account inventory gives an attacker a faster route to credential stuffing, password spraying, or social-engineering campaigns because it removes guesswork about who exists on the system.
What /etc/passwd Can Reveal in Real Environments
On modern Linux and Unix systems, /etc/passwd commonly contains usernames, user IDs, group IDs, home directories, shells, and account comments. Those fields are enough to identify human users, application accounts, shared service identities, and patterns in how the environment is administered. Attackers often combine that with other low-noise findings, such as shell access, file ownership, cron jobs, or web application paths, to build a fuller picture of the host.
In older or misconfigured systems, /etc/passwd may still have historically sensitive entries or point to weaker account hygiene. The real issue is not just the file format, but the fact that account metadata can become a launchpad for further compromise when defenders leave stale accounts, predictable naming patterns, or inconsistent access controls in place. For a broader view of how attackers chain that kind of discovery into account abuse and lateral movement, see The State of NHI & AI Agent Breach Report 2026.
How Defenders Should Read the Risk Around /etc/passwd
The practical risk is account enumeration, not just file exposure. If an attacker can read /etc/passwd, they can turn a single host foothold into a better targeting list for password guessing, phishing, and privilege escalation attempts. If the environment still leaks password material through legacy configuration, the exposure is much worse because the same file view can shorten the path from reconnaissance to compromise.
Failure mechanism: the system exposes account metadata broadly, or stores credentials in a way that lets a low-privilege user learn too much about valid logins and their structure. That weakens the defender’s assumptions about obscurity, increases the efficiency of guessing attacks, and can aid movement across hosts when usernames and account patterns are reused.
Impact: attackers can identify real accounts faster, focus abuse on higher-value targets, and use the recovered naming pattern to improve password spraying, phishing pretexting, or follow-on access attempts. Where older systems or poor hardening still expose password material, the same reconnaissance can become direct credential compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1087 — Account Discovery | Enumerating usernames and local accounts is the core attacker use of /etc/passwd. |
| T1003 — OS Credential Dumping | Older or misconfigured systems may expose password material that supports credential theft. | |
| Recommendation — Hunt for account discovery activity and review local account enumeration telemetry. Investigate credential exposure paths and rotate any credentials recovered from the host. | ||
| CIS Controls v8 | CIS-5 — Account Management | The subject is about local account exposure and unnecessary accounts on Unix systems. |
| Recommendation — Inventory local accounts and remove or disable unnecessary identities. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Defensive guidance centers on protecting password material and rotating exposed credentials. |
| AC-6 — Least Privilege | Limiting who can read account metadata reduces reconnaissance and misuse. | |
| Recommendation — Enforce secure authenticator lifecycle controls and rotate exposed secrets immediately. Restrict file access to the minimum roles that truly need it. | ||
Practitioner Guidance
What to verify: Confirm that /etc/passwd is world-readable only where the operating model requires it, and verify that no sensitive credential material is present there. Check that /etc/shadow remains restricted, that service accounts are justified, and that account comments, shells, and home paths do not reveal more than necessary.
What practitioners underestimate: Enumeration value compounds across systems. A single readable file may seem low impact, but repeated username patterns, default shells, and shared service naming conventions make spraying and phishing materially more effective at scale.
Decision rule: If the file exposes only routine account metadata, treat it as a reconnaissance concern and focus on hardening, hygiene, and detection. If it exposes or implies credential material, treat it as a credential exposure incident and investigate for reuse, lateral movement, and earlier access.
Practitioner takeaway: The security problem is usually the account map, not the file itself, so defenders should reduce what the file reveals, remove unnecessary accounts, and assume attackers will use the metadata to target the weakest login path next.