How Attackers Actually Get In: The Web Application Kill Chain
Most breaches don't look like the films. There's rarely a single dramatic exploit. There's a chain of small, individually unremarkable weaknesses, and someone patient enough to link them together.
Understanding that chain is what separates a security programme that works from a pile of tools that doesn't. Here's how the work actually goes.
1. Reconnaissance: mapping what you forgot you had
Before anything is attacked, it's inventoried. An attacker enumerates subdomains, checks certificate transparency logs, reads job listings to learn your stack, looks through public code repositories for committed credentials, and fingerprints every service that answers.
What this consistently turns up isn't the well-maintained production application. It's the staging server nobody decommissioned, the admin panel on a forgotten subdomain, the API endpoint documented in a public repo, the S3 bucket set to public during a migration in 2023.
Almost every organisation has more internet-facing surface than its own team can list from memory. The gap between what you think you're running and what you're actually running is where engagements begin.
2. Initial access: the boring vulnerabilities
Broken access control remains the most prevalent category on the OWASP Top 10, and in the 2025 revision it also absorbed server-side request forgery. That tells you something: the dominant failure is not exotic memory corruption, it's software letting people reach things they shouldn't.
In practice that means:
Object references that aren't checked — changing an ID in a URL and getting somebody else's invoice.
Endpoints protected only by the UI — the button is hidden for non-admins, the API route behind it isn't.
Misconfiguration — default credentials, debug endpoints live in production, permissive cloud storage. This category moved up in the 2025 list precisely because modern stacks are mostly configuration.
Authentication weaknesses — no rate limiting on login, password reset flows that leak whether an account exists, sessions that never expire.
Supply chain — a dependency you didn't audit, pulled in by a dependency you did.
3. Escalation and movement
Initial access is rarely the goal. A low-privilege foothold becomes valuable when it can reach further — service accounts with far more permission than the task requires, credentials reused between staging and production, internal services that trust anything already inside the network.
This is where flat architectures get expensive. If one compromised container can reach the database directly, the blast radius of a minor bug is the whole business.
4. What the attacker does with the time
The uncomfortable part is duration. Intrusions are frequently discovered weeks or months after they began, and often by an outside party rather than the victim's own monitoring. Inadequate logging and detection is its own OWASP category for exactly this reason — it's the failure that turns a contained incident into a disclosed breach.
Why testing beats guessing
You can read this list and conclude you're probably fine. Almost everyone does. The problem is that the chain above depends on specifics — your actual subdomains, your actual permissions model, your actual dependency tree — and none of that is knowable from a checklist.
A penetration test is that chain, run deliberately, by someone authorised, who writes down what they found and how they got there.
Block Lock performs authorised penetration testing against web applications and infrastructure — the same sequence described above, with a written report of what was reachable and what to fix first.
Authorized testing only. Every technique described here is legal to perform against systems you own or have written permission to assess, and a criminal offence otherwise.
Comments