CSA (312-39) SOC Simulation Lab
Welcome to the SOC. In this lab, we'll analyze web server access logs following a confirmed data breach to identify the exploitation vector. You'll learn to spot path manipulation techniques and differentiate web application attack signatures.
Scenario Context
You are an Incident Responder at AuraCart E-Commerce. The L2 team escalated a critical incident after sensitive customer payment configurations were found leaked on a dark web forum. The perimeter WAF fired no high-severity alerts prior to the breach. You have been tasked with analyzing the raw Nginx access logs of the primary web server to reconstruct the attacker's initial access vector.
Security Environment
Source: /var/log/nginx/auracart_access.log
Expert Insight
What is happening?
The attacker discovered that the `/api/v1/receipt` endpoint takes a user-supplied file name (`?file=`) and likely reads it directly from disk without sanitizing the input. By injecting "dot-dot-slash" (`../`) sequences, the attacker successfully backed out of the designated web root (e.g., `/var/www/html/receipts/`) and navigated the underlying Linux file system to steal `/etc/passwd` and a sensitive database configuration file.
Why the correct answer is correct
Directory Traversal (A), also known as Path Traversal (CWE-22), is exactly what the logs depict. The physical evidence—the use of `../` and its URL-encoded counterpart `..%2f` to manipulate the file path and access unauthorized directories—is the definitive signature of this attack type.
Why the other options are wrong
- B. Cookie Poisoning: This involves modifying session cookies to hijack sessions or escalate privileges. Our evidence shows manipulation of the URI parameters, not HTTP headers or cookies.
- C. SQL Injection (SQLi): While SQLi is used to extract backend data, its signature involves database syntax (`' OR 1=1`, `UNION SELECT`) injected into inputs. We are seeing file path navigation, not database queries.
- D. Cross-site Scripting (XSS): XSS executes malicious JavaScript in a victim's browser. It does not extract backend server files or manipulate the local file system. You would look for <script> or onload= payloads for XSS.
Real-world SOC Application
In a modern SOC, you will rarely see plain `../` in logs because basic WAF rules block them immediately. Attackers use automated tools like `ffuf` with evasion lists. Notice the fourth log entry: `..%252f`. This is double URL encoding. The WAF decodes `%25` into `%`, yielding `..%2f`. If the WAF doesn't decode a second time, it lets the payload through. The backend web server then decodes `..%2f` into `../` and executes the attack. This is exactly why the WAF in our scenario failed to alert L1 analysts.
Mini Lesson: Building Resilient Detection Logic
When writing SIEM queries (Splunk SPL, KQL) to detect Directory Traversal, do not just search for `../`. You must account for encoding techniques. A strong detection pattern involves normalizing the URI on read before applying regex.
// Example pseudo-detection logic
1. Decode URI recursively until no encoding remains.
2. Evaluate normalized URI against Regex: `(?i)(?:\.\.[\\\/]){2,}`
3. Alert if HTTP Status Code == 200 (Successful Exfiltration)
As a SOC analyst, always correlate successful web attacks (HTTP 200s) with abnormal user-agents (like `python-requests` seen in our logs) to prioritize your Incident Response efforts.
Ready for the next incident?
Sharpen your detection skills with more real-world SOC scenarios.
Explore more CSA simulations