CHFI Application, Email and Cloud 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.

• ✗

  Verifying SSL certificate validity

  Why it's wrong here

  Verifying SSL certificate validity confirms that the server's HTTPS encryption is properly configured and trusted, but it says nothing about the integrity of the files hosted on that server. A webshell is a server-side script that communicates over the existing web channel, so an attacker can easily compromise a site that otherwise presents a valid, current certificate. Thus, this check is a general security hygiene measure, not a webshell detection technique, and would fail to identify an active backdoor.

• ✓

  Searching for files with recent creation or modification timestamps in the web root

  Why this is correct

  Searching for files with recent creation or modification timestamps in the web root is a practical initial triage because webshells are usually uploaded shortly before they are used, and the upload leaves a fresh file on disk. In particular, script files such as .php, .jsp, or .aspx that appear in web-accessible directories with timestamps matching the time of a suspected breach are strong candidates for further manual review. While attackers can alter timestamps to hide their tracks, this technique is still appropriate and often the first step in a forensic hunt for malicious web content.

• ✗

  Running a full antivirus scan on the server

  Why it's wrong here

  Running a full antivirus scan on the server is unlikely to identify custom webshells because antivirus products depend on known malware signatures and generic heuristics, whereas webshells are often handcrafted, obfuscated, or encoded to avoid such detection. A bespoke webshell can be a simple one-liner that antivirus does not classify as malicious, producing a false-negative result. Therefore, relying solely on antivirus is inadequate; a forensic examiner must instead examine file contents, timestamps, and logs to detect an active backdoor.

• ✓

  Analyzing web server logs for anomalous POST requests to script files that return 200 OK with large response sizes

  Why this is correct

  Analyzing web server logs for anomalous POST requests to script files that return 200 OK with large response sizes is a powerful detection technique because webshells typically receive command input through POST parameters and then output the command results in the HTTP response. Normal web traffic may include POSTs, but a series of POSTs to a suspicious script like shell.php or a recently uploaded file returning large bodies is a hallmark of interactive command execution. This log-based pattern directly reflects the webshell's operation and is an appropriate, evidence-backed method for identifying compromised web components.

• ✗

  Checking for open ports on the server

  Why it's wrong here

  Checking for open ports on the server is not useful because webshells do not open new network ports; they reside in the web server's existing file system and communicate over the same HTTP/HTTPS ports (80/443) that legitimate web traffic uses. An open port scan would reveal only services listening on the network, not uploaded scripts executing within the web server process. Thus, port scanning is orthogonal to webshell detection and would miss the backdoor entirely.

Go deeper

Related to this question