/etc/passwd and /etc/shadow are Linux account files that store user metadata and password hashes or protected password data. Attackers target them to steal credentials or create offline crackable copies, so defenders should restrict access, monitor reads, and watch for unexpected changes to authentication records.
How /etc/passwd and /etc/shadow work together
On Linux, /etc/passwd provides account metadata such as usernames, user IDs, home directories, and shells, while /etc/shadow holds protected password hash data and related aging fields. The split lets the system keep basic identity records broadly readable while restricting the sensitive secret material needed for authentication.
This division is foundational to local account authentication, because the login flow needs to resolve an account first and then verify the secret material separately. When the files are configured correctly, the design reduces unnecessary exposure of password data without breaking normal user lookup.
Why these files are attractive to attackers
Attackers value these files because they can turn authentication records into offline cracking material. If they can read /etc/shadow, or obtain a copy of both files, they may test hashes away from the host without triggering live login controls or lockout logic.
Credential Dumping Guide is relevant here because the same defensive logic applies to Linux account records as to other credential stores: once secret material is exposed, the attacker’s goal becomes extraction, reuse, or offline cracking rather than direct interactive compromise.
That is why reads of authentication files matter even when no immediate account takeover is visible. A quiet file read can still become a later password-guessing campaign, credential stuffing source, or stepping stone to broader privilege abuse.
What exposure looks like in practice
Exposure usually comes from weak file permissions, overbroad administrative access, misconfigured backups, untrusted containers, or compromised accounts that can read sensitive system files. On hardened systems, ordinary users should not be able to read /etc/shadow, and access to both files should be limited to the minimum required system processes and administrators.
Organisations should verify exposure by checking the live file permissions, reviewing privileged group membership, and confirming that copies do not leak into backup sets, images, or configuration exports. A file that is protected on disk can still become exposed through snapshot systems, image layers, or support tooling that preserves host state.
Monitoring should also treat unexpected reads as a signal. Repeated access from unusual processes, privileged shells, automation jobs, or post-exploitation tooling may indicate credential harvesting, especially when followed by changes to account records or password-related files.
Defensive handling, monitoring, and recovery
Defence starts with tight access control, file integrity monitoring, and careful handling of administrative workflows that need to inspect account data. If a host or account is compromised, defenders should assume the attacker may already have copied the files and may try offline cracking even after the host is cleaned.
NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with the need to restrict access, log privileged activity, and monitor for integrity changes to authentication records. NIST Cybersecurity Framework 2.0 also fits because the subject spans protection, detection, response, and recovery of a basic identity asset. CIS Benchmarks are useful where administrators need concrete hardening guidance for Linux file permissions and account-related system settings.
After a suspected read or copy, incident responders should review authentication logs, recent privilege changes, and account activity for signs of misuse. If there is evidence the files were exposed, password resets alone may be insufficient unless attackers could also have obtained cached credentials, reused passwords, or privilege-bearing accounts.
Risk and Threat Considerations
The core risk is that protected authentication records can be copied once and attacked many times offline. Even a brief exposure window can matter, because an attacker who gets the files may not need continued host access to keep working on the hashes.
Failure mechanism: Weak permissions, reused administrative access, exposed backups, or post-compromise tooling can let an attacker read the files, copy them out, and crack passwords without interacting with the live system again.
Impact: The result can be account takeover, lateral movement, privilege escalation, and reuse of cracked passwords across other systems, especially if password hygiene is weak.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits who can read protected authentication files and related copies. |
| AU-2 — Event Logging | Supports recording reads and changes to sensitive authentication records. | |
| SI-7 — Software, Firmware, and Information Integrity | Covers detection of unexpected changes to account and authentication data. | |
| Recommendation — Restrict file and administrative access to authentication records to the minimum necessary users and processes. Log privileged reads and modifications of account files so suspicious access can be investigated. Monitor authentication files for unauthorized or unexpected integrity changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Addresses control of accounts and access paths tied to local authentication records. |
| Recommendation — Limit and review administrative access to local account and authentication records. | ||
Practitioner Guidance
What to watch for: Treat any unexpected read of /etc/shadow, sudden permission drift on account files, or unexplained changes to authentication records as a security event, not a routine admin task. The most useful judgement is whether the access was required by a known maintenance activity and whether the resulting exposure could already have been copied off-host.
Practitioner takeaway: Protecting these files is less about secrecy in the abstract and more about preventing a small file read from becoming an offline credential recovery problem.