Lion Cipher Lab
Recover where an attacker SSHed to from a hashed known_hosts file
- Digital Forensics & IR (DFIR)
- Intermediate
- ~60 min
- Free · no account required
Why it matters
When an attacker takes over a Linux account, one of the first questions in the incident is: where did they go next? The account's ~/.ssh/known_hosts file quietly answers it, because the SSH client writes a line there the first time it connects to any new server. Attackers know this too: MITRE ATT&CK records malware such as Kinsing and Rocke reading known_hosts to find more machines to attack. That is why many Linux systems store the names in a hashed form, which hides them from a casual reader. Hashing is one-way, so you cannot decode the names, but you can test guesses. Each guess either…
What you'll learn
- Reading every field of an OpenSSH known_hosts line: marker, host pattern, [host]:port, key type and key
- Explaining the hashed form |1|salt|hash and why it is HMAC-SHA1 keyed with a per-line salt
- Testing candidate host names and addresses against hashed lines with Python's hmac module
- Building candidate lists in stages (inventory, subnet sweep, non-standard ports, shell history and ssh_config) and measuring what each stage adds
- Cross-checking results with ssh-keygen -F and recognising its wildcard-line false hits
- Resolving a line whose name cannot be guessed by matching the recorded host key against ssh-keyscan results
Steps in this lab
- Why known_hosts is a record of lateral movement
- Read a known_hosts line field by field
- When names are hashed, and when they are not
- Build the evidence folder
- Test candidate names in stages and measure each stage
- Read what each stage bought you
- Cross-check with ssh-keygen -F, and its wildcard trap
- When no name works, match the host key instead
- What known_hosts cannot tell you
- Turn the result into the next moves