Exploitation

Step 1: Read the Attack Methodology

Open materials/attack-methodology.md. This document describes what sqlmap does, how it tests for SQL injection, and what a successful result looks like. Read it alongside materials/ttp-selection.md, which explains why SQL injection is the technique being tested against Jean-Marc's booking page.

SQL injection is straightforward in principle. A web application takes user input — a search field, a login form, a booking query — and builds a database query with it. If the application doesn't treat user input as data, an attacker can type something that changes the query itself. Instead of searching for a guest name, the query returns every record in the database. Jean-Marc's guests trust him with their passport numbers. If someone can pull every record through a crafted string in the booking form, that trust is broken.

sqlmap automates this testing. It sends a series of crafted inputs to the target parameter and watches how the application responds. Some responses indicate the parameter might be injectable. Others confirm it. The distinction matters: "might be injectable" is a hypothesis. Confirmed injection with extracted data is evidence.

Step 2: Run sqlmap

Think about what you're about to do. The reconnaissance showed open ports and running services. The TTP selection document identified SQL injection as the attack technique to test. Now you're going to prove whether the vulnerability is real. Everything up to this point has been observation. This step is validation.

The TTP selection document specifies the DVWA SQL injection endpoint and the parameter to test. A session cookie is a small piece of data the browser stores to prove you're logged in -- without it, the server treats each request as coming from a stranger. sqlmap needs this cookie so DVWA doesn't reject the request before it reaches the vulnerable page. Direct Claude to run sqlmap against it:

Using the target URL and parameter specified in materials/ttp-selection.md, run sqlmap to test for SQL injection against the DVWA application. Use the --batch flag to accept defaults and show the full output. Include the DVWA session cookie so the request authenticates properly. You can find the cookie value in your browser's developer tools under the Storage or Application tab — look for the cookie named PHPSESSID on the DVWA domain.

Notice the prompt. It points Claude to a specific document for the target details, requests the full output, and mentions the session cookie. If you'd said "test for SQL injection," Claude would have to guess the URL, the parameter, and the authentication — and any of those guesses could be wrong.

While sqlmap runs, it cycles through injection techniques: boolean-based blind, error-based, UNION query, time-based blind. Each one probes the parameter differently. You don't need to memorize the techniques. You need to read the output and understand whether the tool found something real or something possible.

Step 3: Review sqlmap Output

Claude will return sqlmap's terminal output. This is the exploitation evidence — the moment the vulnerability stops being a possibility and becomes a fact.

Look for the distinction between testing and confirmation. Early in the output, sqlmap reports which techniques it's trying against the parameter. Further down, if the injection succeeds, confirmed injection types appear with specific payloads — lines showing "boolean-based blind," "error-based," or "UNION query" as confirmed techniques. The line identifying the back-end database management system ("the back-end DBMS is MySQL") means sqlmap has confirmed the injection and can communicate with the database directly through the booking page.

If Claude summarizes the output as "the parameter is vulnerable" without distinguishing between sqlmap's confidence levels, push back. Ask to see the raw output. A line prefixed with [INFO] reporting a confirmed technique is different from a [WARNING] about an uncertain result. AI tends to collapse uncertainty into certainty — "parameter might be injectable" is probabilistic, not confirmed. The word "might" in sqlmap's output carries real meaning. Treating a probable finding as a confirmed one is how false positives enter assessment reports.

Step 4: Extract Data

A confirmed injection means someone can read the database. But impact depends on what's in it. Direct Claude to extract data through the injection:

The SQL injection is confirmed. Use sqlmap to enumerate the database tables, then extract data from the table that stores guest information. Show me what an attacker could access through this vulnerability.

This is where the vulnerability becomes concrete. sqlmap pulls back table names, column names, and row data. What you see is what an attacker sees: guest names, booking dates, passport numbers. Jean-Marc's guests handed over their personal information to book a whale-watching trip. That information is now sitting in a database that anyone with a crafted URL parameter can read.

Exploitation is validation, not discovery. The reconnaissance in Unit 2 suggested the target might be vulnerable. The sqlmap confirmation proves it. Without this step, the finding is a hypothesis. With it, the finding is evidence — and the evidence shows exactly what's at risk.

Step 5: Map the Finding

A confirmed SQL injection is useful to Jean-Marc. A confirmed SQL injection mapped to professional taxonomies is useful to anyone in security. Direct Claude to classify the finding:

Map our confirmed SQL injection finding to the MITRE ATT&CK framework and the OWASP Top 10. Specifically, map it to ATT&CK technique T1190 (Exploit Public-Facing Application) and OWASP A03:2021 (Injection). Explain what each mapping means and why this finding belongs in those categories.

Two taxonomies matter here. ATT&CK is MITRE's framework for classifying adversary techniques — it describes what attackers do. T1190 specifically covers exploiting public-facing applications to gain initial access. That's exactly what happened: someone (you, with sqlmap) sent crafted input to a web form and got back data they shouldn't have.

OWASP is a different lens. The OWASP Top 10 classifies web application vulnerability types by prevalence and impact. A03:2021 covers injection — any flaw where untrusted data is sent to an interpreter as part of a command or query. SQL injection is the textbook example, but the category is broader than that.

These aren't bureaucratic labels. They connect what you found on Jean-Marc's booking page to a body of professional knowledge about how this class of vulnerability works, how common it is, and what the standard remediation approaches are. When you write the assessment report later, another security practitioner reading "T1190" and "A03:2021" immediately understands the finding without re-reading your methodology. They're a shared language that makes security work communicable across teams and organizations.

Step 6: Document the Finding

Direct Claude to compile everything into a structured finding record:

Document the SQL injection finding. Include: the vulnerability description, the evidence (sqlmap output confirming injection), the ATT&CK and OWASP mappings, the extracted data demonstrating impact, and the potential consequences for Jean-Marc's guests. Reference the scope document to confirm this testing was within authorized boundaries.

Review what Claude produces. The documentation should contain:

• What was found: SQL injection in the specified DVWA parameter.
• How it was confirmed: sqlmap output showing the injection type and back-end DBMS identification.
• What data is exposed: The specific tables and records sqlmap extracted — guest names, passport numbers, booking details.
• Why it matters: ATT&CK T1190 and OWASP A03:2021 classification, with a plain statement of impact.
• That it was authorized: The target and parameter are within the scope document boundaries.

If any piece is missing, direct Claude to add it. A finding without methodology is an assertion. A finding without taxonomy is disconnected from professional practice. A finding without impact is an observation without consequence.

Check that Claude's documentation separates what was observed from what was interpreted. "sqlmap extracted 47 guest records including passport numbers" is an observation. "Jean-Marc's guest database is at critical risk of data theft" is an interpretation built on that observation. Both belong in the documentation, but they're different things. If Claude blends them together — presenting interpretation as raw evidence — the documentation loses its value as a reliable record.

The documentation you build here becomes the core of the assessment report Jean-Marc will receive. Everything after this unit — seeing the attack in the logs, fixing the vulnerability, writing the report — builds on what you've confirmed and recorded now.