CHFI OS and Network Forensics Practice Question
Which THREE of the following are common indicators of a web shell presence on a compromised IIS web server? (Select THREE.)
⚠ Common exam trap
A common misconception is that HTTP error codes like 404 are direct signs of compromise, when in reality they are more indicative of reconnaissance or misconfiguration, not the active presence of a web shell.
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
✓
Process w3wp.exe making outbound connections to an unknown IP
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increased 404 errors in HTTP logs
Why it's wrong here
Increased 404 errors in HTTP logs are not a reliable web shell indicator because a web shell is typically accessed via an existing crafted URL that returns HTTP 200 (or another success-coded response) to execute commands. A 404 represents a request for a resource that was not found, so it more often reflects normal user typos, web crawlers, URL scanning, or reconnaissance rather than successful web shell interaction. Even a large spike in 404s is merely a noisy inbound-scan artifact and does not imply code execution, command-and-control traffic, or persistence inside IIS.
- ✓
Process w3wp.exe making outbound connections to an unknown IP
Why this is correct
Process w3wp.exe making outbound connections to an unknown IP is a strong indicator because w3wp.exe is the IIS worker process that normally only receives inbound HTTP requests and responds to them; it should not initiate outbound connections to arbitrary external addresses. When a web shell is uploaded and invoked, the attacker can use it to run commands, exfiltrate data, or create a reverse shell via the compromised worker process, causing the trusted w3wp.exe process to beacon to an external IP. Such unexpected outbound traffic from a known server-side process is frequently missed by simple HTTP log review, making it a high-value network-based IOC that pairs with file-based web shell detection.
- ✓
Scheduled tasks that execute cmd.exe or powershell.exe
Why this is correct
Scheduled tasks that execute cmd.exe or powershell.exe indicate a post-exploitation persistence mechanism commonly established after an attacker gains initial access via a web shell. An attacker might create a scheduled task to run a PowerShell encoded command or a CMD batch script at regular intervals, allowing continued remote access even if the web shell is removed from the webroot or the application pool is recycled. On an IIS server, legitimate administrative scheduled tasks are rare, so a new task invoking interactive shells, especially with SYSTEM privileges or obfuscated command lines, is a distinct and actionable persistence indicator.
- ✓
Anomalous files with .asp or .aspx extensions in the wwwroot directory
Why this is correct
Anomalous files with .asp or .aspx extensions in the wwwroot directory are classic web shell artifacts because web shells written in ASP or ASP.NET are typically dropped into a web-accessible folder so they can be reached via HTTP. The term 'anomalous' is key: such files may be newly created, have non-standard names, contain obfuscated code, or include functions like eval, Execute, or process invocation, which differentiate them from legitimate application pages. Because IIS maps these extensions to dynamic script handlers, the mere presence of an unusual ASP or ASPX file in a web root gives the attacker a command execution surface and is a strong file-system-based indicator of compromise.
- ✗
Normal GET requests to static .html pages
Why it's wrong here
Normal GET requests to static .html pages are benign and do not indicate web shell activity because static HTML content is served directly by IIS without server-side code execution. For a web shell to function, an attacker must send crafted parameters to a dynamic file such as .asp, .aspx, .php, or .jsp, which is then executed on the server. A continuous stream of ordinary GETs for .html assets merely represents typical user traffic and belongs in a baseline of normal behavior, not in a list of compromise indicators.
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.