CHFI OS and Network Forensics Practice Question
A security analyst is investigating a potential webshell on an IIS server. Which THREE artifacts are commonly associated with webshell presence?
⚠ Common exam trap
Candidates often mistake Event ID 4624 logon events for webshell activity, but these are routine authentication events. The correct artifacts are unusual HTTP POST requests, encoded scripts, and child processes of w3wp.exe.
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 encoded scripts in the web application directory
Option B is correct because webshells are typically dropped as script files (e.g., .asp, .aspx, .php) in web-accessible directories, and attackers frequently obfuscate or encode them (Base64, gzip, eval/execute blocks) to evade signature detection. Option D is correct because webshell interaction occurs over HTTP, so IIS logs commonly show anomalous POST requests to .asp/.aspx endpoints, often with unusual user agents, parameters, or response sizes indicating command execution. Option E is correct because IIS worker process w3wp.exe spawning cmd.exe or powershell.exe is a classic parent-child anomaly indicating remote command execution through a webshell. Option A is not specific to webshells, since NetFlow to a legitimate update server is normal patching traffic and lacks host-level context. Option C is not indicative either, as Event ID 4624 logons by a service account are routine and do not by themselves evidence webshell activity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase in NetFlow traffic to a known good update server
Why it's wrong here
An increase in NetFlow traffic to a known good update server is not an anomaly because that server is a trusted destination already associated with routine software updates. NetFlow records only IP conversations, not payload contents, so a webshell's command-and-control traffic would typically flow to an unfamiliar external host, not a legitimate update endpoint. While unusual volume to any destination deserves review, absent evidence that the server is compromised, this is a weak indicator and a false positive in webshell detection.
- ✓
Presence of encoded scripts in the web application directory
Why this is correct
Because webshells must be accessible by the web server, they are nearly always planted in a web-accessible directory, such as wwwroot or a subfolder. Attackers routinely hide the malicious intent by encoding the payload—for instance with base64, hex, or gzinflate—so the file appears as an opaque script without readable function names. Legitimate web application code is rarely obfuscated in this manner, so the combination of placement in a web directory and encoded content is a strong, direct indicator of a webshell.
- ✗
Event ID 4624 logon events from the service account
Why it's wrong here
Event ID 4624 records successful logon events; service accounts are expected to log on frequently to run the application pool, so these events alone are routine and not indicative of a webshell. A webshell executes code within the existing w3wp.exe process using the application pool's identity, and it does not trigger a new interactive or network logon for the attacker. To tie 4624 to malicious activity, one would want to see anomalous logon types, like type 10 (remote interactive) with unusual source IPs, but that is a separate behavior from a webshell.
- ✓
Unusual HTTP POST requests to .asp or .aspx files in IIS logs
Why this is correct
IIS processes .asp and .aspx files server-side, and webshells often accept commands via POST parameters to keep the command out of the URL and avoid detection in URI-based logging. An unusual pattern of POST requests to a specific .asp or .aspx file—especially one that is not part of the known application, is accessed by an unfamiliar IP, or carries large request bodies—is a classic indicator of interactive webshell traffic. These POSTs typically return large HTTP responses containing command output, which distinguishes them from benign form submissions.
- ✓
Process creation events for cmd.exe or powershell.exe spawned by w3wp.exe
Why this is correct
w3wp.exe is the IIS worker process and normally handles HTTP requests by executing application code, but it should never spawn cmd.exe or powershell.exe as child processes. When an attacker drives a webshell, the script invokes process creation APIs, resulting in a process tree where w3wp.exe is the parent and cmd.exe or powershell.exe is the child—a pattern that is almost always malicious. Monitoring these events with Sysmon Event ID 1 or Windows Event ID 4688 gives direct evidence of remote code execution via a web-based webshell.
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 →
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.