Where are user password hashes stored on Windows and on Linux, and why do attackers target those files?

This is a fundamentals question with real operational weight: knowing where the secrets live tells you what attackers will grab after gaining a foothold and what you must protect and monitor. Interviewers use it to confirm you understand credential theft, not just memorize file paths.

Windows

Local account password hashes (stored as NTLM) live in the SAM registry hive at C:\Windows\System32\config\SAM. The file is locked and obfuscated while Windows is running, but it can be extracted offline (e.g., booting another OS) or dumped with tooling. Live credentials — plaintext, tickets, and hashes for logged-on users — sit in the LSASS process memory, which is why tools like Mimikatz target LSASS. In Active Directory, all domain account hashes are stored in NTDS.dit on domain controllers — the crown jewels.

Linux

Linux historically kept hashes in world-readable /etc/passwd, which let anyone run offline cracking. Modern systems moved the hashes into /etc/shadow, readable only by root, while /etc/passwd retains non-secret metadata (UID, home dir, shell). Each shadow entry encodes the hashing scheme (e.g., $6$ = SHA-512), a salt, and the hash, plus password-aging fields.

Why attackers want them

With the hashes, an attacker can crack weak passwords offline with Hashcat/John, or skip cracking entirely and pass-the-hash against NTLM-authenticating services. That is why dumping SAM/LSASS/NTDS.dit or reading /etc/shadow is a top post-exploitation goal.

Why this matters

A strong answer names SAM, LSASS, and NTDS.dit on Windows and /etc/shadow (vs /etc/passwd) on Linux, and connects them to offline cracking and pass-the-hash. Bonus points for defenses: Credential Guard, LSASS protection, strong/long passwords, and least privilege so these files are never reachable.