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.

• ✗

  /var/log/syslog

  Why it's wrong here

  /var/log/syslog is a general-purpose logging facility that aggregates kernel, daemon, and application messages; on most distributions SSH authentication activity is typically logged to /var/log/auth.log or /var/log/secure, not the default syslog file. Even if authentication messages appear in syslog, it records events such as successful or failed login attempts with timestamps and client IPs, not the static contents of user configuration files. Thus, unauthorized keys would never be listed in syslog; at most, it might show a connection that used a newly added key, but not the key itself.

• ✗

  /etc/ssh/sshd_config

  Why it's wrong here

  /etc/ssh/sshd_config is the SSH daemon's configuration file, not a credential store. It controls directives such as PermitRootLogin, PubkeyAuthentication, and AuthorizedKeysFile, which defines the default path to the authorized_keys file (normally ~/.ssh/authorized_keys). While an investigator should inspect it to detect changes like enabling root login or redirecting AuthorizedKeysFile to an alternate location, the file does not contain the actual public key material that would appear after an attacker appends a key.

• ✓

  ~/.ssh/authorized_keys

  Why this is correct

  ~/.ssh/authorized_keys is a per-user file that stores the public keys (one key per line) that are permitted to log in as that user via SSH. When an attacker compromises a Linux server, a common persistence technique is to append their own public key to /root/.ssh/authorized_keys or another user's authorized_keys file, enabling silent passwordless access at any time. Checking this file for unrecognized keys — and correlating key hashes or comments with known legitimate admins — is direct evidence of key-based backdoor access, making it the correct file to examine in this scenario.

• ✗

  /etc/passwd

  Why it's wrong here

  /etc/passwd is a structured database of local user accounts containing fields for username, UID, GID, home directory, and login shell, but it does not hold SSH keys; password hashes are kept in /etc/shadow for security. If an attacker created a new user for backdoor access, that user would appear in /etc/passwd, but the authorized_keys for that new user would reside in their home directory (e.g., /home/username/.ssh/authorized_keys). Therefore, /etc/passwd alone would not reveal key-based persistence, only the existence of potentially suspicious accounts that might warrant further examination.

Go deeper

Related to this question