CHFI OS and Network Forensics Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  bash_history for suspicious commands

  Why it's wrong here

  The per-user ~/.bash_history can be missing, truncated, or pointed to /dev/null by hardening or attacker cleanup, and it only records interactive command lines, not every file change. A malicious user can also edit or delete the history file to hide the exact command that added an SSH key, so relying on it undermines forensic integrity. While useful for leads, emptiness or gaps cannot rule out an unauthorized key already present in authorized_keys.

• ✗

  /etc/shadow for recent modifications

  Why it's wrong here

  /etc/shadow is the system account database holding password hashes and aging metadata, and it is updated only when a password is set or changed with passwd/chage. Because SSH public-key authentication bypasses password authentication entirely, adding an unknown key to ~/.ssh/authorized_keys does not touch shadow or produce any timestamp there. Inspecting shadow for recent modifications would therefore reveal nothing about an unauthorized key, and a recent mtime in shadow would reflect account/password administration, not SSH key persistence.

• ✓

  ~/.ssh/authorized_keys for unauthorized keys

  Why this is correct

  The ~/.ssh/authorized_keys file for each user is the authoritative list of public keys allowed to log in as that account via SSH. Attackers commonly append a single base64-encoded line containing their public key, often with command= or from= restrictions to evade detection, enabling silent passwordless access independent of any password change. Comparing every entry against known administrative keys—while verifying file ownership, permissions, and the account's shell—is the direct method to locate such an implanted credential.

• ✗

  /var/log/syslog for cron job entries

  Why it's wrong here

  /var/log/syslog aggregates kernel, daemon, and cron messages, including sshd authentication events and cron execution lines, but it does not log the contents or modification of an authorized_keys file. A cron-based persistence mechanism might eventually appear as a job run, yet it is a different persistence method and would not explain the generated key-based access already discovered. Journald rotation and log tampering can also create gaps, making syslog less definitive than inspecting the SSH key file itself.

Go deeper

Related to this question