CHFI OS and Network Forensics Practice Question
Which THREE of the following are indicators of a webshell on a compromised web server? (Select THREE.)
⚠ Common exam trap
EC-Council often tests the distinction between generic performance anomalies (like high CPU) and specific forensic artifacts (like command strings in logs), leading candidates to over-select Option E as a webshell indicator when it is actually a non-specific symptom.
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
✓
Presence of system commands in web server error logs
Option B is correct because webshells typically execute operating-system commands (e.g., cmd.exe, /bin/sh, whoami, net user) that get recorded in web server error logs when the shell's input or output triggers errors, making such command strings a strong indicator of compromise. Option C is correct because attackers drop webshell files with executable web extensions such as .asp, .php, or .jsp into web-accessible directories (often with obfuscated or unusual names) so they can be invoked remotely over HTTP. Option D is correct because a webshell commonly initiates outbound connections from the web server to attacker-controlled command-and-control or exfiltration IP addresses, which is anomalous for a server that should mainly receive inbound HTTP requests. Option A is not specific to webshells, since multiple failed logins in auth.log indicate brute-force or credential attacks against SSH or other services rather than a web-based backdoor. Option E is also not specific, because high CPU usage from the web server process can result from legitimate traffic spikes, misconfiguration, or other malware, and is not a distinctive webshell indicator.
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 failed login attempts in auth.log
Why it's wrong here
auth.log records authentication events for SSH, console, or PAM-based services, not HTTP requests. A webshell is executed by the web server when a URL is requested, so its activity appears in web server access/error logs (access.log, error.log), not in auth.log. While a prior brute-force login could be the initial foothold, multiple failed authentication attempts are a generic precursor and do not specifically indicate that a webshell is present or active.
- ✓
Presence of system commands in web server error logs
Why this is correct
Webshells often invoke server-side commands through PHP functions like system(), exec(), or shell_exec() with attacker-supplied input. When these commands produce errors or partial output that is not sanitized, the web server's error log may capture snippets of OS commands such as id, whoami, ls -la, or cat /etc/passwd. A properly functioning application should never intentionally write raw system command output to error logs, so their presence is a strong sign of webshell activity.
- ✓
Unusual files with .asp, .php, or .jsp extensions in web directories
Why this is correct
A web shell is typically a script saved with an executable extension such as .asp, .php, or .jsp, placed in a directory accessible to the HTTP server, like /var/www/html/ or C:\inetpub\wwwroot. These files are distinctive when they have non-standard names, have been recently created or modified outside of a deployment cycle, and contain code like eval(), base64_decode(), or backticks for command execution. Legitimate application code usually follows a naming structure and change-management process, so an unrecognized executable script in a web directory is a red flag.
- ✓
Outbound connections from the web server to suspicious IP addresses
Why this is correct
A normal web server initiates few outbound connections; it primarily responds to inbound requests on ports 80/443. A webshell frequently establishes outbound TCP connections to an attacker-controlled host for command-and-control sessions, reverse shells, or data exfiltration, often using non-standard ports or protocols that break from the server's baseline network behavior. Monitoring NetFlow or firewall logs for connections to known-malicious IPs, or to unusual geographic regions, can reveal such callbacks.
- ✗
High CPU usage from the web server process
Why it's wrong here
High CPU consumption by a web server process can stem from many benign causes, including a traffic spike, an indexing job, a poorly optimized script, or even a denial-of-service attack. A webshell may cause elevated CPU only when it is actively executing commands or encrypting stolen data, but many webshells remain idle between requests and are therefore nearly invisible to CPU-based anomaly detection. CPU usage alone is too non-specific to be a reliable forensic indicator and must be paired with file or network evidence.
Go deeper
Related to this question
About these practice questions
This CHFI question is part of Courseiva's 745-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CHFI practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CHFI exam.