Security teams can detect access to /etc/passwd and /etc/shadow by monitoring file reads, copies, and unusual command activity from accounts that do not normally need them. Investigate rapid access to both files together, especially from shells, scripts, or backup tools. Exposure can support credential cracking and offline account enumeration.
What to look for when /etc/passwd and /etc/shadow are touched
Detection works best when you treat these files as a paired signal, not two isolated paths. A read of /etc/passwd alone can be benign, but reads or copies of /etc/passwd and /etc/shadow together, especially by an account that does not manage authentication, deserve attention. Focus on unusual shells, scripts, archive tools, and privilege escalation paths rather than filename hits in isolation.
On Linux, the useful question is whether the access pattern matches normal administration. Security teams should compare the source process, parent process, user context, and time of day against expected maintenance activity. Broad file-access monitoring is often too noisy unless it is tuned to high-value paths such as the credential stores and their immediate surrounding activity.
For defenders who want a broader pattern library around credential theft and post-exploitation collection, the Credential Dumping Guide is a useful reference point because the same investigative logic often applies when attackers move from account files to broader credential material.
Which processes and behaviors are most suspicious
The highest-value detections usually come from process context, not the file name alone. Look for unexpected cat, cp, tar, rsync, backup utilities, scripting interpreters, or archive commands reading both files in quick succession. A shell launched by a web server, CI job, or service account is more suspicious than the same file activity from a known administrative session.
Behavioral clues also matter. Rapid access followed by compression, outbound transfer, temporary file creation, or attempts to stage the files into world-readable locations can indicate collection for offline cracking. If the access comes from a compromised account with elevated filesystem reach, the file-read event may be the first visible step rather than the whole incident.
That is why file monitoring should be joined with execution telemetry, authentication logs, and privilege-use logs. A single read event is often ambiguous; a read plus process ancestry, plus network transfer, plus unusual account context is much more actionable.
How to reduce noise while keeping the signal
To make these detections practical, build allowlists around well-understood administration and backup workflows, then alert on deviations. The most useful filters are often based on expected host role, expected account, and expected process lineage, because those three factors explain most legitimate accesses. Without that baseline, teams tend to drown in routine reads performed by scanners, backup agents, and configuration tools.
Retention matters as much as alerting. If you cannot reconstruct who read the files, from where, and through which process, you will struggle to distinguish maintenance from collection. File-integrity monitoring, auditd-style path auditing, endpoint telemetry, and central log correlation give you the best chance of proving whether the access was routine or part of credential compromise.
For teams that want a control-oriented lens on the same problem, NIST Cybersecurity Framework 2.0 is a useful anchor for organizing detect and respond coverage around high-value asset monitoring and investigation workflows.
Risk and Threat Considerations
Access to these files is not just a disclosure event, it is often an enablement event for offline credential attacks. /etc/passwd can help enumerate accounts, while /etc/shadow can expose password hashes that attackers may try to crack after the initial compromise. The main threat is not merely reading the files, but using them to widen access, move laterally, or persist with stolen credentials.
Failure mechanism: Attackers obtain shell or service access, read the account databases, then convert that local exposure into hash cracking, account discovery, and follow-on privilege abuse. Because the reads are often small and look like normal filesystem activity, they can evade weak monitoring unless file access is correlated with process and user context.
Impact: Successful collection can accelerate full host compromise, support reuse of cracked passwords elsewhere, and undermine confidence in any account that shared a password or credential pattern. The most damaging outcome is usually not the file access itself, but the authentication exposure that follows.
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 NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1003 — OS Credential Dumping | Reading /etc/shadow for offline cracking is credential-dump behavior. |
| Recommendation — Map file access to credential-dumping activity and hunt for post-access collection steps. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find events | Detecting sensitive-file access depends on continuous monitoring of events and anomalies. |
| Recommendation — Monitor high-value file access and alert on unusual reads by unexpected accounts or processes. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | File-read detection depends on generating audit records for sensitive paths and process context. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Investigating suspicious reads requires review and correlation of audit evidence. | |
| Recommendation — Enable audit generation for sensitive file access and retain the context needed for investigations. Correlate file-access events with process ancestry and user context during review. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Sensitive-path monitoring and investigation rely on centralized, reviewable logs. |
| Recommendation — Centralize and review logs that show who accessed sensitive account files and how. | ||
Practitioner Guidance
What to verify: Confirm whether the reading account should ever need direct access to either file, whether the access happened from an interactive shell or a non-interactive process, and whether the same actor touched both files in a short window. That combination is usually more important than any single event.
Decision rule: If the access comes from a non-administrative context, treat it as potential credential collection first and routine maintenance second. If the files were copied or compressed, move immediately to host triage and credential exposure assessment rather than waiting for proof of cracking.
Practitioner takeaway: The best detections are sequence-aware, not filename-aware: pair the file read with process lineage, account context, and follow-on staging activity so you can separate normal administration from credential harvesting.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org