Webshell Indicators: Key Signs of a Compromised Web Server
Which THREE of the following are indicators of a webshell compromise on a web server?
Quick Answer
The answer is unexpected outbound connections from the web server to unknown IP addresses, along with unusual files in web directories and high CPU usage due to command execution. These three indicators are classic signs of a webshell compromise because a webshell is essentially a malicious script uploaded to a web server that allows an attacker to execute system commands remotely. When the attacker runs commands like whoami or netstat, the server’s CPU spikes, and the script often spawns outbound connections to exfiltrate data or receive further instructions. On the Computer Hacking Forensic Investigator CHFI exam, this question tests your ability to correlate forensic artifacts with active compromise, often appearing in the web server forensics domain. A common trap is focusing only on file anomalies while ignoring behavioral indicators like traffic patterns. Memory tip: think “Files, CPU, Outbound” as the three pillars of webshell detection.
⚠ Common exam trap
Candidates often mistake normal administrative behavior (Option B) for suspicious activity, but webshells bypass authentication entirely, making regular successful logins irrelevant as indicators.
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
✓
High CPU usage from web server processes
Option A is correct because webshells often execute resource-intensive commands (cryptomining, brute-forcing, scanning, or reverse shells) through the web server's worker processes, so sustained high CPU usage by httpd/nginx/w3wp or their child processes is a common indicator. Option C is correct because attackers typically drop or upload webshell files into web-accessible directories, so unexpected .php, .asp, .aspx, or .jsp files that are not part of the original application are a strong sign of compromise. Option D is correct because a webshell commonly establishes command-and-control or exfiltration channels, producing unexpected outbound connections from the web server to unknown external IP addresses on unusual ports. Option B does not belong because legitimate successful logins with valid credentials are normal activity and are not, by themselves, an indicator of a webshell. Option E does not belong because a decrease in network traffic is not characteristic of webshell activity, which typically generates additional traffic rather than reducing it.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
High CPU usage from web server processes
Why this is correct
Webshell activity spawns unexpected processes under the web server's user context, driving sustained CPU consumption from httpd, w3wp, or similar. This resource anomaly reflects attacker commands executing through the shell, distinguishing it from normal request-driven load spikes.
- ✗
Regular successful logins to the server with correct credentials
Why it's wrong here
Legitimate authenticated logins with valid credentials match normal administrative activity, not webshell behaviour, which typically appears as anomalous POST requests to unusual files or unexpected outbound connections. It is tempting because failed or brute-force logins are a genuine compromise indicator, so successful logins would be relevant when auditing credential-stuffing attempts.
- ✓
Presence of files with extensions like .php, .asp, or .jsp in web directories that are not part of the original application
Why this is correct
Webshells are typically uploaded as executable web scripts, so unfamiliar .php, .asp, or .jsp files appearing in web-accessible directories signal unauthorised code placement. Legitimate applications have known file inventories, making such additions a direct compromise artefact.
- ✓
Unexpected outbound connections from the web server to unknown IP addresses
Why this is correct
Webshells commonly establish command-and-control or exfiltration channels, so outbound connections from the web server to unfamiliar external IPs indicate attacker interaction. Servers that should only respond inbound make such egress traffic a strong compromise indicator.
- ✗
Decrease in network traffic
Why it's wrong here
Webshells generate command-and-control beaconing and data exfiltration, so traffic typically increases rather than decreases. It is tempting because reduced traffic can accompany a server taken offline or a denial-of-service condition, making it a plausible symptom in availability-focused investigations rather than webshell detection.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CHFI question from scratch — 745 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on CHFI
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which THREE of the following are common indicators of a web shell presence on a compromised IIS web server? (Select THREE.)
hard- A.Increased 404 errors in HTTP logs
- ✓ B.Process w3wp.exe making outbound connections to an unknown IP
- ✓ C.Scheduled tasks that execute cmd.exe or powershell.exe
- ✓ D.Anomalous files with .asp or .aspx extensions in the wwwroot directory
- E.Normal GET requests to static .html pages
Why B: Option B is correct because w3wp.exe is the IIS worker process that normally serves web content and should not initiate outbound network connections; seeing it connect to an unknown external IP is a strong indicator that a web shell is being used for command-and-control or data exfiltration. Option C is correct because attackers commonly establish persistence alongside a web shell by creating scheduled tasks that invoke cmd.exe or powershell.exe, which is abnormal for a standard IIS server. Option D is correct because web shells are typically dropped as .asp or .aspx files in the wwwroot directory so they can be executed by IIS, and unexpected files with those extensions in that location are a classic compromise artifact. Option A is not a reliable indicator because increased 404 errors simply reflect missing resources or scanning noise and do not by themselves indicate a web shell. Option E is not an indicator because normal GET requests for static .html pages are ordinary benign web traffic.
Variation 2. Which THREE of the following are common indicators of a web shell on a compromised web server? (Select THREE.)
hard- A.Presence of .htaccess files with rewrite rules
- ✓ B.Files with obfuscated code (e.g., base64 encoded strings)
- ✓ C.Files located in web-accessible directories (e.g., /uploads) with execute permissions
- D.High number of 404 errors in access logs
- ✓ E.Unusual HTTP POST requests with large payloads to a single script
Why B: Option B is correct because web shells are frequently hidden by obfuscating their PHP/JSP/ASP code with base64-encoded strings, gzinflate, eval, or similar encoding tricks to evade signature-based detection. Option C is correct because attackers commonly drop web shell files into writable, web-accessible directories such as /uploads or /images and set execute permissions so the web server can run them via HTTP. Option E is correct because a web shell typically receives commands through HTTP POST requests carrying unusually large or repeated payloads to a single script, which is a strong behavioral indicator in access logs. Option A is not a reliable indicator, since .htaccess files with rewrite rules are a normal, legitimate part of Apache configuration and are used for many benign purposes. Option D is not a reliable indicator either, because a high number of 404 errors usually reflects broken links, scanning noise, or misconfiguration rather than a web shell specifically.
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.