Reduce risk by restricting write access to both files, using strong file permissions, and monitoring for unauthorised changes. Protect account and password data with least privilege, file integrity monitoring, and secure credential storage. Investigate edits that add users, change password hashes, or weaken authentication, because tampering can create persistent access.
How /etc/passwd and /etc/shadow get exposed
/etc/passwd and /etc/shadow are high-value local account files because they can change who can log in and how password hashes are protected. The practical risk is not only read access, but tampering: if an attacker can modify either file, they may create new accounts, weaken authentication, or replace hashes to preserve access.
The files matter differently. /etc/passwd is typically world-readable but should remain tightly controlled for writes, while /etc/shadow must be protected from ordinary users entirely. The real control objective is to prevent unauthorised changes, not just to hide the filenames. Credential Dumping Guide is useful here because it covers credential material in files, including /etc/passwd and /etc/shadow, alongside detection patterns for credential theft and tampering.
On hardened systems, the main exposure path is usually privilege compromise first, file modification second. That means a weak sudo rule, a misowned file, or an over-permissive administrative workflow can become a persistent access path even when the passwords themselves are strong. Monitoring should therefore focus on both file integrity and the processes allowed to touch account data, not just on login failures.
Which mitigations actually reduce the risk
The most effective mitigations are basic but must be precise: restrict write access, enforce correct ownership and permissions, and make sure only approved administrative paths can update account records. Least privilege is the core control principle, because the attack becomes much harder when the files cannot be altered by everyday users, scripts, or services that do not need that capability.
Secure credential handling also matters. Password hashes in /etc/shadow should not be treated as ordinary data, and systems that export, back up, replicate, or automate around these files need the same care as any other sensitive identity store. CISA cyber threat advisories are a sensible external reference point for current threat handling and response practices when local account files are suspected of being altered.
File integrity monitoring adds the detection layer that permissions alone cannot provide. It should alert on edits, permission drift, owner changes, unexpected account additions, and changes to password hashes or authentication-related fields. Where possible, pair that with configuration management or immutable baselines so that a legitimate change has a known source of truth and an audit trail.
Backups and recovery procedures should also be part of the mitigation set. If these files are damaged or intentionally altered, you need a trustworthy way to restore correct account state without reintroducing the compromise. That means the backup itself must be protected from the same privilege path that could be used to alter the live files.
What to check if tampering is suspected
If the concern is active compromise, focus first on whether the file change created or preserved access. A new UID 0 account, an appended backdoor entry, a modified password hash, or a passwordless account field is more important than cosmetic edits. These changes can turn a one-time intrusion into durable access.
Review the surrounding evidence, not just the files themselves. Shell history, sudo logs, file integrity alerts, audit logs, and recent package or configuration changes can show whether the edit came from an administrator, a script, or an attacker. The key question is whether the file change is part of a broader privilege escalation or persistence chain.
If you confirm unauthorised modification, rotate any credentials or secrets that may have been exposed through the same access path, and validate that no additional local accounts, SSH keys, or scheduled jobs were planted for re-entry. Recovery should include a careful revalidation of account state after restoration, not only a return to a known file version.
Risk and Threat Considerations
The main risk is persistence through trusted account data. If an attacker can modify these files, they may bypass normal authentication controls without needing to exploit a service repeatedly, which makes the compromise durable and harder to notice.
Failure mechanism: Weak file ownership, overbroad sudo access, or a compromised privileged process allows unauthorised edits to account fields, password hashes, or login permissions, which can silently change who is able to authenticate.
Impact: The result can be persistent local access, privilege escalation, account creation, or denial of legitimate access, with recovery complicated by the fact that the malicious change may look like ordinary administrative activity.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits who can modify sensitive account files and related admin paths. |
| SI-7 — Software, Firmware, and Information Integrity | Covers monitoring and alerting on unauthorised file and integrity changes. | |
| IA-5 — Authenticator Management | Applies because password hash handling and credential lifecycle are central to shadow-file protection. | |
| Recommendation — Restrict write access to account files and the tools that manage them. Deploy integrity monitoring to detect unauthorised edits to /etc/passwd and /etc/shadow. Manage password material carefully and rotate credentials when account-file compromise is suspected. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Protects sensitive credential material stored or handled in account files and backups. |
| Recommendation — Protect stored credential material with approved cryptographic and storage controls. | ||
| CIS Controls v8 | CIS-5 — Account Management | Directly addresses local account creation, modification, and removal risks tied to these files. |
| Recommendation — Review account changes and remove unauthorized or stale local accounts promptly. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Models attacker behavior that edits account data to maintain persistence or access. |
| Recommendation — Hunt for account manipulation indicators when these files change unexpectedly. | ||
Practitioner Guidance
What to prioritise: Treat /etc/shadow as the higher-sensitivity target, but do not underplay /etc/passwd, because tampering with either file can alter authentication outcomes. The first control question is whether any non-essential process can write to either file or the directories that contain them.
What to verify: Check ownership, mode bits, sudo rules, immutable attributes where used, and whether monitoring alerts on both content drift and permission drift. A good control set should catch both direct edits and indirect changes made by privileged automation.
Practitioner takeaway: The strongest mitigation is not a single hardening step, but a combination of minimal write access, trustworthy change detection, and fast investigation of any account-file edit that could create persistence.