Artifact Analysis: Linux SSH Artifacts

Note

Executive Summary: Secure Shell (SSH) is the ubiquitous standard for remote administration on Unix-like systems. Consequently, the hidden .ssh directory residing within a user’s home folder is a primary target for threat actors. For DFIR analysts performing post-mortem analysis, this directory serves as a critical forensic repository: it contains the keys that open doors (private keys), the locks installed for persistent access (authorized_keys), and the historical log of lateral movement destinations (known_hosts).

1. Persistence via authorized_keys (Inbound Access)

The authorized_keys file contains the public keys that are permitted to authenticate to a specific user account without requiring a password.

• Artifact Location: /home/<user>/.ssh/authorized_keys and /root/.ssh/authorized_keys

Threat actors frequently append their own public keys to this file. It is the most common, robust, and native persistence mechanism on Linux systems. Even if administrators rotate the user’s password, the attacker retains seamless access.

DFIR Hunting Focus

Analysts must parse these files across all user profiles, looking for specific anomalies:

1. Unknown or Suspicious Keys: Keys that do not align with corporate IT management infrastructure.
2. Comment Fields: SSH keys often terminate with a user-generated or auto-generated comment (e.g., user@hostname). Finding comments like root@kali, kali@kali, or unrecognizable external hostnames is a high-fidelity indicator of compromise. Attackers may attempt to blend in by using deceptive comments like backup-admin.
3. Forced Commands (Stealth Backdoor): Attackers can prepend execution options to a key. If a key starts with command="/usr/bin/perl /tmp/backdoor.pl", the specified command executes automatically as soon as the attacker authenticates with that key, providing a highly stealthy, interactive shell without spawning a standard TTY.
4. Timestamp Anomalies: Compare the modification time (mtime) of the authorized_keys file with the suspected intrusion window.

2. Lateral Movement Tracking via known_hosts (Outbound)

The known_hosts file acts as an automated address book. It stores the cryptographic fingerprints of remote servers that the user has connected to from the current machine.

• Artifact Location: /home/<user>/.ssh/known_hosts

DFIR Hunting Focus

This artifact is vital for mapping the attacker’s lateral movement. If an analyst is triaging “Patient Zero” and discovers the IP addresses of internal database servers or domain controllers within the root user’s known_hosts file, it confirms the attacker successfully pivoted to those critical assets.

Tip

The Hashed Known Hosts Problem: On modern Linux distributions, known_hosts entries are hashed for privacy (HashKnownHosts yes in the SSH config), rendering the IP addresses unreadable (e.g., |1|F1E4...). Forensic Trick: Analysts cannot reverse the hash, but they can brute-force it against a known list of internal subnets. Use the ssh-keygen utility to verify if a suspected IP exists in the file: ssh-keygen -F <SUSPECT_IP> -f /mnt/analysis/root/.ssh/known_hosts

3. Credential Theft: Private Keys (id_rsa / id_ed25519)

These files represent the digital identity of the compromised user.

• Artifact Location: /home/<user>/.ssh/id_rsa, id_ed25519, id_ecdsa

If an attacker gains read access to this directory, they will invariably exfiltrate these private keys. Consequently, the attacker inherits the user’s digital identity and can seamlessly authenticate to any internal server that trusts these keys (often the exact servers listed in the known_hosts file). If evidence suggests the .ssh directory was accessed (correlate with Linux Shell History), all associated keys must be revoked immediately across the entire infrastructure.

4. Server Configuration Tampering (sshd_config)

Adversaries occasionally modify the SSH daemon configuration to lower security postures or establish hidden backdoors.

• Artifact Location: /etc/ssh/sshd_config

Analysts must verify the integrity of this file against a known-good baseline, looking for:

• PermitRootLogin yes: Enabling direct root logins, which are typically disabled by default.
• PasswordAuthentication yes: Re-enabled to facilitate brute-force or lateral movement using dumped clear-text credentials.
• AuthorizedKeysFile: Attackers may change this directive to point to a hidden file (e.g., /tmp/.hidden_keys), bypassing standard audits of the ~/.ssh/ directory.

5. DFIR Triage & Automated Auditing

To accelerate the investigation of a mounted forensic image, DFIR teams should utilize automated scripts to audit all SSH artifacts concurrently.

Bash (SSH Audit Script)

audit_linux_ssh.sh

#!/bin/bash
TARGET_DIR="/mnt/analysis"

echo "[+] Extracting all authorized_keys..."
find $TARGET_DIR/home $TARGET_DIR/root -type f -name "authorized_keys" -exec echo -e "\n=== {} ===" \; -exec cat {} \;

echo "[+] Checking for forced commands in authorized_keys..."
find $TARGET_DIR/home $TARGET_DIR/root -type f -name "authorized_keys" -exec grep "command=" {} +

echo "[+] Auditing sshd_config anomalies..."
grep -E "^PermitRootLogin|^PasswordAuthentication|^AuthorizedKeysFile" $TARGET_DIR/etc/ssh/sshd_config

---

References & Further Reading

• SANS Institute: Advanced Incident Response and Threat Hunting
• MITRE ATT&CK: Account Manipulation: SSH Authorized Keys (T1098.004)
• Related Artifact: Linux Authentication Logs (auth.log)
• Related Artifact: Linux Account & Privilege Analysis