Cyber.SoHo

Incident Handling & Response (IH&R)

🌐 The Web Application Threat Landscape

Web applications are the number one breach vector worldwide, accounting for roughly 40% of all breaches. To effectively handle incidents, you must speak the vocabulary of root causes. This section visualizes the OWASP Top 10, highlighting that while some vulnerabilities are extremely common (prevalence), others are rarer but devastating (impact). The OWASP list is not a compliance checklist; it is a vital vocabulary for your post-mortems.

The 2021 OWASP Top 10: Prevalence vs. Attention

Chart representing relative real-world prevalence of the top vulnerability categories based on test data.

🔥 Top 3 by Real-World Prevalence

  • A01: Broken Access Control - Found in ~55% of tested apps.
  • A03: Injection - SQL is declining, but command injection is rising.
  • A06: Vulnerable Components - The mass-scan attacker's favorite.

⚠️ Prevalence ≠ Impact

A10 (SSRF) is historically lower in raw prevalence but is devastating in modern cloud environments. Always read the Top 10 as prevalence-weighted plus impact-weighted. "It was an A01" is a defensible post-mortem answer; "the app had an issue" is not.

⚠️ Attack Vectors: The Unholy Trinity

Despite the complexity of the web, the same 5-6 bug classes dominate year after year. The core of your technical understanding should be grounded in the "Unholy Trinity." This interactive section breaks down the three most critical attack patterns: SQLi, XSS, and CSRF. Understanding who each attack targets is the first step in triage.

🔍 Detection: Logs & The Wedge Pattern

Logs are evidence, not absolute truth. A Web Application Firewall (WAF) block is not the end of the story; it signifies you are being probed. This section explores the six layers of logs you must consult and maps out the chronological "Wedge Attack Pattern." Train yourself to recognize the shape of an attack in your logs, not just the IP address.

The Wedge Attack Pattern

1

Reconnaissance

Many requests, mostly 404 Not Found. Searching for common paths: /wp-admin, /.env, /.git/config.

2

Targeted Probe

Fewer requests, carrying payloads. A mix of 400s (Bad Request) and 500s (Server Error) as the attacker tests inputs.

3

Exploit

Only two or three requests, returning 200 OK. Often followed by complete silence. The payload executed successfully.

4

Persistence

Outbound connections from your web server. New files in the web root. New cron entries on the OS.

Six Layers of Evidence

1. WAF / CDN Log (Perimeter)
2. Web Server Log (Apache/Nginx)
3. Application Log (Stack traces)
4. Database Query Log (Slow/Unusual)
5. OS Log (Files, sudo, cron)
6. SIEM Correlation (The Narrative)

📜 Log-Reading Rules of Thumb

  • Always work in UTC. Local time deceives.
  • Normalise URLs. Decode %27 to '.
  • Look adjacent in time. ±60 seconds around events.
  • Look adjacent in scope. Search the whole fleet.
  • Confirm in a second source. Prevent single-point failure.

🚨 Incident Response: The Containment Ladder

Incident handling is the discipline of doing the right thing in the wrong hour. The NIST SP 800-61r2 framework provides a strict ladder for containment. Skipping a rung means falling. Interact with the ladder below to understand the distinct phases of response and the critical rules that save careers. Furthermore, understand the legal ticking clock that governs your actions.

The 7 Rungs of Containment

⚠️ Two Rules That Save Careers

1. Isolate Before You Eradicate

Cut the network before you cut the malware. If the attacker cannot see your cleanup, they cannot adapt. Do not rush to delete the webshell.

2. Preserve Before You Eradicate

Snapshot disk/memory before cleanup. Forensics, Legal, and Commms need the exact state of the compromise.

⏱️ The Legal Clock (GDPR / AEPD)

The 72-Hour Rule: GDPR Article 33 mandates notifying the supervisory authority within 72 hours of becoming aware.

  • Clock starts at awareness, not full understanding.
  • The IR responder owns the timestamp.
  • Documentation is your defense, not bureaucracy.

📚 Case Studies & Post-Mortems

Reviewing historical breaches grounds our theory in reality. Tooling buys you the data; humans buy you the conclusion. In all three major case studies below, perimeter security failed, humans (not tools) connected the dots, dwell time was massive, and regulators got involved. The goal of incident response is to drive down Time-To-Detect (TTD) through blameless post-mortems.

2017

Equifax

A06: Outdated Components
  • Impact: 147 Million records exposed.
  • Vector: Apache Struts CVE-2017-5638.
  • Dwell Time Note: 67 days from public CVE release to attacker exploit.
2018

British Airways

A08: Integrity Failures
  • Impact: 380,000 credit cards stolen.
  • Vector: Magecart (JavaScript supply-chain).
  • Fallout: Initial £183M fine (reduced to £20M).
2019

Capital One

A10: SSRF
  • Impact: 106 Million records exposed.
  • Vector: SSRF → cloud metadata → IAM → S3.
  • Note: Textbook cloud privilege amplification.

The Blameless Post-Mortem

"We are not here to assign blame; we are here to find what made this possible. Every name in this room is here because they have something to teach us. The output of this meeting is three runbook changes, not three resignations."

Metric 1
TTD
Time-to-Detect
Metric 2
TTC
Time-to-Contain
Metric 3
Dwell Time
Total Attacker Time