CHFI OS and Network Forensics Practice Question
Which THREE of the following are common indicators of a web shell on a compromised web server? (Select THREE.)
⚠ Common exam trap
A common trap is to view .htaccess rewrite rules as inherently malicious, but they are a standard Apache feature; the trap is confusing legitimate configuration with attack indicators, leading candidates to select Option A incorrectly.
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
✓
Files with obfuscated code (e.g., base64 encoded strings)
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Presence of .htaccess files with rewrite rules
Why it's wrong here
The presence of .htaccess files with rewrite rules is not a reliable web shell indicator because .htaccess is a standard Apache configuration file used for legitimate URL rewriting, redirects, and access control. While attackers can abuse .htaccess to hide malicious files, such rules are also ubiquitous in benign sites with clean URLs (e.g., WordPress pretty permalinks). Consequently, observing rewrite rules alone has high false-positive potential, and many web shells don't require .htaccess at all—they are directly accessed via their file path.
- ✓
Files with obfuscated code (e.g., base64 encoded strings)
Why this is correct
Files containing obfuscated code, such as base64-encoded strings wrapped in eval(), gzinflate(), or str_rot13(), are a strong indicator of a web shell because legitimate web applications rarely need to obscure their logic. Obfuscation is deliberately used to hide malicious payloads from static signature-based scanners and to complicate manual inspection. The presence of such encoding in an unexpected file under a web-accessible directory—especially in upload folders—strongly suggests an attacker is trying to evade detection and maintain remote access.
- ✓
Files located in web-accessible directories (e.g., /uploads) with execute permissions
Why this is correct
Files located in web-accessible directories (e.g., /uploads) with execute permissions are a classic web shell indicator because a shell must be reachable via HTTP to accept commands from the attacker. Attackers deliberately place these scripts in directories that the web server serves directly, bypassing application-layer restrictions. While execute permissions are not strictly required for interpreted languages like PHP, the combination of a web-accessible path and permission to run (e.g., via .htaccess or CGI) is what enables the shell to function, making this a highly relevant artifact to investigate.
- ✗
High number of 404 errors in access logs
Why it's wrong here
A high number of 404 errors in access logs is not a specific web shell indicator because 404 responses are generated by any request for a nonexistent resource—common causes include broken links, automated scanners, brute-force directory guessing, or misconfigured bots. Web shell usage, by contrast, usually produces successful 200 responses as the shell executes and returns command output. Therefore, 404s may indicate reconnaissance or background noise, but they do not directly reveal an active web shell, and focusing on them can distract from more telling access patterns.
- ✓
Unusual HTTP POST requests with large payloads to a single script
Why this is correct
Unusual HTTP POST requests with large payloads to a single script are a strong web shell indicator because attackers commonly send commands to their backdoor via POST parameters, often encrypted or base64-encoded, to avoid GET logging. Legitimate form submissions have predictable parameter names and data sizes, whereas web shell traffic tends to show repeated, larger-than-normal POST bodies directed at one file, sometimes with randomized parameter names. This pattern is especially suspicious when the target script resides in an uploads directory or another location where normal user activity is not expected, signaling active command-and-control traffic.
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.