Attack Chain / Cyber Kill Chain
debt(d8/e7/b6/t7)
Closest to 'silent in production until users hit it' (d9), -1. The detection_hints note automated detection as 'no'. While tools like Semgrep and Burp Suite can detect individual vulnerabilities in the chain, recognizing that multiple low-severity findings combine into a critical attack chain requires manual threat modelling and expert analysis. Individual links may be flagged, but the chain relationship itself is nearly invisible to tooling — only careful security review or red-team exercises surface it. Scored d8 rather than d9 because individual steps can sometimes be caught.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix says 'fix low-severity findings that could be combined with others,' but this is deceptively simple advice. In practice, addressing attack chains requires fixing multiple vulnerabilities across different layers (information disclosure in error handling, LFI in file access, auth weaknesses) — these span multiple files and components. The common_mistakes highlight that fixing one high-severity step while ignoring enabling vulnerabilities is insufficient, meaning proper remediation touches error handling, input validation, authentication, and authorization across the codebase.
Closest to 'persistent productivity tax' (b5), +1. Attack chain thinking applies across all contexts (web, api, cli) and is a threat-modelling discipline that must be maintained continuously. It's not just a one-time fix but a persistent mental model that affects how every vulnerability is triaged and prioritized. It doesn't quite define the system's shape (b9) or create strong gravitational pull (b7), but it does impose an ongoing tax on security processes and triage workflows across the organization, slightly beyond b5.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception is explicit and dangerous: 'Fixing one vulnerability in a chain prevents the full attack.' This directly contradicts the intuitive mental model most developers have from CVSS-based triage, where each vulnerability is assessed in isolation. Developers trained to fix the highest-severity issue first naturally assume the chain is broken, but attackers pivot. The common_mistakes reinforce this: accepting low CVSS scores as low risk without considering chain potential is the default behavior.
Also Known As
TL;DR
Explanation
The Cyber Kill Chain (Lockheed Martin) and MITRE ATT&CK model attacks as sequences: Reconnaissance, Weaponisation, Delivery, Exploitation, Installation, Command & Control, then Actions on Objectives. Understanding the chain helps defenders identify the earliest disruption point — blocking delivery via a WAF is far cheaper than responding to active exfiltration. For PHP web applications, a typical chain runs: automated scanner reconnaissance, SQLi or file upload exploitation, webshell installation, reverse shell C2, then database dump. Defence-in-depth aims to break the chain at multiple simultaneous stages.
Diagram
flowchart TD
RECON[Reconnaissance<br/>scan ports, find subdomains] -->
ENUM[Enumeration<br/>find login, API endpoints] -->
EXPLOIT[Initial Exploit<br/>SQL injection / XSS] -->
ACCESS[Initial Access<br/>read DB / steal session] -->
PRIV[Privilege Escalation<br/>admin account] -->
PERSIST[Persistence<br/>backdoor / cron job] -->
EXFIL[Data Exfiltration<br/>customer records]
DEFEND[Defence in Depth<br/>stop at any stage] -.->|blocks| EXPLOIT & ACCESS & PRIV
style RECON fill:#f85149,color:#fff
style EXFIL fill:#f85149,color:#fff
style DEFEND fill:#238636,color:#fff
Watch Out
Common Misconception
Why It Matters
Common Mistakes
- Accepting low CVSS scores as low risk without considering chain potential with other issues.
- Fixing a high-severity step in a chain while ignoring enabling vulnerabilities that still allow reconstitution.
- Threat modelling single vulnerabilities rather than attacker goals and multi-step paths to achieve them.
- Not considering that information disclosure findings enable injection or authentication attacks downstream.
Avoid When
- Do not dismiss individual low-severity findings without checking whether they are part of a chain — information disclosure + IDOR + privilege escalation can each be "low" severity individually.
When To Use
- Use attack chain thinking during threat modelling to evaluate how low-severity findings combine into critical paths — a finding that seems minor in isolation may be the missing link in a chain.
- Apply it when triaging security reports: trace each finding backward (what does an attacker need first?) and forward (what does this enable next?).
Code Examples
// Information disclosure enables the chain:
header('X-Debug-Info: DB_HOST=db.internal DB_PASS=s3cr3t'); // Step 1: leaks creds
// Attacker uses creds to access admin endpoint:
// GET /admin/export?table=users — no auth check (Step 2: privilege escalation)# Attack chains combine individually low-severity issues into critical impact
# Example: Stored XSS + CSRF bypass + privilege escalation
# Step 1: Attacker stores XSS in profile bio (stored XSS — Medium)
# Step 2: Admin views profile — XSS fires in admin session
# Step 3: XSS POSTs to /admin/create-user with admin role (CSRF — Medium)
# Result: Attacker has admin account (Critical)
# Defence: each layer stops the chain
# Input sanitisation → stops Step 1
# CSP → stops Step 2 even if Step 1 slips through
# SameSite=Strict → stops Step 3 even if Steps 1+2 succeed
# In threat modelling: trace multi-step attack paths, not just single issues