During a forensic analysis of a compromised web server, an investigator identifies the following log entries. Which THREE entries are the strongest indicators of a successful web shell upload? (Choose three.)

GET /../../windows/system32/cmd.exe HTTP/1.1 404 - -

GET /images/logo.png HTTP/1.1 304 - -

CHFI Application, Email and Cloud Forensics Practice Question

Correct answer & explanation

✓

POST /upload.php HTTP/1.1 200 0

Successful uploads of aspx or php files that contain web shell code (e.g., with cmd parameter) and subsequent access to those files are strong indicators. The 404 for cmd.exe indicates a path traversal attempt, not a web shell.

Answer analysis

Option-by-option breakdown

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

✓
POST /upload.php HTTP/1.1 200 0
Why this is correct
A POST request to /upload.php that returns HTTP 200 with a zero-byte response body indicates the server accepted a client upload even though the reply was empty. In Apache access logs, the trailing '0' is the response size in bytes, so this record is consistent with a PHP upload handler completing successfully and not returning content. Combined with the known purpose of upload.php, this is a strong forensic foothold for a web shell planted through the application's file-upload feature.
✓
POST /uploads/shell.aspx HTTP/1.1 200 - -
Why this is correct
A successful POST to /uploads/shell.aspx is unusual because an attacker is writing directly into a URL-accessible directory rather than going through a typical upload handler; this can happen when a vulnerable script writes attacker-controlled files or WebDAV is enabled. HTTP 200 means the server returned a success status for that write, and the .aspx extension is critical because ASP.NET will execute the code when the file is later requested. Therefore this log line marks the moment the malicious server-side payload became resident in the web root.
✓
GET /uploads/shell.aspx?cmd=dir HTTP/1.1 200 - -
Why this is correct
This GET request targets the previously uploaded /uploads/shell.aspx and passes a command through the cmd parameter, which is the classic invocation pattern for ASP.NET command-execution web shells such as cmdasp.aspx. The 200 response confirms that the file was retrieved and interpreted by the server; had the file been missing or blocked, the status would be 404 or 403. Because a normal ASPX application would not use a cmd parameter for directory listing, this record demonstrates post-upload remote code execution.
✗
GET /../../windows/system32/cmd.exe HTTP/1.1 404 - -
Why it's wrong here
The 404 status is itself the reason this option is not evidence of compromise: the server could not find the requested cmd.exe path, so no file was disclosed and no command executed. Although the URI shows a path traversal technique that could be part of an attacker's earlier reconnaissance, the attempt failed at this logging stage. Failed traversal probes are frequently found in server logs, but without a successful 200 response they do not prove the upload or execution of a web shell.
✗
GET /images/logo.png HTTP/1.1 304 - -
Why it's wrong here
A 304 Not Modified response for /images/logo.png is a routine conditional-GET result: the browser already has a cached copy and the server confirms it is still valid, so no content is transferred. This request does not involve a writable endpoint, an executable file, or a parameter that could trigger server-side code, making it unrelated to the signs of a web shell upload. In log analysis, 304 responses should be filtered or noted as background noise rather than treated as suspicious events.

CHFI Application, Email and Cloud Forensics Practice Question

Why each option matters

Option-by-option breakdown

Related to this question