How do attackers use /etc/passwd?

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.

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.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?