/etc/passwd and /etc/shadow (T1003.008) is a credential access sub-technique for Linux. Adversaries try to dump both files so they can crack password hashes offline.
How attackers use it
MITRE explains the layout. Modern Linux systems store account information across two files. The passwd file holds user ID, group ID, home directory and login shell. The shadow file holds all password hashes, including entries for users with no password and for locked or disabled accounts. By default, shadow is readable only by root.
An adversary may read both with simple command line utilities, or use the unshadow utility to combine them into a format that cracking tools accept. MITRE notes the adversary needs both files, since the user information is linked to the hashes.
How to detect it
MITRE's analytic correlates several events: an elevated process, reads of the sensitive paths, and anomalous reads tied to non-root or unusual users. It also flags creation of backup copies of the files and use of post-exploitation frameworks.
With auditd, you can set a watch on the shadow file and review the results. This command lists current audit rules (read-only, needs root):
auditctl -l
If no rule mentions the shadow file, add a watch through your normal change process and send the events to your log platform. Then alert on reads by anything other than the login and account management tools you expect.
Also look at process creation events for unshadow, and for copies of either file written to temp directories.
How to reduce the risk
MITRE lists:
- Privileged Account Management: restrict access to privileged accounts so hostile programs cannot reach this data.
- Password Policies: complex, unique root passwords across all systems.
Hashes are only dangerous if they can be cracked. Long, unique passwords for local accounts, or key-only access with local passwords locked, make a stolen file much less useful.
What the hashes are worth
The shadow file holds hashes for every account, including locked and disabled ones. A locked account may look harmless, but its hash is still in the file, and the password behind it may be reused elsewhere. That is the reason MITRE stresses unique passwords for root and for accounts on all systems.
For service accounts on Linux, the best fix is to avoid passwords at all. Use key-based access, lock the password field and keep the keys protected. A hash of a locked field offers nothing to crack.
Tuning the detection
The shadow file is read by a short list of tools: login, account management utilities, and some security agents. Build that list from your auditd data over a week. Then alert on any other reader. Add a second rule for copies of either file written to temp directories or home folders, since the combination step MITRE describes tends to leave output behind.
Remember that root can read everything. An alert here usually means the attacker is already root, so the right response is host-level, not just account-level. Isolate, collect evidence and plan to rebuild.
Beyond system files
Passwords also hide in application configs, deployment scripts and repository history. The shadow file is protected by default, but these places often are not, and an adversary reads them just as easily.
Check your own environment
Check the file permissions on the shadow file (read-only):
ls -l /etc/shadow
Expect read access for root, and at most the shadow group on some distributions, and nothing for everyone else.
List accounts with an empty password field. This reads the shadow file, so run it as root on a host you administer:
awk -F: '($2 == "") {print $1}' /etc/shadow
The output should be empty.
Try it yourself
Credentials do not only hide in system files. Application configs, scripts and repositories often hold secrets too. The demo below shows how secrets scanning finds them.
Click through it at your own pace, or open it full screen.
Quick check
Why does an adversary need both files?
The passwd file links user information to the hashes stored in the shadow file. Combined, they give cracking tools a usable input.
