GCIH Incident Response and Cyber Investigation Practice Question
Exhibit
{
"rule_name": "Suspicious_PowerShell_Execution",
"conditions": {
"command_line_contains": ["-enc", "-encodedcommand", "IEX"],
"parent_process": "w3wp.exe"
}
}Refer to the exhibit. An analyst deploys this policy to detect threats. Why is the 'parent_process' condition specifically targeting 'w3wp.exe'?
⚠ Common exam trap
Candidates often assume the rule is looking for the 'w3wp.exe' process itself as the threat, missing that the goal is to detect suspicious child processes spawned by a legitimate web server process.
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
✓
To identify potential web shell execution or exploit payloads triggered via IIS.
The 'w3wp.exe' process is the IIS worker process. Attackers often exploit web vulnerabilities to spawn child processes, such as PowerShell, to execute malicious scripts directly from memory. By flagging PowerShell child processes of an IIS worker, the analyst is specifically monitoring for web shell activity or remote code execution, which are common vectors for initial access and persistence in web-facing server environments.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
To detect unauthorized software installations performed by administrative users.
Why it's wrong here
Administrative installations are typically performed via different processes or installers. Monitoring PowerShell child processes of a web server is not a standard way to track software installation, and this approach would likely result in an overwhelming number of false positives for legitimate automated web server management scripts.
- ✓
To identify potential web shell execution or exploit payloads triggered via IIS.
Why this is correct
IIS worker processes (w3wp.exe) should rarely spawn PowerShell. When they do, it is a high-confidence indicator of a web application compromise, such as a web shell executing commands. This detection is tailored to catch the specific behavior of attackers attempting to pivot from a web exploit to system-level execution.
- ✗
To prevent the web server from being used as a staging ground for brute force.
Why it's wrong here
Brute force attacks typically involve repeated authentication attempts to login endpoints, which appear as network traffic or application login failures. These attacks do not necessarily involve the IIS worker process spawning PowerShell, so this rule would be ineffective at detecting a brute force attack against a web application.
- ✗
To ensure that all PowerShell scripts are signed and authorized by the organization.
Why it's wrong here
While code signing is a valid policy, this specific rule checks for the parent process and command line arguments, not the script signature. It is a behavioral detection rule designed to catch malicious activity, not a policy enforcement rule designed to verify the digital signatures of legitimate administrative scripts.
About these practice questions
Courseiva writes every GCIH question from scratch — 322 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GCIH practice question is part of Courseiva's free GIAC 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 GCIH exam.