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.

• ✗

  Multiple GET requests to /index.html

  Why it's wrong here

  Multiple GET requests to /index.html are not a webshell indicator because index.html is a static file that cannot process or execute commands. Webshells require a server-side script (e.g., .aspx, .php, .jsp) to interpret input and produce dynamic output, whereas repeated GETs to a static homepage generally represent normal browsing, search-engine crawling, or load testing. Even if the request volume is high, the absence of an executable endpoint and command-carrying parameters means the traffic lacks the defining characteristics of webshell use.

• ✓

  POST requests to a script file with large payloads

  Why this is correct

  POST requests to a script file with large payloads strongly suggest webshell activity because attackers use the HTTP body to hide command strings, encoded scripts, or file-upload content from URL-based logging and detection. A legitimate script receiving a large POST body is uncommon, and when combined with an executable extension (.php, .aspx, .jsp), it indicates the attacker is sending instructions or data to be processed by the shell. The large payload size also corresponds to obfuscated command blocks or base64-encoded data, making it a crucial behavioral indicator.

• ✗

  Consistent 304 Not Modified responses

  Why it's wrong here

  Consistent 304 Not Modified responses are a normal part of HTTP caching and indicate that a client used conditional headers such as If-Modified-Since or If-None-Match and the server determined the cached copy was still fresh. These responses contain no response body, so they cannot return webshell output or command results, making them irrelevant as a webshell indicator. An attacker using a webshell needs 200 OK responses with dynamic content, not cache-revalidation traffic, so pervasive 304s are more likely browser behavior or static asset requests.

• ✓

  Requests to unusual script files like cmd.aspx or shell.php

  Why this is correct

  Requests to unusual script files like cmd.aspx or shell.php are a direct indicator of a webshell because such names are not part of a typical application's legitimate URL space and often match publicly known web shells (e.g., c99shell, r57shell). Attackers frequently name backdoors after system binaries (cmd, shell, upload) to evade casual inspection, and the extension (.aspx, .php) reveals the execution context the web server will use. Security monitoring should flag these filenames, especially when they appear in directories where no such script is expected.

• ✓

  A high number of requests from a single IP to a single script

  Why this is correct

  A high number of requests from a single IP to a single script indicates automated interaction with a specific executable file, which is exactly how webshells are used for repeated command execution, file browsing, or privilege-escalation attempts. Normal users distribute their requests across many pages and assets, so the concentrated one-to-one IP-to-script pattern is a behavioral outlier. This pattern, especially when combined with varying parameters or POST bodies, suggests a tool like curl, China Chopper, or a custom script hammering the backdoor.

Go deeper

Related to this question