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.

• ✓

  Unexpected file modifications in web directories, especially .php, .asp, or .jsp files

  Why this is correct

  Web shells are typically script files placed in web-accessible directories, and their presence is often revealed by changes to file integrity—new files appearing or existing files altered with PHP/ASP/JSP content. A file integrity monitoring system would flag these modifications, and during forensic analysis, file hashes and timestamps can correlate with the attack timeline. This is a strong indicator because legitimate content management processes rarely modify executable scripts in web root directories without corresponding change-control records.

• ✓

  Presence of processes like cmd.exe or /bin/bash running under the web server user

  Why this is correct

  When an attacker exploits a web shell, it typically executes OS commands by spawning a child process such as cmd.exe on Windows or /bin/bash on Linux, and this child process inherits the web server's user account. This is observable via process monitoring or audit logs, and it is anomalous because normal web server operations do not produce interactive command shells. The process tree would show the web server process (like apache or w3wp.exe) as a parent, which is a strong sign of command execution.

• ✗

  An increase in 404 errors due to directory traversal attempts

  Why it's wrong here

  A spike in 404 responses typically results from automated vulnerability scanners, directory brute-forcing, or attackers probing for non-existent paths, but it does not indicate that a web shell has been uploaded or executed. Directory traversal attempts can be detected in access logs via patterns with ../ sequences, but successful exploitation would lead to file inclusion or command execution, not simply 404 errors. Therefore, these errors are a generic artifact of web reconnaissance and are insufficient as a definitive indicator for web shells.

• ✗

  Regular successful logins from multiple IP addresses

  Why it's wrong here

  Successful authentication from many IP addresses is more closely associated with credential stuffing, brute-force attacks, or account sharing, and it does not directly correspond to web shell installation or activity. This pattern concerns the application's authentication mechanism rather than the web server's file system or process execution, which are the primary loci of web shell artifacts. It might be a precursor if attackers gain access through legitimate accounts, but it is not a reliable standalone indicator because web shells can be deployed without any login activity via existing vulnerabilities.

• ✓

  Atypical HTTP requests containing system commands (e.g., ?cmd=whoami)

  Why this is correct

  Web shells commonly take user-supplied parameters like 'cmd' or 'exec' as arguments to system functions, so requests containing recognizable command-line syntax (whoami, id, cat /etc/passwd) in query strings or POST bodies are a direct indicator. The behavior is atypical because normal web application requests are structured around application-specific parameters, not arbitrary shell commands. These requests are often identifiable in web server logs and network traffic, especially when they are combined with encoded payloads or unusual parameter names.

Go deeper

Related to this question