CHFI OS and Network Forensics Practice Question

In Linux forensics, an investigator examines /var/log/auth.log and finds repeated entries of "Failed password for root from 10.0.0.5 port 22 ssh2". Which type of attack is most likely indicated?

⚠ Common exam trap

This exam often tests the distinction between network-layer attacks (ARP spoofing, DNS poisoning) and application-layer attacks (SSH brute force), and the trap here is confusing repeated failed login attempts with a network-level attack like ARP spoofing.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Brute force attack on SSH

Repeated 'Failed password for root' entries in /var/log/auth.log indicate multiple authentication attempts against the SSH service. This pattern is characteristic of a brute force attack, where an attacker systematically tries many passwords to gain unauthorized access to the root account via SSH.

Answer analysis

Option-by-option breakdown

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

✗
DNS cache poisoning attack
Why it's wrong here
DNS cache poisoning is a network-layer attack that corrupts the cached records of a DNS resolver, causing clients to resolve domains to malicious IPs. Its observable artifacts are anomalous DNS responses or cache entries, typically captured by packet analyzers or DNS server logs. The auth.log records authentication events such as SSH logins, PAM checks, and sudo usage, and therefore contains no traces of DNS cache manipulation. An investigator seeing unusual successful or failed SSH entries would not attribute them to DNS poisoning.
✗
SQL injection attack
Why it's wrong here
SQL injection attacks exploit insufficient input validation to execute arbitrary SQL queries against a backend database, affecting the web application's data layer. The attack's fingerprints appear in web server access logs (e.g., malicious parameters in GET requests) or in database transaction logs, not in auth.log. While auth.log might record a database authentication failure if the web app misbehaves, it does not log the injected SQL statements or their results. Therefore, suspecting SQLi from auth.log evidence is a misattribution of the attack vector.
✗
ARP spoofing attack
Why it's wrong here
ARP spoofing (ARP poisoning) operates at Layer 2 by forging ARP replies to associate the attacker's MAC address with a legitimate IP address, enabling man-in-the-middle interception. Evidence of ARP spoofing is obtained through ARP cache inspection, arpwatch alerts, switch port security, or packet capture showing duplicate ARP replies. This activity never reaches the authentication subsystem; auth.log records only login/logout, sudo, and PAM events for actual user authentication. Thus, it cannot explain anomalies in auth.log and is not a valid hypothesis.
✓
Brute force attack on SSH
Why this is correct
A brute-force attack against SSH is the classic finding in auth.log, where sshd writes every authentication attempt via messages like 'Failed password for <user> from <IP> port <port> ssh2'. A sustained pattern of many such failures in a short window—especially with changing usernames or source IPs—indicates automated password guessing. This aligns with the observed log entries, and PAM may also log 'authentication failure' before sshd closes the connection. Because auth.log directly records this sequence, the investigator can correlate failed attempts and possibly successful follow-up logins to assess compromise.

Go deeper

CHFI OS and Network Forensics Practice Question

Why each option matters

Option-by-option breakdown

Related to this question