Multi-Layer Exploitation

Step 1: Plan the exploitation sequence

You have confirmed findings from automated scanners, cross-tool correlation, and custom NSE scripts. Now exploit the vulnerabilities that demonstrate the highest-risk attack paths.

The Portland buyer wants to know whether the cooperative's systems are secure. The answer is not "we found 17 vulnerabilities" -- it is "here is what an attacker could access and what it means for your supply chain." Plan the exploitation to demonstrate business impact, not to maximize vulnerability count.

Review the threat model and the correlated findings. Identify the two or three attack paths that carry the most risk for the cooperative's business -- buyer pricing data, farmer personal information, or fermentation process integrity.

Based on the threat model and verified findings, plan an exploitation sequence targeting the highest-risk attack paths. For each path, identify: the entry point, what data or access it leads to, and why it matters for the Portland buyer's compliance question. Don't exploit everything -- focus on what demonstrates the most significant risk.

AI will try to exploit every finding to its maximum depth. That is not what a scoped assessment requires. You decide which paths are worth pursuing and how deep to go. Is proving initial access to buyer data sufficient? Or does the compliance question require demonstrating the full chain from web application to database to lateral movement?

Step 2: Exploit the web application vulnerability

Start with the export tracking system. The SQL injection finding from Unit 3 was correlated across multiple tools. Exploit it.

Exploit the SQL injection vulnerability on the export tracker's search endpoint. Demonstrate what data an attacker could access. Document the exploitation path -- what you sent, what came back, and what it means.

The goal is evidence, not damage. Extract enough data to demonstrate the impact -- buyer names, shipment details, pricing information. This is what the Portland buyer needs to see in the compliance report: proof that the vulnerability exists and evidence of what it exposes.

Document the exploitation path clearly. The developer in Caracas will need to understand exactly what endpoint is vulnerable, what input triggers it, and what data is accessible. The Portland buyer needs to understand the business impact. These are two different descriptions of the same finding.

Step 3: Attempt multi-layer movement

From the web application layer, investigate whether the attacker can reach other services. The export tracker, member portal, fermentation API, and payment processor share the Docker network. A compromised web application is the entry point -- what else can the attacker reach?

From the export tracker's compromised position, investigate lateral movement possibilities. Can you reach the member portal, the fermentation API, or the payment processor? What network connections are possible between services? Document what is reachable and what is not.

The fermentation sensors share the office network. If the export tracker can reach the fermentation API, and the fermentation API has no authentication, the attacker can pivot from buyer pricing data to fermentation process manipulation. That is a different kind of risk -- not just data exposure but operational interference during a critical processing window.

Container escape is a boundary. If you reach a point where the next step requires breaking out of the Docker container, that crosses a scope line. You need explicit authorization before attempting it. Note the boundary, document what you can see from inside the container, and decide whether asking Andres to expand the scope is warranted.

Step 4: Run Semgrep SAST analysis

Dynamic testing from the outside tells you what an attacker can exploit. Static analysis from the inside tells you what vulnerabilities exist in the code -- even the ones you cannot reach from the outside.

Run Semgrep against the cooperative's application code.

Run Semgrep against the export tracker, member portal, fermentation API, and payment processor code. Look for SQL injection, XSS, insecure dependencies, hardcoded credentials, and API key exposure. For each finding, note the file path, line number, and whether the vulnerable code path is reached during normal application operation.

Semgrep will find things dynamic testing missed. But a finding in the source code is not the same as a finding you can exploit at runtime. If Semgrep flags a code path that is never executed -- a deprecated function, an unused route, a commented-out feature -- that is informational, not exploitable. Check reachability for each finding.

AI commonly treats every Semgrep finding as a confirmed vulnerability. When you ask AI to summarize the results, it may not distinguish between a finding in active code and a finding in dead code. Verify which findings are reachable before recording them as exploitable.

Pay attention to dependencies. The payment processor's requirements file may include packages with known CVEs. Semgrep and Trivy both check dependencies -- a vulnerable library that is actually imported and used is different from one that is listed but never loaded.

Step 5: Make depth decisions and document

You have exploited web application vulnerabilities, investigated lateral movement, and run static analysis. Now decide: is the evidence sufficient for the Portland buyer's compliance question, or does the assessment need to go deeper?

Marcus Webb sends a message: "Be careful with that shipping integration. Testing their API is testing their system, not Andres's. Did you check whether the API keys are in the code repository?"

Marcus is redirecting you. The shipping API is a third-party system -- probing it directly is out of scope. But checking whether the cooperative's code contains exposed API keys is entirely in scope. That is a supply chain finding about the cooperative's practices, not an attack on the shipping provider.

Check the export tracker's source code for exposed API keys, credentials, or tokens related to the shipping integration. Document what is stored in the code versus what should be in environment variables or a secrets manager.

Document your exploitation depth decisions. For each attack path, explain why you stopped where you did. "Proved initial access to buyer pricing data -- sufficient to demonstrate information disclosure risk for compliance report" is a professional scope decision. "Pursued every possible path to maximum depth because the tool kept finding things" is not.