How do you detect copying of passwd or shadow files on Linux?

What to watch for when passwd or shadow access looks suspicious

Unusual access to /etc/passwd or /etc/shadow is more meaningful when it does not line up with a real admin task. The signal is strongest when the file access comes from a shell, archive utility, scripting process, or remote copy tool, especially after privilege escalation or from an account that normally does not manage local identities.

Focus on process context, not just the file event. A legitimate password or account change workflow usually has a clear operator, an expected source host, and a known destination. Copying for exfiltration often shows a chain such as sudo or another privilege change, followed by read access, then compression, staging, or outbound transfer.

For broader host hardening and audit coverage around file access, review the Linux Server Hardening Guide, which covers auditd, baseline hardening, and file integrity monitoring on Linux systems.

Why this matters operationally

/etc/passwd is often readable by many users, but /etc/shadow should be tightly protected. If an attacker can copy these files, they may gain offline material for password cracking, account enumeration, or follow-on targeting of weak or reused credentials. That makes the event useful both as a possible compromise indicator and as a sign that your local access controls may already be too loose.

Detection should therefore look for the whole sequence, privilege gain, file reads, collection, and outbound movement. A single read may be benign on its own, but repeated access, access from unusual parent processes, or reads followed by archiving or transfer utilities should raise confidence that the event is not routine administration.

For Linux-specific operational controls that reduce this exposure, the Linux Server Hardening Guide is the most directly useful internal reference for audit logging, sudo discipline, and baseline system hardening.

How to investigate and confirm intent

Start by verifying who accessed the files, from which process, and under what privilege context. Review process ancestry, command lines, and the destination path if the files were copied or staged. If the access came from a compressed archive, remote copy session, or scripted collection path, treat that as stronger evidence than a simple read through an interactive shell.

Then correlate the access with nearby signals such as new archive files, temporary directories, unusual outbound connections, or later authentication anomalies. If the file access aligns with privilege escalation and outbound transfer activity, assume the event may be part of an exfiltration chain until proven otherwise.

For a detection pattern that maps directly to credential theft and offline abuse, the Credential Dumping Guide is useful because it covers file-based credential collection patterns, detection logic, and response considerations that overlap with passwd and shadow theft.

Risk and Threat Considerations

Copying passwd or shadow files is risky because it can turn local account data into offline attack material. Even when the attacker cannot immediately log in, they may use the copied data to target weak passwords, validate account names, or support later privilege escalation and persistence.

Failure mechanism: An attacker gains local or elevated access, reads identity files, then stages or transfers them for offline analysis, often hiding the action inside routine command usage or administrative tooling.

Impact: The organisation can lose confidence in local account secrecy, expose weak or reused credentials, and face a wider compromise path if the same credentials work elsewhere.

Practitioner Guidance

What to verify: Confirm that alerts distinguish legitimate administration from suspicious collection by checking the active account, parent process, and whether the destination path or transfer tool is consistent with approved operations.

Decision rule: If file access follows privilege escalation and is paired with compression, staging, or outbound transfer, treat it as suspected credential exposure and move immediately to containment and credential review.

Practitioner takeaway: The key judgement is not whether passwd or shadow was merely read, but whether the access fits a normal identity-management task or the opening stage of credential theft and exfiltration.

Related resources from NHI Mgmt Group

• What steps should security teams take to prevent Shadow AI risks?
• Why is visibility important in managing Shadow AI?
• How can security teams detect /etc/passwd and /etc/shadow?
• How do you detect attackers searching for credentials in files and the registry on Windows?