~/tutorials/035-where-credentials-live.md

035: Where credentials live

An attacker with a foothold does not start by cracking anything. They read the places systems keep secrets, because those places are documented and mostly unwatched.

In your lab, after you land a shell, the first census is the same every time.

The Linux map

The accounts list is one file, one line per user, readable by everyone:

$ cat /etc/passwd
$ sudo cat /etc/shadow
$ ls -la /home
$ find / -name "*.pem" 2>/dev/null

The hashes used to live in the second column of that first file, until somebody decided world readable password hashes were a bad idea. Now the column holds an x and the hashes live in /etc/shadow, which needs root. The lesson inside that split: the location moved, the habit of reading it stayed.

Home directories are credential stores. The .ssh directory holds keys that often work on other machines. The shell history file holds commands people typed, sometimes with passwords as arguments. Service configs hold database strings in plain text. Cloud credentials hold the worst secret of the era: a file in a home directory that is administrator of a whole company's infrastructure.

What a hash looks like before you crack it

A shadow line does not hide its family. The hash field starts with a tag between dollar signs, and the tag names the scheme:

$6$    sha512crypt, the long standing Linux default
$y$    yescrypt, the new default on current Debian and Kali
$1$    md5crypt, old, and every wordlist beats it
$2b$   bcrypt, common in application databases

Reading the tag first is not trivia. It decides what you type next, because a cracking tool told the wrong format loads nothing and says so in a voice that sounds like failure. On a modern Kali the accounts you create will hash with yescrypt, and on an older box with sha512crypt, and nothing about that difference is your mistake. It is the machine telling you what it is.

The browser store

On a Windows target the pattern repeats with different paths. Browser profile directories hold saved passwords in a store that decrypts in the logged in user's context. Extract the store, run it through a tool, and every saved password is on the screen. This is why remember my password is a decision about the machine's whole security, not a convenience.

A password is not a permission

This site's flag discipline says the same thing: a password is not a permission. Finding a credential is not the same as being allowed to use it. In your lab you are allowed. On an engagement the scope letter decides, and credentials found outside scope are findings to report, not keys to turn.

Try it

1. In your lab, from a foothold, spend ten minutes enumerating credential locations before touching anything. A shell on the Linux target is on the apparatus page the known entry, and that page is where the foothold stops being circular.
2. Write the census down. Path, what lives there, who can read it. The three commands that open the census are in this lesson, and the census is honest only when the shadow line is read with its tag, not past it.
3. Take one hash you find and crack it with a wordlist. The exercise is the ratio: how long the crack took against how long finding the hash took. The crack command, the wordlist discipline, and the mode rule live on the apparatus page the words and the hashes.

$ sudo grep l1a_weak /etc/shadow
$ sudo unshadow /etc/passwd /etc/shadow > hashes.txt
$ sudo john --wordlist=words.txt hashes.txt
$ sudo john --show hashes.txt

Finding is cheap. That fact shapes both attack and defense.