Attackers use /etc/passwd and /etc/shadow to enumerate local accounts and, when possible, obtain password hashes for offline cracking. Access to these files can reveal privileged users and enable credential theft or privilege escalation. Defenders should restrict read access tightly, monitor for unauthorised file access, and alert on tampering or unexpected copies.
What attackers get from /etc/passwd and /etc/shadow
/etc/passwd and /etc/shadow are useful because they expose different parts of local account data. /etc/passwd can reveal which users exist, which accounts are enabled, and which ones may have elevated privileges. /etc/shadow contains password hashes and aging data on systems where access is properly restricted, so a successful read can turn a local foothold into offline password cracking and broader account compromise.
That is why attackers often treat these files as discovery and credential material, not just configuration files. On Linux and Unix-like systems, they help answer two immediate questions: which identities are present, and can any of them be cracked, reused, or abused for lateral movement?
How the files support enumeration, cracking, and escalation
/etc/passwd is often the first file attackers inspect because it is a quick way to map the local account landscape. Even when password hashes are protected elsewhere, the file can still show usernames, home directories, shells, and account patterns that help an attacker identify real operators, service accounts, and dormant entries. Paired with other local data, that inventory can support targeted password guessing or privilege targeting.
/etc/shadow is more sensitive because it is where password hashes are normally stored. If an attacker can read it, they may try offline cracking without generating login noise. That matters because offline attacks are not rate-limited by the host, and cracked credentials can then be reused against sudo access, SSH, application logins, or adjacent systems that share passwords.
For a broader view of how credential theft and password-hash exposure are used in real intrusions, Credential Dumping Guide is the most directly relevant internal starting point, because the same attacker logic applies when local password material is exposed.
What defenders should assume when these files are exposed
The safe assumption is that exposure of either file can reveal enough structure to support escalation, even if the attacker does not immediately recover a password. /etc/passwd can confirm which accounts are worth attacking next, while /etc/shadow can convert a local access event into a credential recovery problem. That is especially important on systems where shared admin passwords, weak local passwords, or stale service accounts still exist.
Attackers also use copies of these files as evidence of deeper compromise. A seemingly minor read event can indicate that the attacker has already gained local execution or found another path to privileged file access. Once that happens, the issue is no longer just file confidentiality, it becomes account integrity and possible privilege abuse.
For broader attacker tradecraft around credential theft, account abuse, and escalation paths, The State of NHI & AI Agent Breach Report 2026 provides useful context on how stolen credentials become a movement and persistence mechanism.
Risk and Threat Considerations
Exposure of these files is high-value because it can reveal both identity inventory and secret material on the same host. A read primitive, misconfiguration, or privilege boundary failure can let an attacker enumerate privileged users and then work offline against password hashes without triggering normal authentication controls.
Failure mechanism: the attacker obtains read access to files that should be restricted, then uses account names, shells, and hashes to target privileged identities or recover usable credentials offline.
Impact: this can lead to credential theft, privilege escalation, lateral movement, and faster follow-on compromise, especially where passwords are reused or local admin hygiene is weak.
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 surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1003 — OS Credential Dumping | Covers attacker extraction of local password material for offline cracking and escalation. |
| Recommendation — Map exposure of local account files to credential-dumping detections and hunt for offline cracking activity. | ||
| CIS Controls v8 | CIS-5 — Account Management | Local account enumeration and privileged-user discovery depend on strong account governance. |
| Recommendation — Review local account inventory and remove dormant or unnecessary privileged accounts. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Restricting reads of /etc/shadow and related files requires least-privilege access enforcement. |
| AU-6 — Audit Review, Analysis, and Reporting | Unauthorized reads and tampering with account files need audit review and alerting. | |
| Recommendation — Enforce least privilege on sensitive account files and privileged maintenance paths. Review file-access logs for unusual reads, copies, and tampering. | ||
| ISO/IEC 27001:2022 | A.8.3 — Information access restriction | Sensitive account files require tightly restricted access and controlled handling. |
| Recommendation — Restrict access to password-hash files to approved privileged workflows only. | ||
Practitioner Guidance
What to verify: confirm that /etc/shadow is only readable by root or tightly controlled privileged processes, and review whether any automation, backup, container, or support workflow can copy it out indirectly. If /etc/passwd reveals unexpected interactive shells or privileged local accounts, treat that as a review trigger, not just an inventory issue.
Decision rule: if you find evidence that either file was copied, read by an unexpected process, or accessed outside normal maintenance windows, assume potential credential exposure and investigate for cracking attempts, new sudo use, SSH anomalies, and account tampering before you assume the system is clean.
Practitioner takeaway: the key question is not whether the files are present, but whether any path exists that lets an attacker read them without immediately being detected or blocked.